あなたはバックエンドの開発者で、SRE によって発見された問題の調査を支援するように呼ばれました。SRE はユーザーエクスペリエンスが悪いと特定し、その問題の調査をお願いしています。
RUM トレース（フロントエンド）から APM トレース（バックエンド）にジャンプすることで、完全な End to End の可視性の力を理解できるでしょう。すべてのサービスが Splunk Observability Cloud によって視覚化、分析、異常およびエラーの検出が可能となるテレメトリ（トレースやスパン）を送信しています。
RUM と APM は同じコインの両側面です。RUM はアプリケーションのクライアント側のビューであり、APM はサーバー側のビューです。このセクションでは、APM を使用してどこに問題が潜んでいるかドリルダウンし、特定します。
APM サービスマップは、APM で計装されたサービス、および、存在が推測されるサービス間の依存関係とつながりを表示します。このマップは、時間範囲、環境、ワークフロー、サービス、およびタグのフィルタで選択した内容に基づいて動的に生成されます。
RUM ウォーターフォールで APM リンクをクリックすると、サービスマップビューに自動的にフィルタが追加され、その Workflow Name（frontend:/cart/checkout）に関与したサービスが表示されます。
Service Map でワークフローに関係するサービスが表示されます。画面右側の Business Workflow の下には、選択したワークフローのチャートが表示されます。Service Map と Business Workflow のチャートは同期されています。Service Map 内であるサービスを選択すると、Business Workflow ペインのチャートが更新され、選択したサービスのメトリクスが表示されます。
Splunk APM は、発生している問題をリアルタイムに確認し、特定のサービス、特定のエンドポイント、またはこれらを支えるインフラストラクチャに関連しているかどうかを迅速に判断するために利用できる、メトリクスをチャートとして可視化する一連の組み込みダッシュボードを提供しています。これを詳しく見てみましょう。
APM サービスダッシュボードは、サービス、エンドポイント、および Business Workflow のエンドポイントスパンから生成されたモニタリングメトリクセットに基づいて、リクエスト、エラー、および所要時間（RED）メトリクスを提供します。ダッシュボードを下にスクロールすると、基盤や Kubernetes に関連するメトリクスも表示され、インフラストラクチャに問題があるかどうかを判断するのに役立ちます。
サービスマップで paymentservice の上にカーソルを合わせてください。ポップアップして表示されたサービスに関するチャートからどんなことがわかりますか？
エラー率が非常に高いです。
このエラー率にパターンがあるかどうかを理解する必要があります。そのためには、Tag Spotlight が便利です。
Tag Spotlight には、2つの表示モードがあります。デフォルトは Request/Errors で、もう1つは Latency です。
Request/Error チャートでは、リクエストの合計数、エラーの合計数、および根本原因のエラーが表示されます。Latency チャートでは、p50、p90、および p99 のレイテンシが表示されます。これらの値は、Splunk APM がインデックス化された各スパンタグに対して生成する Troubleshooting MetricSets（TMS）に基づいています。これらは RED メトリクス（リクエスト、エラー、および所要時間）として知られています。
どのチャートが問題を特定するタグでしょうか？
version チャートです。v350.10 に対するリクエストの数はエラーの数と一致しています。
tenant.level を選択します。これは顧客のステータスを表すタグであり、顧客のステータスに関連するトレンドを見るのに役立ちます。version を選択します。これはサービスのバージョンを示すタグです。確認できた内容から、どんな結論を得ることができますか？
すべてのテナントがバージョン v350.10 による影響を受けている
paymentservice が gold、silver、bronze の3つのサービスに分けて表示されていることが分かるでしょう。各テナントはバージョン (v350.10 と v350.9) ごとのサービスに分けられています。
スパンに付与されるタグに基づいてサービスの分析は非常に強力な機能です。これにより、異なる顧客、異なるバージョン、異なる地域などに対するサービスのパフォーマンスを確認できます。この演習では、paymentservice の v350.10 がすべての顧客に問題を引き起こしていることが判明しました。
次に、トレースを詳細に調査して問題の原因を見つける必要があります。
Splunk APM では、NoSample™ の End to End の可視性が提供され、すべてのサービスのトレースがキャプチャされます。このワークショップでは、Order Confirmation ID がタグとして利用可能です。これにより、ワークショップの前半で遭遇したユーザーエクスペリエンスの問題のトレースを正確に検索できます。
Splunk Observability Cloud は、アプリケーションモニタリングデータを探索するための複数のツールを提供しています。Trace Analyzer は、未知の問題や新しい問題を調査するために高カーディナリティで粒度の細かなデータを検索・探索するシナリオに適しています。
1:10 ではなく 1:1 に設定されていることを確認します。orderId を入力し、リストから orderId を選択します。
これで、あなたが体験した、チェックアウト処理で長時間待たされユーザーエクスペリエンスを損ねていた処理のトレースを絞り込むことができました。このトレースは最大13ヶ月間アクセスすることができます。そのため、例えば、開発者は後日この問題に再び取り組む際にも、このトレースを確認できるでしょう。
次に、トレースのウォーターフォールを見ていきましょう。
Trace Analyzer から Trace Waterfall に移動しました。トレースは、同じトレース ID を共有するスパンの集合であり、アプリケーションとその構成サービスによって処理される一意のトランザクションを表します。
Splunk APM の各スパンは、単一の操作をキャプチャします。Splunk APM は、スパンに記録された操作がエラーとなった場合、スパンをエラースパンと見なします。
paymentservice:grpc.hipstershop.PaymentService/Charge スパンの隣にある ! をクリックします。スパンのメタデータに記録されているエラーメッセージとバージョンは何ですか？
Invalid Request と v350.10 です。
問題を引き起こしている paymentservice のバージョンを既に特定しているので、エラーに関してより詳細な情報を見つけられるか、やってみましょう。ここで Related logs が役立ちます。
関連するコンテンツは、特定のメタデータによって実現されており、これにより、APM, Infrastructure Monitoring, Log Observer が Splunk Observability Cloud 内でフィルター条件を共有することで可能になっています。Related Logs が機能するには、ログに次のメタデータが必要です。
service.namedeployment.environmenthost.nametrace_idspan_id