異常のトラブルシューティング
逸脱検知と根本原因の自動分析を効果的に使用するための手法を実証するために、この例では、根本原因が確認されるまで異常が発生します。トラブルシューティング プロセスは、異常を表示する複数の方法のいずれかから開始できます。異常のモニタリングこの例では、 ページから開始することを前提としています。
異常の詳しい調査
- [アラートと対応（Alert & Respond）] > [逸脱検知（Anomaly Detection）]で、[逸脱（Anomalies）] タブを表示します。
- 異常をダブルクリックして詳細ビューを開きます。
最初は、異常の開始時間中に発生しているすべての情報がページに表示されます。異常のライフサイクルで起きた変化を後で確認するには、タイムラインに沿ってイベントをクリックします。
異常の説明確認
異常の説明では、ビジネストランザクション、選択した状態遷移イベントのシビラティ（重大度）、および上位の偏差ビジネス トランザクション メトリックに関連する異常の内容が通知されます。
この例では、次のようになります。
- ビジネストランザクション：
/r/Checkout - シビラティ（重大度）：Critical
- 上位の偏差メトリック：平均応答時間
偏差メトリックは、チェックアウトの応答が遅いことが問題であることを示す平均応答時間です。
タイムラインの確認
状態遷移イベントでは、異常が [Warning] と [Critical] の状態の間を移動した瞬間がマークされます。
- この例のタイムラインは [Critical] 状態から始まり、その 30 分後に [Warning] 状態に移行します。これは 8 分間しか続きません。
- この単純な異常は [重大（Critical）] 状態から開始され、そのライフサイクルのほとんどで継続するため、最初のイベントから知っておく必要があります。
対照的に、より複雑なタイムラインで表示されるパターンは、異常を理解するのに役立ちます。たとえば、別の異常のこのタイムラインは、短い [警告（Warning）] 状態からより長い [重大（Critical）] 状態に繰り返し切り替わります。
このような場合は、いくつかの状態変更イベントを調査して、アプリケーションの問題について、状態間の遷移によってどのような手掛かりが提供されるかを確認する必要があります。
フローマップの調査
フローマップの例には、次が含まれます。
- START ラベルには、ビジネストランザクションが OrderService 階層から始まることが示されます。
- [OrderService] 階層とその多数の依存関係の間で、2 つの階層が赤色です。これらはシステムが疑わしい原因を検出した階層です。
これで、どちらの赤色の階層が異常の根本原因になっているかを特定することに重点を置くことができます。
最も疑わしい原因の調査
[上位の疑わしい原因（Top Suspected Causes）] には、ビジネストランザクションのパフォーマンス上の問題の考えられる根本原因が表示されます。異常の原因を特定するため、コールパスにおいて以下のエンティティまで遡って確認できます。
支払いサービス、注文サービスなどのサービス
データベースバックエンド、HTTP バックエンドなどのバックエンド
クロスアプリケーション
インフラストラクチャ マシン エンティティ サーバー
次の例では、ビジネストランザクション /order がエラーをスローしている理由を知る必要があります。最初の疑わしい原因は、Frontend15novaauto のフロントエンドの問題です。
疑わしい原因にカーソルを合わせると、フローマップ内の関連エンティティが強調表示されます。クリティカルパス以外のすべてがフェードアウトし、ビジネストランザクションが開始され、1 分あたりのエラー数メトリックに異常があった ApacheWebServer が Frontend15novaauto に依存していることが明らかになります。
疑わしい原因を詳しく調査する
[詳細（More Details）] をクリックして、疑わしい原因を確認します。
- 簡素化されたタイムライン
- 経時的にグラフ化されたメトリック
次の 2 種類のグラフ化されたメトリックが表示されます。
- ビジネストランザクションの上位偏差メトリック
- 疑わしい原因のメトリック
ビジネストランザクションの上位偏差メトリックの調査
偏差ビジネス トランザクション メトリックでは、異常が十分重要である理由を示すことができます。（システムでは、メトリックのすべての一時的またはわずかな偏差の異常は表示されません。そのような異常は、お客様への影響が最小限であるため、疑わしい値になります。同じ理由により、CPM が 20 未満のビジネストランザクションの異常が表示されます。）
各偏差メトリックは、幅の広い灰色の帯域（メトリックの予想範囲）に対して、細い青色の線（メトリックの値）として表示されます。
次の操作を実行できます。
- グラフに沿ってスクロールし、メトリックの値を任意の時点で予想される範囲と比較します。
- メトリックの値と予想される範囲を数値形式で表示するには、ある時点にカーソルを合わせます。
この例では：
- 偏差メトリック（1 分あたりのエラー数）が急上昇し、約 50 分間（7:45 AM ～ 8:35 AM）継続してから、予想される範囲に収束します。
- メトリックが予想される範囲に戻ってから 6 分後に、シビラティ（重大度）レベルが [Critical] から [Warning] に変わり、12 分後に [Normal] になります。
時間ポイントにカーソルを合わせると、偏差の期間が表示されます。1 分あたりのエラー数は約 16 以上で、予想される範囲は 0 ～ 13.5 でした。このような重要なメトリックを大量に使用することで、システムによってこの異常が表示される理由がわかります。
[上位逸脱メトリック（Top Deviating Metrics）] タイムラインには、異常の評価期間も灰色で表示されます。評価期間は、異常を検出するためにデータが分析される期間です。このタイムラインは、問題が発生した時刻を正確に特定するのに役立ちます。次の図は、評価期間を示しています。
疑わしい原因のメトリックの調査
上位の偏差メトリックと同様に、疑わしい原因メトリックを表示、スクロール、およびカーソルを合わせて表示します。
たとえば、Frontend15novaauto の疑わしい原因のメトリックが表示されます。MemoryUsed% メトリックの予想範囲は 0 ～ 4.5% ですが、値は 8% で、予想される範囲を超えています。これが異常の根本原因です。
成果
逸脱検知と根本原因の自動分析を使用して、ビジネストランザクションのパフォーマンス上の問題の根本原因を迅速に特定しました。この場合、逸脱検知および根本原因の自動分析に費やした時間と労力はどのくらいだったと思いますか。
ビジネストランザクションが開始された階層、/order には、複数のサービスを含む依存関係があることを思い出してください。逸脱検知と根本原因の自動分析により、最も関連性の高い階層と、問題の発生源としてその階層で最も重要なメトリックが特定されました。
それぞれの依存関係について、複数のメトリックを調査する面倒なプロセスが軽減されました。その代わりに、タイムライン、フローマップ、およびメトリックの概要を一目で見て、疑わしい原因を確認または否定しました。逸脱検知および根本原因の自動分析により、仮説を迅速に形成および確認するための必要な情報が提供され、根本原因分析のほとんどの作業が行われました。
（オプション）スナップショットの検査とアクションの実行
異常が表示された場合は、以下の内容を検査できます。
- 異常期間内のビジネス トランザクション スナップショット。
- ビジネストランザクションに設定したポリシーの結果として実行されるアクション。
これらは標準のトラブルシューティング フローのオプションです。通常、これらはフォローアップとして実行されます。
この例では：
フロントエンド 15novaautoのMemoryUsed%の問題について、より多くのコンテキストが必要だとします。この問題の影響を受けるトランザクションのスナップショットを表示できます。リスト内のスナップショットをダブルクリックして、独自のペインで開き、必要に応じて詳細とコールグラフにドリルダウンします。- 異常の発生時にチケットシステムにメッセージを送信するのが一般的です。この場合、Slack にメッセージを送信し、運用チームが自分の電話機で確認できるようにします。