引き続き バックエンド開発者 の役割で、アプリケーションのログを調査して問題の原因を特定する必要があります。
APM トレースに関連するコンテンツ（ログ）を使用して、Splunk Log Observer を使用して問題を正確に理解するために、深掘りをしていきます。
Related Content は、1つのコンポーネントから別のコンポーネントにジャンプするための強力な機能で、メトリクス、トレース、および ログ に対して利用できます。
Log Observer (LO) は複数の方法で使用できます。クイックツアーでは、LO ノーコードインターフェース を使用してログの特定のエントリを検索しました。ただし、このセクションでは、APM のトレースから LO に移動したと想定しています。
RUM と APM の間のリンクと同じように、前のアクションのコンテキストを引き継いでログを調査することができるのは一つの利点です。今回の場合、時間枠（1）を見てみると、これはトレースが取得された時間帯と一致しています。また、Filter(2)にも、trace_id の情報が既に設定されています。
このビューには、オンラインブティックでエンドユーザーが実施した操作によって実行されたバックエンドのトランザクションに関わる すべての アプリケーションまたはサービスの すべての ログ行が含まれます。
オンラインブティックのような小さなアプリケーションでも、膨大な量のログが検出され、調査対象となる実際のインシデントに関わる特定のログを見つけ出すのが難しくなる場合があります。
ログに含まれるエラーメッセージだけにフォーカスする必要があります。
sf_service=paymentservice を追加することもできます。今回の場合は不要です。
次に、詳細なログエントリを見ていきましょう。
特定のログ行を見る前に、これまでに何を行ってきたかと、オブザーバビリティの3本柱に基づいて、なぜここに辿り着いたのかを簡単に振り返りましょう。
| Metrics | Traces | Logs |
|---|---|---|
| 問題があるか？ | 問題はどこにあるか？ | 問題は何か？ |
v350.9 と v350.10 の2つのバージョンで構成されており、 v350.10 に対するエラーレートは 100% でした。v350.10 の paymentservice から生成されるエラーがオンラインブティックのチェックアウト処理の応答において、複数回の再試行と長時間の遅延を引き起こしていたことを確認しました。hostname: "paymentservice-xxxx" と表示されていることを確認してください）。メッセージを踏まえ、問題を解決するためには開発チームに何を伝える必要がありますか？
開発チームは、有効なAPIトークンを使用してコンテナを再構築およびデプロイするか、 v350.9 にロールバックする必要があります。
Splunk Observability Cloud を使用することで、オンラインブティックでのショッピング中にユーザーエクスペリエンスが悪かった原因を理解することができました。オブザーバビリティの3本柱である メトリクス、トレース、ログ に基づいて、RUM、APM、およびログを利用することで、サービス全体で何が起こっており、その後、その根底にある原因を見つけることができました。
また、Splunkが提供する、アプリケーションの振る舞いのパターンを検出する Tag Spotlight によるインテリジェントなタグ付けと分析の機能や、問題のコンテキストを維持しながら異なるコンポーネント間を素早く移動する Related Contents によりスタック全体を相関させる機能についても、その使い方を理解したはずです。
ワークショップの次のパートでは、問題の特定から緩和、予防、およびプロセスの改善に進んでいきます。
次に、カスタムダッシュボードでログチャートを作成します。
Log Observer である固定のビューを持っておくと、ダッシュボードの中でそのビューを活用し、将来的に問題の検出と解決にかかる時間を削減することができるでしょう。ワークショップの一環として、これらのチャートを使用するカスタムダッシュボードの例を作成します。
まず、Log Timeline チャートの作成を見てみましょう。Log Timeline チャートは、時間の経過とともにログメッセージを表示するために使用されます。これはログメッセージの頻度を確認し、パターンを識別するのに適した表現方法です。また、環境全体でのログメッセージの出力傾向を確認するのにも適しています。これらのチャートはカスタムダッシュボードに保存できます。
まず、表示するログの列を必要なものに絞り込みます。
_raw のチェックを外し、k8s.pod_name, message, version のフィールドが選択されていることを確認します。
trace_id を削除し、 sf_service=paymentservice および sf_environment=[WORKSHOPNAME] フィールドを追加します。
Log Timeline を入力します。<受講者のイニシャル> - Service Health Dashboard と入力し、 Save をクリックします。
次に、Log View チャートを作成します。
次に、ログに関するチャートタイプである Log View チャートタイプを見ていきます。このチャートを使用すると、事前に定義しておいたフィルタに基づいてログメッセージを表示できます。
前の Log Timeline チャートと同様に、Log View のチャートを Customer Health Service Dashboard に追加します。
severity=error、sf_service=paymentservice および sf_environment=[WORKSHOPNAME] でフィルタリングしているはずです。
次のセッションでは、Splunk Synthetics を見て、Web ベースのアプリケーションのテストを自動化する方法を見ていきます。