以下の使用： Machine Agentにより、独自のカスタムメトリックを使用して AppDynamics コントローラ UI の既存のメトリックを補うことができます。現在、Cisco DevNet サイトには多くの拡張機能があります。AppDynamics が作成したものと、ユーザが作成したものがあります。

組み込みメトリックと同様に、カスタムメトリックは次の AppDynamics 機能で使用できます。

  • 自動ベースラインと異常検知

  • カスタムダッシュボードへの表示機能

  • ポリシーでの使用機能
  • メトリックブラウザおよび [Infrastructure] タブでのすべてのメトリックの表示（同じグラフに外部メトリックと AppDynamics メトリックを表示できます）

最初に報告されたメトリック値は、[Server Visibility ] メトリックブラウザには表示されますが、[Application Performance Monitoring] メトリックブラウザには表示されません。これは予期される動作であり、メトリックレポートを最適化し、メモリオーバーヘッドを防ぐように設計されています。

新しいカスタムメトリックの追加

カスタムメトリックを作成するには、モニタリング拡張機能を作成します。拡張機能では、メトリックの名前とパス（メトリックブラウザのツリーでの表示場所）、メトリックのタイプ（合計、平均など）、およびメトリックのデータが古くなった場合のロールアップ方法を定義します。任意のモードを通じてコントローラに報告されるカスタムメトリックは、少なくとも 300 秒（5 分）に 1 回報告される必要があります。1 つのエージェントで多くの拡張機能を実行できますが、そのようにする場合、JVM エージェントのメモリの量を増やす必要がある場合があります。同じ拡張機能の複数のコピーを使用することもできます（それらが異なるディレクトリにある場合）。

カスタムメトリックは、ノード間で共通にすることも、特定の階層に関連付けることもできます。メトリックを作成するときに、パスを指定します。メトリックは、メトリックツリー内のこのパスの場所に表示されます。共通のカスタムメトリックを作成するには、メトリック宣言でルートツリーパスのカスタムメトリックを使用します。階層固有のメトリックを作成するには、そのコンポーネントに関連付けられているメトリックパスを指定します。   

アプリケーションがマシンエージェントで多数の AppDynamics 拡張機能を使用している場合は、メモリ割り当てのサイズを増やす必要がある場合があります。

For Linux and Unix-like Systems

% <machine_agent_home>/bin/machine-agent -Xms64m
CODE

For Windows

> <machine_agent_home>\bin\machine-agent.cmd -Xms64m
CODE

ワイルドカード機能は、カスタムメトリックではサポートされていません。

モニタリング拡張機能のタイプ

次のメカニズムを使用して、カスタムメトリックを実装できます。

  • スクリプトを使用：
    1 分ごとにマシンエージェントにカスタムメトリックをレポートするためのシェルスクリプト（Linux および Unix ライクなシステム）またはバッチファイル（Windows）を作成できます。マシンエージェントは、これらのメトリックをコントローラに渡します。「スクリプトを使用したモニタリング拡張機能の作成」を参照してください。
  • Java を使用：
    カスタムメトリックは、複雑になりすぎて、スクリプトを使用して収集できない場合があります。たとえば、メトリックを取得するために、複雑な計算を実行するか、サードパーティの API を呼び出す必要がある場合があります。この場合、JavaServersMonitor クラスを拡張してメトリックを収集し、それらをマシンエージェントにレポートできます。Java プログラムで JavaServersMonitor クラスを拡張してカスタム機能を提供します。「Java を使用したモニタリング拡張機能の作成」を参照してください。
  • HTTP を使用：
    エージェント HTTP リスナーを有効にすると、HTTP リクエストをマシンエージェントにポストして、そのエージェントにカスタムメトリックを 1 分ごとに送信できます。これを行うには、Jetty HTTP リスナーを含むマシンエージェントを起動します。「マシンエージェント HTTP リスナー」を参照してください。