関連トピック：

異常検知と根本原因の自動分析を効果的に使用するための手法を実証するために、この例では、根本原因が確認されるまで異常が発生します。トラブルシューティング プロセスは、異常を表示する複数の方法のいずれかから開始できます。この例では、[Alert & Respond > Anomaly Detection ] ページから開始することを前提としています。

異常検知と根本原因の自動分析は SaaS のお客様のみが使用できます。

異常の詳しい調査

  • [In Alert & Respond > Anomaly Detection] で、[Anomalies] タブを表示します。 
  • 異常をダブルクリックして詳細ビューを開きます。

最初は、異常の開始時間中に発生しているすべての情報がページに表示されます。異常のライフサイクルでどのような変化が起こっているかを確認するには、タイムラインに沿ってイベントをクリックします。 

異常の説明確認

異常の説明では、ビジネストランザクション、選択した状態遷移イベントのシビラティ（重大度）、および上位の偏差ビジネス トランザクション メトリックに関連する異常の内容が通知されます。

この例では、次のようになります。

  • ビジネストランザクション：/r/Checkout
  • シビラティ（重大度）：Critical
  • 上位の偏差メトリック：平均応答時間

この場合、偏差メトリックは、チェックアウトの応答が遅いことが問題であることを示す平均応答時間です。 

タイムラインの確認

状態遷移イベントでは、異常が [Warning] と [Critical] の状態の間を移動した瞬間がマークされます。

  • この例のタイムラインは [Critical] 状態から始まり、その 30 分後に [Warning] 状態に移行します。これは 8 分間しか続きません。
  • この単純な異常は [Critical] 状態から開始され、そのライフサイクルのほとんどで継続するため、最初のイベントから知っておく必要があります。

Critical to Warning Timeline

対照的に、より複雑なタイムラインで表示されるパターンは、異常を理解するのに役立ちます。たとえば、別の異常のこのタイムラインは、短い [Warning] 状態からより長い [Critical] 状態に繰り返し切り替わります。

このような場合は、いくつかの状態変更イベントを調査して、アプリケーションの問題について、状態間の遷移によってどのような手掛かりが提供されるかを確認する必要があります。

フローマップの調査

フローマップの例には、次が含まれます。

  • [START] ラベルから、ビジネストランザクションが [OrderService] 階層から始まることがわかります。
  • [OrderService] 階層とその多数の依存関係の間で、2 つの階層が赤色です。これらはシステムが疑わしい原因を検出した階層です。

これで、どちらの赤色の階層が異常の根本原因になっているかを特定することに重点を置くことができます。

異常検知フローマップが異なる

Splunk AppDynamics には次の 2 種類のフローマップがあります。

  • 異常検知と自動 RCA フローマップ（このページで説明）
  • ビジネス トランザクション フローマップ

これらのフローマップはそれぞれ、偏差または異常なエンティティを独自の方法で検出します。そのため、次のような違いがあります。

  • 2 つのフローマップでは、同じエンティティに対して異なる正常性ステータス（色で表現）が表示されることがあります。これは、それぞれが独自のアルゴリズムを使用して正常性を判断するためです。
  • ビジネス トランザクション フロー マップに保存されたエンティティの配置または非表示のユーザ設定は、異常検知フローマップには影響しません。
  • ティア間の一部のリンクは、1 つのタイプのフローマップに表示されますが、他方では非表示になります。
    • たとえば、データがティアやティア間をフローしていない場合は、次のようになります。
      • ビジネス トランザクション フロー マップによって、「非アクティブ」階層またはリンクとして非表示にされる場合があります。
      • 異常検知フローマップによって、アプリケーショントポロジを完全に示すために表示される場合があります。

最も疑わしい原因の調査

最も疑わしい原因として、ビジネストランザクションのパフォーマンス上の問題の根本原因が考えられます。この場合、チェックアウトの応答が遅い理由を知る必要があります。

最初の疑わしい原因として考えられるのは、PaymentService1 階層の eretail.prod.payment01_1 ノードでのプロセス CPU の書き込みに関する問題です。

疑わしい原因にカーソルを合わせると、フローマップ内の関連エンティティが強調表示されます。クリティカルパス以外のすべてがフェードアウトし、ビジネストランザクションが開始され、応答時間が低下した OrderService が PaymentService1 に依存していることが明らかになります。

Top Suspected Cause

2 番目の疑わしい原因は、OrderService 自体の HTTP コールです。 

影響を受けるエンティティを強調表示するには、カーソルを合わせます。

根本原因となる疑わしい原因はどれか？全体的な問題となっている唯一の症状はどれか？

  • PaymentService1 階層でのプロセス CPU の書き込みに関する問題に有力な根本原因があり、システムによって最も可能性が高いとランク付けされています。
  • 一方、OrderService の HTTP コールは、次のように分析されます。
    • HTTP コールには、要求と応答の両方が含まれます
    • 他方のエンドである PaymentService1 の階層には独自の問題があることがわかっています
    • そのため、PaymentService1 からの HTTP 応答がコールの速度を低下させていると推測できます

次に、疑わしい原因の両方が PaymentService1 によって発生し、HTTP コールの問題がプロセス CPU の書き込みに関する問題の副次的な影響を受けていることがわかります。システムのランキングは理にかなっています。

調査を続行して、プロセスの CPU の書き込みに関する問題が根本的な原因ではないと判断した場合は、HTTP コールを再検討できます。

ゼロから上位 3 つの疑わしい原因になる可能性があります。たとえば、ART が高くても、ART に接続されているすべてのエンティティが正常に動作している場合は、疑わしい原因が特定されないため、原因がゼロになります。

疑わしい原因を詳しく調査する

[More Details] をクリックして、疑わしい原因を確認します。

  • 簡素化されたタイムライン
  • 経時的にグラフ化されたメトリック

次の 2 種類のグラフ化されたメトリックが表示されます。

  • Top Deviating Metricsビジネストランザクションの場合
  • Suspected Cause Metrics

ビジネストランザクションの上位偏差メトリックの調査

偏差ビジネス トランザクション メトリックは、異常が十分に重要である理由を示すことができます。（システムでは、メトリックのすべての一時的またはわずかな偏差の異常は表示されません。このような異常は、お客様への影響が最小限であるため、疑わしい値になります。同じ理由により、CPM が 20 未満のビジネストランザクションの異常が表示されます。）

各偏差メトリックは、幅の広い灰色の帯域（メトリックの予想範囲）に対して、細い青色の線（メトリックの値）として表示されます。

方法は以下のとおりです。

  • グラフに沿ってスクロールし、メトリックの値を任意の時点で期待される範囲と比較します。
  • メトリックの値と予想される範囲を数値形式で表示するには、時間ポイントにカーソルを合わせます。

予想される範囲が偏差メトリック値よりもはるかに小さくなり、灰色の帯域が X 軸に「消える」場合、カーソルを合わせて数値形式で値を確認することが重要です。 

この例では、以下のようになっています。

  • 偏差メトリックが急上昇し、約 30 分間継続してから、予想される範囲に収束します。
  • メトリックが予想される範囲に戻ってから 7 分後に、シビラティ（重大度）レベルが [Critical] から [Warning] に変わり、その 8 分後に [Normal] になります。

時刻にカーソルを合わせると、偏差の期間が表示されます。平均応答時間は 1200 ミリ秒を超えていましたが、予想される範囲は 370.08 ～ 721.24 ミリ秒でした

このような重要なメトリックを大量に使用することで、システムによってこの異常が表示される理由がわかります。

上位の偏差メトリックはビジネス トランザクション レベルであるため、疑わしいすべての原因で同じです。

[Top Deviating Metrics] タイムラインには、異常の評価期間も灰色で表示されます。評価期間は、異常を検出するためにデータが分析される期間です。このタイムラインは、問題が発生した時刻を正確に特定するのに役立ちます。次の図は、評価期間を示しています。

疑わしい原因のメトリックの調査

上位の偏差メトリックと同様に、疑わしい原因メトリックを表示、スクロール、およびカーソルを合わせて表示します。

上位の偏差メトリックはビジネストランザクションを表していますが、疑わしい原因のメトリックは、エンティティツリー内でさらに下位のティアまたはノードを示しています。つまり、ART が上位の偏差メトリックであり、疑わしい原因となるメトリックである場合、これらは 2 つの異なるメトリックになります。同様に、EPM を上位の偏差メトリックとして、および疑わしい原因メトリックとしても、2 つの異なるメトリックがあります。

疑わしい原因のメトリックは、上位の偏差メトリックの動作方法に起因する可能性がありますが、2 つのメトリックの値は異なります。

この例では―

  • ProcessPayment1 階層内の eretail.prod.payment01_1 ノードについて、疑わしい原因のメトリックが表示されます
  • これはティアに含まれている唯一のノードで、ティアに複数のノードがある場合、各ノードで個別にメトリックを表示できます
  • プロセス CPU の書き込みとプロセス CPU で使用されるメトリックの上昇パターンは、ビジネス トランザクション メトリックで表示されるパターンと完全に一致します

Suspected Cause Metric

これで、仮説が次のように確認できます。

  1. CPU 使用率が ProcessPayment1（ビジネストランザクションが開始された階層から下流にある階層）で急上昇しました
  2. これにより、OrderService からの HTTP 要求に対する HTTP 応答を含む、ProcessPayment1 の応答時間が低下しました
  3. HTTP コールが遅くなった結果、OrderService での応答時間が遅くなりました
  4. OrderService でチェックアウト ビジネス トランザクションが開始されるため、チェックアウトで応答時間が遅くなる異常が発生します
  5. ProcessPayment1 におけるプロセス CPU の書き込みに関する問題は、エンティティツリー内で最も深い原因である可能性があります。これは異常の根本原因です

結果

異常検知と根本原因の自動分析を使用して、ビジネストランザクションのパフォーマンス上の問題の根本原因を迅速に特定しました。この場合、異常検知および根本原因の自動分析に費やした時間と労力はどのくらいだったと思いますか。

ビジネストランザクションが開始された階層、OrderService には、他のサービスおよびデータストアを含む複数の依存関係があることを思い出してください。異常検知および根本原因の自動分析により、（1）OrderService での応答時間の低下の原因として 2 つの階層以外のすべてが取り除かれ、（2）それらの階層に関連する多くのメトリック以外のすべてが取り除かれました。 

それぞれの依存関係について、複数のメトリックを調査する面倒なプロセスが軽減されました。その代わりに、タイムライン、フローマップ、およびメトリックの概要を一目で見て、疑わしい原因を確認または否定しました。異常検知および根本原因の自動分析により、仮説を迅速に形成および確認するための必要な情報が提供され、根本原因分析のほとんどの作業が行われました。

（オプション）スナップショットの検査とアクションの実行

異常が表示された場合は、次を検査できます。

  • 異常の期間内のビジネス トランザクション スナップショット
  • ビジネストランザクションに設定したポリシーの結果として実行されるアクション

これらは標準のトラブルシューティング フローのオプションです。通常、これらはフォローアップとして実行されます。

この例では、以下のようになっています。

  • PaymentService1 のプロセス CPU の書き込みの問題について、コンテキストを増やす必要があると考えています。この問題の影響を受けるトランザクションのスナップショットを表示できます。リスト内のスナップショットをダブルクリックして、独自のペインで開き、必要に応じて詳細とコールグラフにドリルダウンします。
  • 異常の発生時にチケットシステムにメッセージを送信するのが一般的です。この場合、運用チームが自分の電話機でそのことを確認できるように、Slack に送信しました。