Splunk4Rookies ワークショップ

2. ログエントリの確認

2 min

特定のログ行を確認する前に、これまでに行ったことと、Observability の3本柱に基づいてなぜここにいるのかを簡単に振り返りましょう

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

メトリクスを使用して、アプリケーションに問題があることを特定しました。これは Service Dashboards のエラーレートが想定よりも高かったことから明らかでした。
トレースとスパンタグを使用して、問題がどこにあるかを発見しました。wire-transfer-service は v350.9 と v350.10 の2つのバージョンで構成されており、v350.10 のエラーレートは 100% でした。
wire-transfer-service v350.10 からのこのエラーが、複数回のリトライとコンプライアンスチェックサービスからのレスポンスの大幅な遅延を引き起こしていることを確認しました。
トレースから Related Content の機能を使用して、障害が発生している wire-transfer-service バージョンのログエントリに到達しました。これで、問題が何であるかを特定できます。

Exercise

ログテーブルのエラーエントリをクリックします（リストに別のサービスからのまれなエラーがある場合に備えて、hostname: "wire-transfer-service-xxxx" と表示されていることを確認してください）。

このメッセージに基づいて、問題を解決するために開発チームに何をするよう伝えますか？

開発チームは有効な API Token でコンテナを再ビルドしてデプロイするか、v350.9 にロールバックする必要があります。

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

Congratulations

Splunk Observability Cloud を正常に使用して、ユーザーが送金サービスの利用中に問題を経験している理由を理解しました。Splunk APM と Splunk Log Observer を使用して、サービスランドスケープで何が起こったかを理解し、Observability の3本柱であるメトリクス、トレース、ログに基づいて根本原因を発見しました。

また、Splunk のインテリジェントなタグ付けと分析を Tag Spotlight で使用してアプリケーションの動作パターンを検出する方法と、Related Content のフルスタック相関機能を使用して、問題のコンテキストを維持しながら異なるコンポーネントとテレメトリ間を素早く移動する方法を学びました。

ワークショップの次のパートでは、問題発見モードから緩和、予防、プロセス改善モードに移行します。

次は、カスタムダッシュボードでのログチャートの作成です。