Download PDF
Download page Java を使用したモニタリング拡張機能の作成.
Java を使用したモニタリング拡張機能の作成
カスタムメトリックをスタンドアロン マシン エージェントとサーバの可視性で収集できるようにする Java モニタリング拡張機能を作成できます。これらのカスタムメトリックは、定義、提供し、コントローラにレポートします。これは、スクリプトを使用してモニタリング拡張機能を追加するという方法の代わりの方法です。
モニタリング拡張機能を使用してカスタムメトリックをキャプチャする場合、それらのカスタムメトリックは、AppDynamics アプリケーションとマシンエージェントによってキャプチャされる標準メトリックに対して使用できる同じ AppDynamics サービスによってサポートされます。これらのサービスには、自動ベースライン化、異常検知、メトリックブラウザへの表示、カスタムダッシュボードへの表示機能、アラートやその他のアクションをトリガーするためのポリシーでの使用機能が含まれます。
このトピックでは、Java でモニタリング拡張機能を作成する方法について説明します。
エージェントに対しては、モニタリング拡張機能は、固定スケジュールで実行され、メトリックを収集するタスクです。
はじめに
独自の拡張機能を最初から作成する前に、 AppDynamics コミュニティで拡張機能を確認してください。次の場所には拡張機能の説明があり、それらのソースを無料でダウンロードできます。
https://github.com/Appdynamics/
新しい拡張機能が常に追加されています。他のユーザが必要なもの、または必要なものに近いものをすでに作成している可能性があります。必要なものに近いものをダウンロードし、簡単な変更をいくつか加えれば使用できる場合があります。
モニタリング拡張機能の作成の概要
Java でモニタリング拡張機能を作成するには、次のようにします。
- 拡張クラスを作成します。「モニタリング拡張機能の作成」を参照してください。
- monitor.xml 設定ファイルを作成します。「monitor.xml ファイルの作成」を参照してください。
<agent_home>/monitors
の下にサブディレクトリ(<your_extension_dir>
)を作成します。- 拡張クラスファイルと monitor.xml ファイル(および依存 jar ファイル)を <your_extension_dir> に配置します。
コントローラのアクセス情報と資格情報を入力します。詳細については、「スタンドアロン マシン エージェントの設定」を参照してください。
コントローラ情報とコマンドラインパラメータが正しく設定されていることを確認します。必要なプロパティには、コントローラ名、ポート番号、アカウントアクセスキーなどがあります。
- マシンエージェントを再起動します。
モニタリング拡張クラスの作成
com.singularity.ee.agent.systemagent.api パッケージ内の AManagedMonitor クラスを拡張してモニタリング拡張クラスを作成します。このパッケージは、MachineAgent.jar ファイルに含まれています。
モニタ拡張クラスは、次のタスクを実行します。
- AppDynamics に追加するメトリックの値をハッシュマップに入力します。
これらのメトリックの取得方法は、ご使用の環境およびカスタムメトリックの取得元のソースによって異なります。 - MetricWriter クラスを使用して収集するメトリックのタイプを定義します。「メトリック処理修飾子」を参照してください。
- AManagedMonitor クラスの
execute()
メソッドを使用して、メトリックをコントローラにアップロードします。
ソースコードの例を次に示します。Extension_Class_Source.txt。
メトリックパス
マシンエージェントとサーバの可視性によって処理されるすべてのカスタムメトリックは、[Metric Browser] > [Application Infrastructure Performance] に表示されます。「I」文字を使用して、[Application Infrastructure Performance] からカスタムメトリックへのパスを指定します。メトリックが特定の階層に適用される場合は、階層のメトリックパス(「Component」、その後にコロン「:」と階層名または階層 ID)を使用します。
たとえば、メトリックを AccountService 階層に関連付けたいとします。この場合、メトリックパスを次のように指定します。
- Server|Component:AccountService|Custom Metrics|Path|
メトリックは、メトリックブラウザの次のツリーの下に表示されます。
スタンドアロン マシン エージェントに関連付けられている階層にのみ、カスタムメトリックをレポートできます。メトリックを別の階層に公開しようとすると、メトリックはレポートされません。
既存のタイプのメトリックとともにカスタムメトリックを挿入できます。たとえば、次の宣言により、pool usage という名前のカスタムメトリックが JMX メトリックとともに表示されます。
- name="Server|Component:<tier-name>|JMX|Pool|First|pool usage",value=10
この後、このメトリックを、他のタイプの JMX メトリックと同様に、正常性ルールで使用できます。
スタンドアロン マシン エージェントの REST API にメトリックデータをポストすることによって、コントローラ API でカスタムメトリックの表示をテストできます。メトリックのパス、名前タイプ、および値を URL 引数として渡します。詳細については、スタンドアロン マシン エージェントの HTTP リスナーを参照してください。
メトリック名
メトリック名は、同じメトリックパス内で一意である必要がありますが、メトリック階層全体に対して一意である必要はありません。
メトリックブラウザに表示されるときに見やすいように、短いメトリック名を使用してください。
メトリックをコントローラにアップロードするときにメトリック名の前にメトリックパスを付加します。
メトリック処理修飾子
コントローラには、メトリックの処理方法(集約、時間ロールアップ、および階層ロールアップ)を示すさまざまな修飾子があります。
メトリック修飾子には、次の 3 つのタイプがあります。
- 集約修飾子
- 時間ロールアップ修飾子
- クラスタロールアップ修飾子
これらのオプションは、MetricWriter クラスによって提供される列挙型を使用して指定します。これらのタイプは、以下のように定義されます。
集約修飾子
集約修飾子では、1 分間にレポートされた値をマシンエージェントでどのように集約するかを指定します。
集約修飾子は、アグリゲータ="アグリゲータタイプ" として指定します。
この値は列挙型です。有効な値は次のとおりです。
アグリゲータタイプ | 説明 |
---|---|
METRIC_AGGREGATION_TYPE_AVERAGE | これがデフォルトです。その 1 分にレポートされたすべての値の平均。 |
METRIC_AGGREGATION_TYPE_SUM | その 1 分にレポートされたすべての値の合計。これにより、メトリックはカウンタと同様に動作します。 |
METRIC_AGGREGATION_TYPE_OBSERVATION | その 1 分にレポートされた最後の値。その1分以内に値がレポートされない場合は、最後にレポートされた値が使用されます。 |
時間ロールアップ
時間ロールアップ修飾子では、時間が経過して 1 分単位のテーブルから 10 分単位のテーブル、および 60 分単位のテーブルに変換するときに、コントローラで値をどのようにロールアップするかを指定します。
ロールアップ方法 | 説明 |
---|---|
METRIC_TIME_ROLLUP_TYPE_AVERAGE | 1 分間のすべてのデータポイントの平均(10 分単位または 60 分単位のテーブルに追加する場合)。 |
METRIC_TIME_ROLLUP_TYPE_SUM | 1 分間のすべてのデータポイントの合計(10 分単位または 60 分単位のテーブルに追加する場合)。 |
METRIC_TIME_ROLLUP_TYPE_CURRENT | その 10 分または 60 分の間隔で最後にレポートされた 1 分間のデータポイント。 |
クラスタロールアップ
クラスタロールアップ修飾子では、コントローラで階層内のメトリック値をどのように集約するかを指定します。
ロールアップ方法 | 説明 |
---|---|
METRIC_CLUSTER_ROLLUP_TYPE_INDIVIDUAL | 階層内の各ノードでのメトリック値を平均して、メトリック値を集計します。 |
METRIC_CLUSTER_ROLLUP_TYPE_COLLECTIVE | 階層内のすべてのノードのメトリック値を合計して、メトリック値を集計します。 |
たとえば、階層に 2 つのノード、ノード A とノード B があり、ノード A に 1 分あたり 3 個のエラーがあり、ノード B に 1 分あたり 7 個のエラーがある場合、INDIVIDUAL 修飾子では 1 分あたり 5 個のエラーが値としてレポートされ、COLLECTIVE 修飾子では 1 分あたり 10 個のエラーがレポートされます。INDIVIDUAL は、各ノードの値が必要な CPU 使用率(% CPU Busy)などのメトリックに適しています。COLLECTIVE は、階層全体の値が必要な呼び出し数(Number of Calls)などのメトリックに適しています。
モニタリング拡張クラスの例
NGinXMonitor クラスは、Nginx Web サーバから次のメトリックを取得し、それらのメトリックを AppDynamics によってレポートされたメトリックに追加します。
- Active Connections:アクティブな接続の数
- Accepts:承認された要求の数
- Handled:処理された要求の数
- Requests:要求の合計数
- Reading:読み取り回数
- Writing:書き込み回数
- Waiting:キープアライブ接続の数
拡張クラスのソースは添付ファイルとして含まれています。
monitor.xml の作成
マシンエージェントで拡張機能をどのように実行するかを設定する <monitor> 要素がある monitor.xml ファイルを作成します。
<name>
を Java モニタリング拡張クラスの名前に設定します。<type>
をmanaged
に設定します。<execution-style>
はcontinuous
またはperiodic.
にすることができます。- continuous は、一定期間の平均メトリックを収集することを意味します。たとえば、1 分あたりの平均 CPU 使用率などです。continuous 実行では、マシンエージェントは拡張機能を一度だけ呼び出し、そのプログラムが継続的に実行され、60 秒ごとにデータが返されます。
periodic は、指定された頻度でモニタを呼び出すことを意味します。periodic 実行では、マシンエージェントは拡張機能を呼び出し、それを短時間実行し、
<execution-frequency-in-seconds>
要素によって設定されたスケジュールでデータを返します。<
execution-frequency-in-seconds
> を 300 秒(5 分)よりも大きい値に設定しないでください。拡張機能では、少なくとも 5 分ごとにメトリックを収集する必要があります。
- 実行スタイルとして
periodic
を選択した場合、<execution-timeout-in-secs>
要素で収集の頻度を設定します。デフォルトの頻度は、60 秒です。continuous
を選択した場合、この設定は無視されます。 <monitor-run-task>
子要素の<type>
をjava
に設定します。<execution-timeout-in-secs>
を、拡張機能がタイムアウトになるまでの秒数に設定します。<task-arguments>
要素で必要なタスク引数を指定します。ここで指定するデフォルトの引数は、拡張機能で使用される唯一の引数です。これらは他の場所では設定されません。<classpath>
を、拡張機能のクラスが含まれる jar ファイルに設定します。任意の依存 jar ファイルをセミコロンで区切って含めます。<impl-class>
を、マシンエージェントが呼び出すクラスのフルパスに設定します。
サンプルの monitor.xml ファイル
この添付されている monitor.xml ファイルによって、NGinXMonitor モニタリング拡張機能が設定されます。この拡張機能は、60 秒ごとに実行されます。
この添付されている monitor.xml ファイルによって、MysqlMonitor が設定されます。このモニタは、60 秒ごとに実行され、4 つの必須タスク引数、1 つのオプションタスク引数、および 1 つの依存 jar ファイルが使用されます。