Related pages:

カスタムメトリックをマシンエージェントとサーバの可視性で収集できるようにする Java モニタリング拡張機能を作成できます。これらのカスタムメトリックは、定義、提供し、コントローラにレポートします。これは、スクリプトを使用してモニタリング拡張機能を追加するという方法の代わりの方法です。

モニタリング拡張機能を使用してカスタムメトリックをキャプチャする場合、それらのカスタムメトリックは、AppDynamics アプリケーションとマシンエージェントによってキャプチャされる標準メトリックに対して使用できる同じ AppDynamics サービスによってサポートされます。これらのサービスには、自動ベースライン化、異常検知、メトリックブラウザへの表示、カスタムダッシュボードへの表示機能、アラートやその他のアクションをトリガーするためのポリシーでの使用機能が含まれます。

このページでは、Java でモニタリング拡張機能を作成する方法について説明します。

エージェントに対しては、モニタリング拡張機能は、固定スケジュールで実行され、メトリックを収集するタスクです。 

はじめに

独自の拡張機能を最初から作成する前に、 AppDynamics コミュニティで拡張機能を確認してください。拡張機能の無料ダウンロードについては、GitHub を参照してください

新しい拡張機能が常に追加されています。他のユーザが必要なもの、または必要なものに近いものをすでに作成している可能性があります。必要なものに近いものをダウンロードし、変更をいくつか加えれば使用できる場合があります。

Java でのモニタリング拡張機能の作成

Java でモニタリング拡張機能を作成するには、次のようにします。

  1. 拡張クラスを作成します。「モニタリング拡張機能の作成」を参照してください。
  2. monitor.xml 設定ファイルを作成します。「monitor.xml ファイルの作成」を参照してください。
  3. <agent_home>/monitors の下にサブディレクトリ（<your_extension_dir>）を作成します。
  4. 拡張クラスファイルと monitor.xml ファイル（および依存 jar ファイル）を <your_extension_dir> に配置します。

  5. コントローラのアクセス情報と資格情報を入力します。詳細については、「マシンエージェントの構成」を参照してください。

    controller-infoとコマンドラインパラメータが正しく設定されていることを確認します。必要なプロパティには、コントローラ名、ポート番号、アカウントアクセスキーなどがあります。 

  6. マシンエージェントを再起動します。

モニタリング拡張クラスの作成

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|

メトリックは、メトリックブラウザのツリーの下に表示されます。

Metric Browser Tree

マシンエージェントに関連付けられている階層にのみ、カスタムメトリックをレポートできます。メトリックを別の階層に公開しようとすると、メトリックはレポートされません。

既存のタイプのメトリックの次にカスタムメトリックを挿入できます。たとえば、次の宣言により、pool usage という名前のカスタムメトリックが JMX メトリックの次に表示されます。name="Server|Component:<tier-name>|JMX|Pool|First|pool usage",value=10

この後、このメトリックを、他のタイプの JMX メトリックと同様に、正常性ルールで使用できます。 

コントローラ API でのカスタムメトリックの表示をテストするには、マシンエージェントの REST API にメトリックデータをポストします。メトリックのパス、名前タイプ、および値を URL 引数として渡します。「マシンエージェント HTTP リスナー」を参照してください。

メトリック名

メトリック名は、同じメトリックパス内で一意である必要がありますが、メトリック階層全体に対して一意である必要はありません。

AppDynamics では、メトリックブラウザに表示されるときに見やすいように、短いメトリック名を使用することを推奨しています。

メトリックをコントローラにアップロードするときにメトリック名の前にメトリックパスを付加します。

メトリック処理修飾子

コントローラには、メトリックの処理方法（集約、時間ロールアップ、および階層ロールアップ）を示すさまざまな修飾子があります。

メトリック修飾子には、次の 3 つのタイプがあります。

  • アグリゲータ修飾子
  • 時間ロールアップ修飾子
  • クラスタロールアップ修飾子

これらのオプションは、MetricWriter クラスによって提供される列挙型を使用して指定します。

集約修飾子

アグリゲータ修飾子では、1 分間にレポートされた値をマシンエージェントでどのように集約するかを指定します。

集約修飾子は、次のように指定します。 aggregator="aggregator type"

この値は列挙型です。有効な値は次のとおりです。

アグリゲータタイプ

説明

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 ファイルを作成します。

  1. <name> を Java モニタリング拡張クラスの名前に設定します。
  2. <type> を managed に設定します。
  3. <execution-style> は continuous または periodic. にすることができます。
    • continuous は、一定期間の平均メトリックを収集することを意味します。たとえば、1 分あたりの平均 CPU 使用率などです。continuous 実行では、マシンエージェントは拡張機能を一度だけ呼び出し、そのプログラムが継続的に実行され、60 秒ごとにデータが返されます。

    • periodic は、指定された頻度でモニタを呼び出すことを意味します。periodic 実行では、マシンエージェントは拡張機能を呼び出し、それを短時間実行し、<execution-frequency-in-seconds> 要素によって設定されたスケジュールでデータを返します。 

      <execution-frequency-in-seconds> を 300 秒（5 分）よりも大きい値に設定しないでください。拡張機能では、少なくとも 5 分ごとにメトリックを収集する必要があります。

       

  4. 実行スタイルとして periodic を選択した場合、<execution-frequency-in-seconds> 要素で収集の頻度を設定します。デフォルトの頻度は、60 秒です。
    continuous を選択した場合、この設定は無視されます。
  5. <monitor-run-task> 子要素の <type> を java に設定します。
  6. <execution-frequency-in-seconds> を、拡張機能がタイムアウトになるまでの秒数に設定します。

  7. Java ベースの拡張機能の <task-arguments> 要素で必要なタスク引数を指定します。引数タグには、name、default-value、および is_required の 3 つのパラメータがあります。is_required は常に true に設定されます。タスク引数には、任意のカスタム引数を指定できます。ここで指定するデフォルトの引数は、拡張機能で使用される唯一の引数です。これらは他の場所では設定されません。

    <task-arguments> 要素の例：

    <argument name="password" is-required="true" default-value="welcome"/>
    CODE


  8. <classpath> を、拡張機能のクラスが含まれる jar ファイルに設定します。任意の依存 jar ファイルをセミコロンで区切って含めます。
  9. <impl-class> を、マシンエージェントが呼び出すクラスのフルパスに設定します。

サンプルの monitor.xml ファイル

この添付されている monitor.xml ファイルによって、NGinXMonitor モニタリング拡張機能が設定されます。この拡張機能は、60 秒ごとに実行されます。

この添付されている monitor.xml ファイルによって、MysqlMonitor が設定されます。このモニタは、60 秒ごとに実行され、4 つの必須タスク引数、1 つのオプションタスク引数、および 1 つの依存 jar ファイルが使用されます。