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

概要

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

フルスタックの相関

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

  1. サーバー側ログとトレースの相関付け
  2. フロントエンドプロダクトの相関付け
  3. ユーザーエクスペリエンスとサーバー動作の相関付け

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

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

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

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

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

理由

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

方法

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

プロキシログの相関付け

理由

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

方法

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

NGINX

OpenTracing のセットアップ

NGINX トレースインテグレーションを参照。

ログのトレース ID の挿入

トレース ID は、opentracing_context_x_datadog_trace_id 変数として保存されます。NGINX 構成ファイル (/etc/nginx/nginx.conf) の HTTP セクションに以下の構成ブロックを追加して、NGINX のログ形式を更新します。

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;
}
パイプラインでトレース ID をパース
  1. NGINX パイプラインのクローンを作成します。

  2. 最初の grok parser をカスタマイズします。

    • Parsing rules で、パースルールを以下と置き換えます。
    access.common %{_client_ip} %{_ident} %{_trace_id} %{_auth} \[%{_date_access}\] "(?>%{_method} |)%{_url}(?> %{_version}|)" %{_status_code} (?>%{_bytes_written}|-)
    
    • Helper RulesAdvanced settings で、行を追加します。
    _trace_id %{notSpace:dd.trace_id:nullIf("-")}
    
  3. dd.trace_id 属性で トレース ID リマッパーを追加します。

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

理由

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

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

方法

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 パイプラインのクローン作成とカスタマイズ:

  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 アクションのブラウザログ

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

方法

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

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

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

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

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

理由

APM と RUM およびセッションリプレイのインテグレーションにより、フロントエンドとバックエンドのデータを 1 つの視点で見ることができるようになります。また、以下のことも可能になります。

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

方法

トレースエクスプローラーで RUM ビューに、RUM エクスプローラーで APM トレースにアクセスできます。詳細については、RUM とトレースの接続を参照してください。

トレース内の RUM 情報

RUM ビューとサーバーログには直接の相関はありません。ログ内の RUM イベントと RUM イベント内のログを表示するには、Traces タブをクリックします。

RUM アクショントレースプレビューのログ

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

理由

APM と Synthetic Monitoring のインテグレーションにより、テストによって生成されたトレースを使用して、失敗したテスト実行から問題の根本原因を導き出すことができます。

Synthetic テストの失敗の根本原因

バックエンド、インフラストラクチャー、トレースからのログ情報、および RUM イベント (ブラウザテストのみ) に加えて、テストからネットワーク関連の詳細情報を得ることで、アプリケーションの動作とユーザー体験に関するさらなる詳細にアクセスすることができます。

方法

アプリケーションのエンドポイントで APM を有効にすると、Synthetic Monitoring & Continuous Testing ページで APM トレースにアクセスできます。

詳しくは Synthetic テストとトレースの接続を参照してください。

その他の参考資料