シナリオ：KaiがSplunk APMのサービスマップを使用してエラーの根本原因を調査する 🔗
Buttercup Gamesのサイト信頼性エンジニアであるKaiは、Buttercup Gamesのウェブサイトでゲームを購入する際に「無効なリクエスト」のエラーが発生したという複数の顧客からのチケットを受け取っています。
無効なリクエストのエラーレポートをトラブルシュートするために、Kaiは以下の手順を踏みます：
Kaiがサービスマップを開く 🔗
エラーの原因となっているダウンストリームサービスを調査するため、Kaiは「サービスマップ」と検索し、検索結果のナビゲーション項目を選択してAPMのサービスマップに直接移動します。そして、Splunk APMにインストルメントされているサービスのノードと依存関係を含むリアルタイムのサービスマップに目を通します。
Kaiが根本原因エラーを持つサービスを探る 🔗
サービスマップでは赤色を使って根本原因エラー率を識別しています。Kaiは、 paymentservice のノードに赤い点があり、checkoutservice ノードから paymentservice ノードへの依存関係の矢印が赤色であることを確認します。
Kaiがサービスを選択して詳細情報を収集する 🔗
Kaiは paymentservice ノードを選択し、Tag Spotlightサイドバーでエラー率が最も高いエンドポイントを検出します。次のスクリーンショットに示すように、すべてのエラーが1つのエンドポイントで発生していることが分かりました：
Kaiが問題のあるエンドポイントのTag Spotlightへのリンクをカスタマーチケットに追加する 🔗
Kaiは、このエンドポイントのTag Spotlightへのリンクを取得し、カスタマーチケットに追加するメモにリンクを含めて、このエンドポイントをエラーの根本原因として特定します。チケットを決済サービスのオーナーに送信して、さらなるトラブルシューティングを促します。
まとめ 🔗
Kaiはサービスマップを使用して、根本原因エラー率が高いサービスをすばやく切り分け、顧客が報告している無効なリクエストのエラーの原因である可能性が高いサービスを特定しました。Kaiは、さらなるトラブルシューティングのために、この情報をサービスオーナーと共有しました。
さらに詳しく 🔗
Splunk APMのサービスマップの詳細については、サービスマップでサービス間の依存関係を表示する を参照してください。
アプリケーションのメトリクスとトレースをSplunk Observability Cloudに送信するためのアプリケーションのインストルメンテーション方法については、バックエンドアプリケーションをインストルメンテーションして、スパンを Splunk APM に送信する を参照してください。