クロスプロダクト相関で容易にトラブルシューティング

Docs > ログ管理 > ログガイド > クロスプロダクト相関で容易にトラブルシューティング

概要

統合サービスタグ付けは、高度な相関能力を可能にします。調査の出発点が単一のログ、トレース、ビュー、または Synthetic テストという場合もあるでしょう。ログ、トレース、およびビューを他のデータと相関させることで、ビジネスへの影響を推定し、問題の根本原因を迅速に特定するのに役立つコンテキストが提供されます。

このガイドでは、フルスタックデータを相関させる方法を説明します。ユースケースによっては、以下のいくつかのステップは省略することができます。他のステップに依存しているステップは、明示されています。

サーバー側ログとトレースの相関付け
フロントエンドプロダクトの相関付け
- ブラウザログと RUM の相関付け
ユーザーエクスペリエンスとサーバー動作の相関付け
- RUM ビューとトレースの相関付け
- トレースの相関を活用して Synthetic テストをトラブルシューティング

サーバー側ログとトレースの関連付け

アプリケーションでユーザーにエラーまたは高レイテンシーが発生した際、問題のあるリクエストからの特定のログを見ることで問題を的確に把握できます。該当リクエストに関するすべてのログを集めて始めから終わりまでの処理を詳しく確認し、問題をすばやく診断できます。

ログをトレースと相関付けることで、trace_id を使用してエンティティレベルの一貫性を維持しながら積極的なサンプリング戦略も実現できます。

アプリケーションログの相関付けにより、スタック全体の広い範囲を可視化できますが、特定のユースケースではスタックのより深くに相関付ける必要があります。ユースケースに合わせたセットアップを完了するには、以下のリンクをご利用ください。

プロキシログの相関付け
データベースログの相関付け

アプリケーションログの相関付け

理由

アプリケーションログは、ほとんどのコードおよびビジネスロジックの問題に関するコンテキストを提供します。他のサービスの問題（たとえばORM ログデータベースエラーなど）の解決にも役立ちます。

方法

さまざまな OOTB 相関の 1 つを使用します。カスタムトレーサーを使用している場合や、問題がある場合は、相関に関するよくあるご質問をご参照ください。

プロキシログの相関付け

理由

プロキシログは、アプリケーションログより多くのエントリポイントをカバーするため、静的なコンテンツとリダイレクトに関する、より多くの情報を提供します。

方法

アプリケーショントレーサーは、デフォルトでトレーサーを生成します。HTTP リクエストヘッダに x-datadog-trace-id を挿入することでこれを変更することが可能です。

NGINX

NGINX のログとトレースを関連付けるには、トレース ID が含まれるように NGINX の log_format を設定し、ログからその ID を解析するための Datadog パイプラインを設定する必要があります。

完全なエンドツーエンドのセットアップ手順については、NGINX のインスツルメンテーションを参照してください。

データベースログの相関付け

理由

データベースログは、同様のクエリ、変数の匿名化、そして高い使用量のため、コンテキスト化が困難なことが多くあります。

たとえば、プロダクションのクエリ遅延は、多くのリソースを使用して長時間かけて調査しなければ再現することが困難です。以下に、トレースを使用してクエリ遅延の分析を相関付ける方法例をご紹介します。

方法

PostgreSQL

データベースログの強化

PostgreSQL のデフォルトのログについては詳述されていません。強化するには、こちらのインテグレーションガイドに従ってください。

クエリ遅延のベストプラクティスでは、ステートメント遅延の実行プランを自動的にログに記録することも提案されているため、手動で EXPLAIN を実行する必要はありません。EXPLAIN を自動的に実行するには、/etc/postgresql/<VERSION>/main/postgresql.conf を次のように更新します。

session_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '500ms'

500ms 以上のクエリは実行プランを記録します。

注: auto_explain.log_analyze = 'true' にすると、より多くの情報を取得できますが、パフォーマンスに大きな影響が出ます。詳しくは、公式ドキュメントをご参照ください。

trace_id のデータベースログへの挿入

SQL コメントとともに、データベースログのほとんどに trace_id を挿入します。以下は、Flask および SQLAlchemy の例です。

if os.environ.get('DD_LOGS_INJECTION') == 'true':
    from ddtrace import tracer
    from sqlalchemy.engine import Engine
    from sqlalchemy import event

    @event.listens_for(Engine, "before_cursor_execute", retval=True)
    def comment_sql_calls(conn, cursor, statement, parameters, context, executemany):
        trace_ctx = tracer.get_log_correlation_context()
        statement = f"{statement} -- dd.trace_id=<{trace_ctx['trace_id']}>"
        return statement, parameters

注: これは、クエリステートメントを含むログのみを相関付けます。 ERROR: duplicate key value violates unique constraint "<TABLE_KEY>" のようなエラーログは、コンテキスト外にとどまります。ほとんどの場合、エラー情報はアプリケーションログを通じて取得できます。

PostgreSQL パイプラインのクローン作成とカスタマイズ:

新しい grok parser を追加します。

extract_trace %{data}\s+--\s+dd.trace_id=<%{notSpace:dd.trace_id}>\s+%{data}

dd.trace_id 属性でトレース ID リマッパーを追加します。

以下に、遅延しているトレースからのクエリ遅延の実行プランの例を示します。

フロントエンドプロダクトの相関付け

ブラウザログと RUM およびセッションリプレイの相関付け

理由

RUM イベント内のブラウザログから、問題のコンテキストと洞察を得ることができます。以下の例では、ブラウザログは、不正なクエリの根本的な原因が無効なユーザー ID であることを示しています。

ブラウザログを RUM と相関付けると、session_id や view.id などの属性を使用して、エンティティレベルの一貫性を維持しながら積極的なサンプリング戦略も実現できます。

方法

ブラウザログと RUM イベントは自動的に相関付けられます。詳細については、RUM とセッションリプレイの請求を参照してください。RUM ブラウザ SDK とログ SDK の構成を一致させる必要があります。

ユーザーエクスペリエンスとサーバー動作の相関付け

従来のバックエンドとフロントエンドのモニタリングはサイロ化されており、スタック全体のトラブルシューティングには別々のワークフローが必要になる場合があります。しかし Datadog のフルスタック相関なら、ブラウザの問題であれ、データベースのダウンタイムであれ、根本原因を特定し、ユーザーへの影響を見積もることができます。

このセクションでは、以下の相関を有効にする方法を説明します。