このページでは、AppDynamics ポリシーでトリガーを定義する正常性ルールおよびポリシーステートメントの概要について説明します。

正常性ルールとは

正常性ルールでは、お使いの環境で正常または予想されるオペレーションであると考えられるものを表すパラメータを指定します。パラメータは、ビジネストランザクションの平均応答時間やノードのCPU使用率などのメトリック値に依存します。

正常性ルールの影響を受けるエンティティのパフォーマンスがルールの条件に違反すると、正常性ルール違反となります。正常性の状態は、重大、警告、通常、および不明で表されます。 

エンティティの正常性状態が変わると、正常性ルール違反のイベントが発生します。正常性ルール違反の例:

  • 起動中
  • 終了中
  • 警告から重大へのアップグレード、または
  • 重大から警告へのダウングレード

エンティティおよび正常性ルール違反の正常性の状態は、コントローラ ユーザーインタフェースに表示されます。また、正常性ルール違反のイベントは、アラートメールの送信や修正スクリプトの実行など、自動でアクションを開始できるポリシーのトリガーに使用できます。

正常性ルールの構成」で説明されている正常性ルールウィザードを使用して、正常性ルールを作成します。ウィザードを使うと、一般的なシステム エンティティおよび関連するメトリックをグループ化することで、正常性ルールのセットアップを単純化できます。また、AppDynamics で提供されるデフォルトの正常性ルールをそのまま、または変更して使用する方法もあります。

デフォルトの正常性ルール

AppDynamics には、アプリケーションやサーバなど一部の製品に対する正常性ルールのデフォルト設定があります。こうしたデフォルトの正常性ルールは、エンティティによって異なります。デフォルトのルールを確認するには、正常性ルールが AppDynamics のインストールに追加される前に次を実行します。

  1. [Alert&Respond] タブで、[Health Rules] をクリックします。
  2. エンティティを選択します。
    選択したエンティティのデフォルトの正常性ルールが表示されます。

この定義済みの正常性ルールのいずれかに違反すると、UI では影響を受けたエンティティが警告レベルの違反は黄-オレンジ色、重大な違反の場合は赤色で表示されます。

多くの場合、デフォルトの正常性ルールは必要な唯一の正常性ルールである可能性があります。アプリケーションに合わせて正常性ルールを編集およびカスタマイズできます。また、デフォルトの正常性ルールを無効にすることもできます。

正常性ルールのスコープ

正常性ルールのスコープによって、デフォルトの正常性ルール タイプのセットが決まります。スコープを選択して、アプリケーション、サーバー、またはデータベース用のデフォルトの正常性ルール タイプのセットを取得できます。たとえば、モバイルアプリケーションをスコープとして定義すると、クラッシュ率や HTTP/ネットワークエラー率などデフォルトの正常性ルールが表示されます。同様に、アプリケーション用に正常性ルールのスコープを定義する場合、ビジネストランザクション、CPU/メモリ使用率などの正常性ルールになります。

Alert & Respond > Health Rules では、ドロップダウンリストから次の正常性ルールのスコープのいずれかを選択できます。

  • アプリケーション
  • User Experience: Browser Apps
  • User Experience: Mobile Apps
  • ユーザーエクスペリエンス:API モニタリング
  • データベース
  • サーバ
  • 分析

各スコープのデフォルトセットに追加する新しい正常性ルールを作成することもできます。正常性ルール app starts をモバイルアプリケーションに追加することができます。この正常性ルールは、モバイルアプリのスコープで正常性ルールのデフォルトセットに含まれていないため、新しい正常性ルールを追加するだけで済みます。

正常性ルールのタイプ

正常性ルールウィザードでは、正常性ルールが適用されるエンティティにより分類されるタイプに正常性ルールをグループ化します。こうすることで、正常性ルールの作成中にウィザードに適切な構成項目を表示することができます。

正常性ルールには以下のタイプがあります。

  • トランザクションパフォーマンス
    • Overall Application Performance:負荷、応答時間、コールの遅延、停止に関連するメトリックをアプリケーションでグループ化
    • Business Transaction Performance:負荷、応答時間、コールの遅延、停止などに関連するメトリックをビジネストランザクションでグループ化
  • ノード正常性
    • Node Health-Hardware, JVM, CLR:CPU やヒープの使用、ディスク I/O などのメトリックをノードでグループ化
    • Node Health-Transaction Performance:負荷、応答時間、コールの遅延、停止などに関連するメトリックをノードでグループ化
    • Node Health-JMX:Java のみ、接続プール、スレッドプールなどに関連するメトリックを特定のノードおよびティアにある特定の JMX インスタンスおよびオブジェクトでグループ化
  • ユーザエクスペリエンス-ブラウザ アプリケーション
    • Pages:エンドユーザ用のアプリケーションページのパフォーマンスで、DOM 構築時間、JavaScript エラーなどのメトリックをグループ化
    • IFrames: エンドユーザ用の iFrame のパフォーマンスで、最初のバイトタイミング、毎分のリクエストなどのメトリックをグループ化
    • AJAX Requests: エンドユーザ用の Ajax リクエストのパフォーマンスで、Ajax コールバック実行時間、毎分のエラーなどのメトリックをグループ化
    • Virtual Pages:Angular で作成された仮想ページ用のエンドユーザ応答時間、ダイジェストサイクル、HTML ダウンロード時間、DOM 構築時間などのメトリックをグループ化仮想ページのコンテキストでこれらのメトリックが意味することに関する情報については、AngularJS サポートを参照してください。
  • ユーザーエクスペリエンス-モバイル アプリケーション
    • Mobile Apps: モバイルアプリのクラッシュ、起動、サーバコールに加えて、ネットワークのリクエストおよびエラーに関連するメトリックをグループ化
    • Network Requests:HTTP やネットワークエラー、リクエスト時間、および毎分のリクエストなどのメトリックをネットワークリクエストでグループ化
  • Servers:ハードウェアリソースに関連するメトリックをグループ化
  • Databases & Remote Services:応答時間、負荷、またはエラーに関連するメトリックをデータベースおよびその他のバックエンドでグループ化
  • Advanced Network:PIE(パフォーマンス影響イベント)、ゼロウィンドウ、データ再送信、エラーなど、ネットワーク可視性に関連するメトリックをグループ化
  • Error Rates:例外、復帰コード、およびその他のエラーに関連するメトリックをアプリケーションまたはティアでグループ化
  • Information Points:応答時間、負荷、またはエラーなどのメトリックをインフォメーションポイントでグループ化
  • Service Endpoints:Java および .NET のみ。平均応答時間、毎分のコール、および毎分のエラーなどのメトリックをサービスエンドポイントでグループ化
  • Custom:エージェントで収集されて、単一のビジネストランザクション、単一のノード、または全体的なアプリケーション パフォーマンスに影響を与える可能性のあるすべてのメトリックを表示。このタイプを使用して、カスタムメトリックを評価するルールを作成。

これらの正常性ルールのタイプから 1 つを選択すると、ウィザードにより埋め込みブラウザ内で該当するタイプに関連する一般的なメトリックが提供されます。

正常性ルールを設定する方法

AppDynamics では、アプリケーションに対する正常性ルールの設定には次の手順をおすすめしています。

  1. モニタリングの必要がある主要なエンティティの主要なメトリック(パフォーマンス指標)を特定。
  2. Alert & Respond > Health Rules をクリックして、AppDynamics により提供されているデフォルトの正常性ルールをすべて確認。
    • 自分のメトリックリストと、デフォルトルール用に構成されたメトリックを比較。
    • デフォルトの各正常性ルールについて、影響を受けるエンティティのリストを表示し、エンティティを修正することが可能。詳細については、影響されたエンティティの構成を参照してください。
    • デフォルトの正常性ルールが必要なすべての主要メトリックを対象としている場合、事前設定された条件を自分の環境へ適用可能にするかを決定。必要に応じて、条件を変更

      条件に対し複雑な基準を評価するためのメトリック式を定義。

      複数の正常性ルール条件を評価するブール式を定義。

  3. デフォルトの正常性ルールがすべての要件に対して不十分な場合、または特定のユースケースに対応する厳密な正常性ルールが必要な場合は、新しい正常性ルールを作成
    1. 作成したい正常性ルールのタイプを特定する。詳細については、Health Rule Typesを参照してください。
    2. 新しいルールにより影響を受けるエンティティを決定する。「正常性ルールに影響を受けるエンティティ」を参照してください。
    3. モニタリングの条件を定義する。詳細については、条件の作成および設定を参照してください。
  4. 事前定義されたタイムスケジュールに従って正常性ルールを評価する場合は、正常性ルールのスケジュールを作成する。場合によっては、特定の時期に評価すると正常性ルールがさらに有効になります。「正常性ルールのスケジュール」を参照してください。

正常性ルールの設定後、正常性ルールの違反時に実行するポリシーおよびアクションを構成する必要があります。「ポリシー」および「アクション」を参照してください。

その他の注意事項

  • アプリケーションのステータスは、現在の時間範囲の正常性ルールに基づいています。古い正常性ルールポリシーを無効にするか、または新しいポリシーを有効にすると、新しいポリシーに基づく現在重大なイベントがない場合でも、アプリケーションのステータスに赤のエラーが表示されることがあります。新しいまたは無効な正常性ルールポリシーが有効になっていることを確認するには、ダッシュボードの時間範囲を、より小さく、より新しいタイムフレームに変更します。

  • 設定した条件でベースラインスが選択され、25msなど非常に速い平均応答時間(ART)を持つビジネストランザクションの正常性ルールを設定する場合、基準として標準偏差を使用すると、頻繁に正常性ルールの違反が生じることがあります。頻繁に正常性ルールの違反が生じるのは、応答時間のわずかな増加が複数の標準偏差に当てはまることがあるためです。この場合、基準として最小のARTを設定した2つ目の条件を追加することを検討してください。たとえば、ARTが50msを上回ったときのみ通知を受け取る場合は、基準をART > 2標準偏差およびART > 50 msに設定します。
  • 同様に、設定された条件でベースラインが選択される、1秒あたりのコール(CPM)メトリックの正常性ルールを構成する時は、条件で標準偏差が使用されており、結果の値が0以下だと正常性ルール違反が起こらない可能性があります。この場合は、0の値にチェックを入れた2つ目の条件を追加することを検討してください(例えば、 CPM < 2標準偏差およびCPM < 1)。