異常の詳しい調査

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

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

異常の説明確認

異常の説明では、エンティティ(ビジネストランザクション、データベース、ベース ページ エクスペリエンス、またはネットワークリクエスト)に関連する異常を示します。異常に関する選択した状態遷移イベントの重大度レベルと、エンティティに関連する上位逸脱メトリックが示されます。

この例では、次のことを分析します。

  • ビジネストランザクション:/web-api/getDepositSummary
  • シビラティ(重大度):Critical
  • 上位の偏差メトリック:平均応答時間

逸脱メトリックは、チェックアウトの応答が遅いことが問題であることを示す Average Response Time です。

タイムラインの確認

タイムラインは、異常が最初に検出されてから解決されるまでに経過するさまざまな段階を視覚的に表します。異常を検出するためにデータがアクティブに分析されている期間は、評価ウィンドウを示すグレーで強調表示されます。評価期間は、異常を検出するためにデータが分析される期間です。このタイムラインを使用すると、異常が始まった正確な時点を特定できます。タイムライン上の特定のマーカーは、異常の状態が移行するタイミング([警告(Warning)] から [重大(Critical)] への移行など)を示し、問題の進行を詳細に追跡するのに役立ちます。

たとえば、このタイムラインは [重大(Critical)] 状態から始まり、その 35 分後に [警告(Warning)] 状態に移行します。この状態は 10 分間しか続きません。

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

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

フローマップの調査

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

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

これで、異常の根本原因が含まれている赤色の階層に重点を置くことができます。

最も疑わしい原因の調査

[Suspected root causes] タブには、ビジネストランザクション、ベースページ、データベース、およびネットワークリクエストに関連するパフォーマンス上の問題の考えられる根本原因が表示されます。異常の原因を特定するため、コールパスにおいて以下のエンティティまで遡って確認できます。

  • 支払いサービス、注文サービスなどのサービス

  • データベースバックエンド、HTTP バックエンドなどのバックエンド

  • クロスアプリケーション

  • インフラストラクチャ マシン エンティティ サーバー

次の例では、ビジネストランザクション /web-api/getDepositSummary がエラーをスローしている理由を特定する必要があります。[Summary| AI-generated] には、影響を受けるビジネストランザクション、異常の開始時刻と終了時刻、異常の状態(重大、警告など)、逸脱メトリックの詳細など、問題の簡単な説明が表示されます。AppDynamics SaaS は、AI を活用して、異常に関連付けられたすべてのメトリックを相互に関連付け、サマリーを生成します。この包括的なサマリーは、問題をより深く理解するのに役立ちます。

注: AI が生成したサマリーは、ビジネストランザクションとデータベースに関連する異常についてのみ利用できます。

[View suspected cause]