シナリオ：KaiがSplunk APMのサービスマップを使用してエラーの根本原因を調査する 🔗
Buttercup Gamesのサイト信頼性エンジニアであるKaiは、Buttercup Gamesのウェブサイトでゲームを購入する際に「無効なリクエスト」のエラーが発生したという複数の顧客からのチケットを受け取っています。
無効なリクエストのエラーレポートをトラブルシュートするために、Kaiは以下の手順を踏みます：
Kaiがサービスマップを開く 🔗
To investigate the downstream service causing the error, Kai searches for 「service map」 and selects the navigation item in the search results to go directly to the Service Map in APM. Kai looks through the real-time service map, which contains nodes and dependencies of services instrumented in 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 に送信する を参照してください。