2. ログエントリの参照

特定のログ行を見る前に、これまでに何を行ってきたかと、オブザーバビリティの3本柱に基づいて、なぜここに辿り着いたのかを簡単に振り返りましょう。

Metrics	Traces	Logs
問題があるか？	問題はどこにあるか？	問題は何か？

メトリクスを使用して、アプリケーションに問題があることが判明しました。これは、サービスダッシュボードのエラーレートが本来の状態よりも高かったことから明らかです。
トレースとスパンタグを使用して、問題がどこにあるかを見つけました。 paymentservice は v350.9 と v350.10 の2つのバージョンで構成されており、 v350.10 に対するエラーレートは 100% でした。
バージョン v350.10 の paymentservice から生成されるエラーがオンラインブティックのチェックアウト処理の応答において、複数回の再試行と長時間の遅延を引き起こしていたことを確認しました。
トレースから Related Content の強力な機能を使用して、失敗した paymentservice バージョンのログエントリに到達しました。これにより、問題が 何であるか を特定できるようになりました。

Exercise

Logs tables のエラーエントリをクリックします（異なるサービスからのまれなエラーがある場合は、エントリに hostname: "paymentservice-xxxx" と表示されていることを確認してください）。

メッセージを踏まえ、問題を解決するためには開発チームに何を伝える必要がありますか？

開発チームは、有効なAPIトークンを使用してコンテナを再構築およびデプロイするか、 v350.9 にロールバックする必要があります。

ログメッセージペインの X をクリックして閉じます。

おめでとうございます

Splunk Observability Cloud を使用することで、オンラインブティックでのショッピング中にユーザーエクスペリエンスが悪かった原因を理解することができました。オブザーバビリティの3本柱である メトリクス、トレース、ログに基づいて、RUM、APM、およびログを利用することで、サービス全体で何が起こっており、その後、その根底にある原因を見つけることができました。

また、Splunkが提供する、アプリケーションの振る舞いのパターンを検出する Tag Spotlight によるインテリジェントなタグ付けと分析の機能や、問題のコンテキストを維持しながら異なるコンポーネント間を素早く移動する Related Contents によりスタック全体を相関させる機能についても、その使い方を理解したはずです。

ワークショップの次のパートでは、問題の特定から緩和、予防、およびプロセスの改善に進んでいきます。

次に、カスタムダッシュボードでログチャートを作成します。