ログとトレース：シームレスな調査においてコンテキストが全てである理由

午前3時。アラートが鳴り響いています。何かが故障し、レイテンシーが急上昇し、ノイズが多すぎて、迅速に根本原因を特定するプレッシャーにさらされています。問題を解決するためには、システムがどのように相互作用しているかを理解する必要があります。しかし、組織が新しい技術、AIモデル、コンテナベースのマイクロサービスを追加するにつれて、システムはますます複雑化しています。そのため、複雑さが増すにつれて、相互に関連した洞察の必要性も高まっています。可観測性の世界では、ログとトレースはそれぞれ異なる目的を持ちながらも補完し合います。これらを組み合わせて使用することで、システムの健全性、パフォーマンス、動作に関する強力な可視性が得られます。

ログとトレースの知られざる関係

理論上、ログとトレースの相関分析は単純明快であるべきです。しかし実際には、チームはトレースの経路と関連する全てのログを追跡するために、頻繁にコンテキストを切り替える必要に迫られます。その理由を理解するため、ログとトレースの役割と責任について詳しく見ていきましょう。

トレース：全体像を捉える視点

トレースは、分散システム内の様々なサービスを通過するリクエストの経路を追跡します。異なるコンポーネント間の相互作用をエンドツーエンドで可視化するため、レイテンシ、ボトルネック、サービス間の依存関係を理解するのに最適です。分散トレースはイベントを一貫したタイムラインに結び付け、あるサービスのパフォーマンスが他サービスに与える影響をエンジニアが把握する手助けとなります。

トレースは、「このリクエストはどこで遅延したのか？」や「どのサービスが障害を引き起こしたのか？」といった疑問を解明する際に真価を発揮します。

ログ：詳細な調査作業

ログは、アプリケーションやインフラストラクチャによって生成される、詳細なタイムスタンプ付きのイベント記録です。コンテキストが豊富で、エラーメッセージ、デバッグ情報、開発者がコードに記述したカスタム出力などが含まれることがよくあります。トレースが流れを示すのに対し、ログは詳細を示します。ログはトレースとは独立して存在し、問題が発生した際に開発者が最初に確認する場所となることがよくあります。

ログは「ここで具体的に何が起きたのか？」という疑問を解明する際に真価を発揮します。

メトリクスやその他のテレメトリ信号もお忘れなく

ここではログとトレースに焦点を当てていますが、メトリクスやその他のテレメトリデータも可観測性と深いコンテキストを得るために不可欠です。可観測性シグナルの全範囲を統合することが重要な理由については、「可観測性とは何か」および「統合された可観測性：OpenTelemetryシグナルを一元的に保存する意義」をご覧ください。

単一のフルコンテキストプラットフォームからログとトレースを相関させる力

テレメトリ信号が孤立していると、盲点が生じ、原因究明に時間を浪費する恐れがあります。ログとトレースを活用する主な目的としては、トラブルシューティングの簡素化、パフォーマンスの向上、セキュリティ態勢の強化、コンプライアンス基準の達成などが挙げられます。

単一の可観測性データソースからログとトレースを相関させることができれば、調査の速度を低下させる絶え間ないコンテキストの切り替えを排除できます。トレースツールとログビューアを切り替える代わりに、点と点を素早く結びつける統合ビューを取得できます。

単一のプラットフォームからログとトレースを関連付けることで、トラブルシューティングは断片的な調査から合理化された分析へと変化し、情報を探す代わりに問題解決に時間を費やすことができるようになります。Grail®、OneAgent®、Davis® AI などのコアテクノロジーは、柔軟性を実現する OpenTelemetry などのオープンソースフレームワークを採用しながら、スケーラブルな基盤を提供します。

チェックアウトの失敗の事例を解明する：ログとトレースの調査

調査は、必ずしも同じ方法で始まるわけではありません。トレースによって、問題を発見し、さらに深く掘り下げるために必要な概要を把握できる場合もあります。また、ログエントリが、何か異常があることの最初の手がかりとなる場合もあります。次のセクションでは、トレースから始める例とログから始める例の 2 つを取り上げ、必要な答えをどのように得ることができるかをご紹介します。

シナリオ 1：トレースからログへの調査

分散トレーシングアプリで日常的な監視を行っている際、Kubernetesのプロダクションネームスペースで一連のリクエスト失敗を確認しました。そこで、失敗したトランザクションをフィルタリングし、詳細に調査することにしました。

特に目立つリクエストが「/cart/checkout」です。これは重要なトランザクションパスであり、ここで失敗が発生しています。

トレースのウォーターフォールを詳細に確認します。その直下に、各スパンに関連付けられたログが見つかり、より深い洞察を得ることができました。そこで次のメッセージを発見しました：

「エラー：注文の完了に失敗しました」

さらに調査を進めると、別のログから根本原因が明らかになりました。当社のポリシーに沿ってVisaとMastercardのみを受け付けているため、ビジネスに制限が生じている可能性があります。これにより新たな疑問が生じます：この現象はどの程度の頻度で発生しているのでしょうか？

ワンクリックでログアプリに切り替えると、この特定のメッセージを検索し、影響を受けた可能性のある取引数を定量化できます。

このアプローチにより、散在する兆候が一貫したストーリーへと統合され、表面的な症状から迅速かつ正確に実行可能な洞察へと移行することが可能となります。

シナリオ 2: ログからトレースへの調査

一日の始まりがPagerDutyやSlackからの通知であれ、KubernetesやCloudsアプリなどDynatrace内の各種アプリから直接開始であれ、調査の文脈に沿ったログを常に確認できます。

このシナリオでは、別の角度から調査を進めます。まずログアプリで、Kubernetes の prod ネームスペース用に事前フィルタリングされたセグメントから開始します。このビューは、当社が所有するサービスに合わせてカスタマイズされています。素早く確認したところ、不審な点が発見されました。一部のログファイルに多数のエラーが記録されているのです。

さらに深く調査するため、ログアプリ内で「payment」と「error」のコンテンツフィルターを使用すると、以下のメッセージを含む複数のログが見つかりました：

ユーザー ID = xxxxxxxxxxxxx のカード決済に失敗しました

しかし、失敗の原因は何でしょうか？「関連ログを表示」をクリックすると、トレースIDに関連するすべてのログが表示されます。これで、発生した順にログメッセージを連続して確認できます。

周辺のログを調査したところ、ユーザーがVisaやMastercard以外のクレジットカードを使用していることが判明しました。当社ではこれらのカード以外のクレジットカードはサポートしておりません。失敗の原因が理解できたところで、この体験を最適化できるかどうか、さらに調査を進めてみましょう。

影響の全容を把握するため、シームレスにトレースビューへ切り替えます。ここではリクエストの完全なウォーターフォール分析（サービス呼び出し、タイミング、スパンレベルのメタデータ）を確認できます。

特に注目すべき点は、ユーザーが失敗メッセージを受け取るまでに5秒を要したことです。カードがサポートされていないことを知らされるだけで、これほど長く待たせるのは問題です。

この知見をもとに、ユーザーが支払い方法がサポートされていないことを理解するまで長時間待たされることなく、より良いユーザー体験を提供できるよう、的を絞った改善を行うことが可能となります。

これらの事例は、ログとトレース間のシームレスなナビゲーションがトラブルシューティングを加速させることを示していますが、これは一面に過ぎません。Dynatrace GrailとNotebooksを活用すれば、高度なクエリの実行、反復作業の自動化、データ豊富な共同ワークフローの構築により、さらに一歩進んだ取り組みが可能です。これらのツールにより、チームは事後対応型のトラブルシューティングを超え、先を見据えたスケーラブルな可観測性へと移行できます。

ログとトレース間のシームレスなナビゲーションが重要な理由

ログとトレース間のシームレスなナビゲーションは、単なる利便性ではなく、ゲームチェンジャーです。トレースから始める場合でもログから始める場合でも、シグナル間を瞬時に切り替えることができるため、答えを探す時間を削減し、問題解決に集中できます。根本原因の分析を加速し、チームコラボレーションを向上させ、自信を持って行動するために必要な完全なコンテキストを提供します。これは、Dynatraceが断片的なトラブルシューティングから統合されたインテリジェントな可観測性への移行を支援する一例に過ぎません。

調査を開始する準備はできていますか？

Dynatrace Playgroundで事前入力データ付きの分散トレースと ログ管理・分析機能をご体験ください。