あなたはバックエンド開発者で、SRE が発見した問題の調査を手伝うよう依頼されました。SRE はユーザーエクスペリエンスの低下を特定し、あなたにその問題を調査するよう依頼しました。
RUM トレース（フロントエンド）から APM トレース（バックエンド）にジャンプすることで、完全なエンドツーエンドの可視性の力を発見します。すべてのサービスはテレメトリ（トレースとスパン）を送信しており、Splunk Observability Cloud はこれを視覚化、分析し、異常やエラーを検出するために使用できます。
RUM と APM は同じコインの表と裏です。RUM はアプリケーションのクライアント側からの視点であり、APM はサーバー側からの視点です。このセクションでは、APM を使用して掘り下げ、問題がどこにあるかを特定します。
APM サービスマップは、APM で計装された（インストルメンテーション）サービスと推測されるサービスの間の依存関係と接続を表示します。このマップは、時間範囲、環境、ワークフロー、サービス、タグフィルターでの選択に基づいて動的に生成されます。
RUM ウォーターフォールで APM リンクをクリックすると、そのワークフロー名（frontend:/cart/checkout）に関連するサービスを表示するために、サービスマップビューに自動的にフィルターが追加されました。
ワークフローに関連するサービスはService Mapで確認できます。サイドペインのBusiness Workflowの下には、選択したワークフローのチャートが表示されています。Service Mapとビジネスワークフローチャートは同期しています。Service Mapでサービスを選択すると、Business Workflowペインのチャートが更新され、選択したサービスのメトリクスが表示されます。
Splunk APM はまた、リアルタイムで発生している問題を確認し、問題がサービス、特定のエンドポイント、または基盤となるインフラストラクチャに関連しているかどうかを迅速に判断するのに役立つ組み込みの Service Centric View(サービス中心ビュー) も提供しています。より詳しく見てみましょう。
サービスオーナーとして、Splunk APM のサービスビューを使用して、単一のパネルでサービスの健全性の完全なビューを取得できます。サービスビューには、可用性、依存関係、リクエスト、エラー、および期間（RED）メトリクス、ランタイムメトリクス、インフラストラクチャメトリクス、Tag Spotlight、エンドポイント、および選択したサービスのログのためのサービスレベルインジケーター（SLI）が含まれています。また、サービスビューからサービスのコードプロファイリングとメモリプロファイリングにすぐにアクセスすることもできます。
サービスマップでpaymentserviceの上にカーソルを置いてください。ポップアップサービスチャートからどのような結論を導き出せますか？
エラーの割合が非常に高い。
このエラー率にパターンがあるかどうかを理解する必要があります。そのための便利なツール、Tag Spotlightがあります。
Tag Spotlightのビューは、チャートとカードの両方で設定可能です。デフォルトではリクエストとエラーに設定されています。
また、カードに表示されるタグメトリクスを設定することも可能です。以下の任意の組み合わせを選択できます：
改めて、フィルターアイコンからShow tags with no valuesチェックボックスがオフになっていることを確認してください。
どのカードが問題を特定するタグを明らかにしていますか？
「Version」カードです。v350.10に対するリクエスト数がエラー数と一致しています（つまり 100%）
paymentserviceの問題を引き起こしているバージョンを特定したので、エラーについてさらに詳しい情報が見つかるか確認してみましょう。ページ上部の ← Tag Spotlight をクリックして、サービスマップに戻ります。
tenant.levelを選択します。versionを選択します。これはサービスバージョンを表示するタグです。表示されている内容からどのような結論が導き出せますか？
すべてのtenant.levelがv350.10の影響を受けています
これでpaymentserviceがgold、silver、bronzeの 3 つのサービスに分解されているのが確認できます。各テナントは 2 つのサービスに分解されており、それぞれのバージョン（v350.10とv350.9）に対応しています。
スパンタグを使用してサービスを分解することは非常に強力な機能です。これにより、異なる顧客、異なるバージョン、異なる地域などに対して、サービスがどのようにパフォーマンスを発揮しているかを確認できます。この演習では、paymentserviceのv350.10がすべての顧客に問題を引き起こしていることを特定しました。
次に、何が起きているかを確認するためにトレースを詳しく調べる必要があります。
Splunk APM はすべてのサービスのNoSample（サンプリングなし）エンドツーエンドの可視性を提供するため、Splunk APM はすべてのトレースをキャプチャします。このワークショップでは、Order Confirmation IDがタグとして利用可能です。これは、ワークショップの前半で遭遇した不良なユーザー体験の正確なトレースを検索するためにこれを使用できることを意味します。
Splunk Observability Cloud は、アプリケーション監視データを探索するためのいくつかのツールを提供しています。Trace Analyzerは、未知または新しい問題を調査するための高カーディナリティ、高粒度の検索と探索が必要なシナリオに適しています。
1:10ではなく1:1に設定されていることを確認します。
Trace & Error countビューは、積み上げ棒グラフで合計トレース数とエラーのあるトレース数を表示します。マウスを使用して、利用可能な時間枠内の特定の期間を選択できます。
Trace Durationビューは、期間ごとのトレースのヒートマップを表示します。ヒートマップは 3 次元のデータを表しています：
マウスを使ってヒートマップ上の領域を選択し、特定の時間帯とトレース期間の範囲にフォーカスすることができます。
1:10ではなく1:1に設定されていることを確認します。orderIdと入力してリストからorderIdを選択します。
これで、非常に長いチェックアウト待ちという不良なユーザーエクスペリエンスに遭遇した正確なトレースまでフィルタリングできました。
このトレースを表示することの二次的な利点は、トレースが最大 13 か月間アクセス可能であることです。これにより、開発者は後の段階でこの問題に戻り、このトレースを引き続き表示することができます。
次に、トレースウォーターフォールを確認していきます。
トレースアナライザーからトレースウォーターフォールに到達しました。トレースは同じトレース ID を共有するスパンの集まりで、アプリケーションとその構成サービスによって処理される一意のトランザクションを表します。
Splunk APM の各スパンは、単一の操作をキャプチャします。Splunk APM は、スパンがキャプチャする操作がエラーになった場合、そのスパンをエラースパンとみなします。
スパン詳細で報告されているエラーメッセージとバージョンは何ですか？問題を引き起こしているpaymentserviceのバージョンを特定したので、エラーについてさらに詳しい情報が見つかるか確認してみましょう。ここで関連ログの出番です。
演習
paymentservice:grpc.hipstershop.PaymentService/Chargeスパンの横にある!をクリックします。
Invalid request（無効なリクエスト）とv350.10です。
関連コンテンツ(Related Contents)は、APM、インフラストラクチャモニタリング、および Log Observer が可観測性クラウド全体でフィルターを渡すことを可能にする特定のメタデータに依存しています。関連ログが機能するためには、ログに以下のメタデータが必要です：
service.namedeployment.environmenthost.nametrace_idspan_id
次に、ログのエラーについてさらに詳しく調べてみましょう。