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

概要

統合サービスタグ付けを使用すると、高レベルの相関機能を利用できます。しかし、調査の開始が単独のログ、トレース、ビューまたは Synthetic テストであることがあります。ログ、トレース、ビューを他のデータと相関付けることで、ビジネスへの影響を予測し問題の根本原因を数クリックで見つけ出すためのコンテキストを確保できます。

このガイドでは、フルスタックデータの相関付けの手順についてご説明します。

1. サーバー側ログとトレースの相関付け
   • アプリケーションログの相関付け
   • プロキシログの相関付け
   • データベースログの相関付け
2. フロントエンドプロダクトの相関付け
   • ブラウザログと RUM の相関付け
3. ユーザーエクスペリエンスとサーバー動作の相関付け
   • RUM ビューとトレースの相関付け
   • トレースの相関を活用して Synthetic テストをトラブルシューティング

注: ユースケースによっては、以下の手順の一部をスキップしてください。他の要因に左右される手順は、明確に言及されています。

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

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

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

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

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

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

理由

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

方法

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

プロキシログの相関付け

理由

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

方法

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

http {
  log_format main '$remote_addr - $opentracing_context_x_datadog_trace_id $http_x_forwarded_user [$time_local] "$request" '
          '$status $body_bytes_sent "$http_referer" '
          '"$http_user_agent" "$http_x_forwarded_for" ';

  access_log /var/log/nginx/access.log;
}

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

理由

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

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

方法

データベースログの強化

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

またクエリの遅延ガイドラインは、クエリの遅延に関する詳細なプランの説明も必要とします。実行プランの結果については、以下を使用して/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 パイプラインのクローン作成とカスタマイズ:

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

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

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

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

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

ブラウザログと RUM の相関付け

理由

RUM 内のブラウザログにより、コンテキストと問題の詳細情報が得られます。下記の例では、ブラウザログは正しくないクエリの根本原因が無効なユーザー ID であることを示しています。

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

方法

RUM 請求に関するよくあるご質問で説明されているとおり、ブラウザログと RUM イベントは自動的に相関付けられます。RUM とログ SDK に一致するコンフィギュレーションが必要です。

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

従来のバックエンドおよびフロントエンドのモニタリングはサイロ化され、スタック全体のトラブルシューティングに別々のワークフローを要求します。Datadog のフルスタック相関なら、根本原因を特定（ブラウザの問題なのかデータベースのダウンタイムに起因するのか）し、ユーザーへの影響を予測できます。

このセクションでは、このようなタイプの相関付けを有効にする手順についてご説明します。

• RUM ビューとトレースの相関付け
• トレースの相関を活用して Synthetic テストをトラブルシューティング

RUM ビューとトレースの相関付け

理由

APM と RUM を共に使用することで、フロントエンドおよびバックエンドの完全データを 1 つのレンズで見ることができます。

RUM 相関で以下を実行:

• フロントエンドを含むスタックのあらゆる場所の問題をすばやく特定
• ユーザーが経験している問題を完璧に把握

方法

RUM とトレースの接続ドキュメントを参照してください。RUM ビューの情報はトレースビュー、トレースの情報はセッションビューでご利用いただけます。

注: RUM ビューとサーバーログに直接相関はありません。トレースのプレビューで、RUM イベントをログから、ログを RUM イベントから確認できます。

トレースの相関を活用して Synthetic テストをトラブルシューティング

理由

Synthetic モニタリングとの APM インテグレーションを使用すると、失敗したテストから生成されたトレースを見ることで、テストランが失敗した問題の根本原因を探ることができます。

ネットワーク関連の仕様（テストから）に加えてバックエンド、インフラストラクチャー、ログの情報（トレースから）、そして RUM イベント（ブラウザテストのみ）を得ることで、ユーザーが目にしたのと同じようにアプリケーションが挙動する詳細な様子を確認することができます。

方法

この機能については、Synthetic 設定で APM インテグレーションを有効にするドキュメントを参照してください。