ウェブサービスの最も遅いエンドポイントで最も遅いトレースをデバッグする

所要時間 3 分

Datadog APM を使用すると、エンドポイントのパフォーマンスを調査して遅いリクエストを特定し、レイテンシー問題の根本原因を調査できます。上記の例では、E コマースチェックポイントのエンドポイントについて、1 日のうちで最も遅いトレースと、CPU 使用率が高いためにそのトレースが遅くなっている様子を示しています。

  1. サービスカタログを開きます

    このページには、Datadog にデータを送信しているすべてのサービスのリストが含まれています。なお、キーワード検索、env-tag によるフィルタリング、時間枠の設定が可能です。

  2. 関連性があるアクティブなウェブサービスを検索し、そのサービス詳細画面を開きます

    この例では、テクノロジースタックの主要サーバーであり、ほとんどのサードパーティサービスへのコールを制御している web-store サービスを使用しています。

    最も遅いトレースを特定し、その原因となっているボトルネックを解明する

    スループット、レイテンシー、エラー率の情報に加えて、サービス詳細ページには、そのサービスで特定されたリソース (API エンドポイント、SQL クエリ、Web リクエストなどの主要な操作) の一覧も含まれています。

  3. リソース表を p99 レイテンシーで並べ替え、最も遅いリソースをクリックして開きます。 : p99 レイテンシーの列が表示されていない場合は、歯車アイコン Change Columns をクリックして p99 に切り替えます。

    Resource ページには、スループット、レイテンシー、エラー率、リソースからの各ダウンストリームサービスにかかった時間の内訳など、このリソースに関する上位のメトリクスが表示されます。また、リソースをパススルーする特定のトレースや、このトレースを構成するスパンの集計ビューも確認できます。

    最も遅いトレースを特定し、その原因となっているボトルネックを解明する
  4. 時間フィルターを 1d One Day に設定します。トレース表までスクロールダウンし、期間で並べ替え、表の一番上のトレースにマウスを合わせ View Trace をクリックします

    これはフレームグラフとその関連情報です。ここでは、トレース内の各ステップの時間とエラーの有無を確認でき、遅いコンポーネントやエラーを起こしやすいコンポーネントを特定するのに役立ちます。フレームグラフは、拡大、スクロール、探索が自然に行えます。フレームグラフの下には、関連するメタデータ、ログ、およびホスト情報が表示されます。

    フレームグラフは、エラーが発生しているスタックや、遅いスタックを正確に特定するのに最適です。エラーは赤くハイライト表示され、時間は横向きスパンで表されます。つまり、長いスパンが最も遅いスタックということになります。フレームグラフの活用については、トレースビューガイドを参照してください。

    また、フレームグラフの下には、すべてのタグ (カスタムタグを含む) が表示されます。ここからは、関連するログ (ログをトレースに接続してある場合) や、CPU 使用率やメモリ使用量などのホストレベルの情報も確認できます。

    最も遅いトレースを特定し、その原因となっているボトルネックを解明する
  5. Host タブをクリックして開き、リクエストがヒットしていた間の下層のホストの CPU とメモリのパフォーマンスを調査します。

  6. Open Host Dashboard をクリックして、ホストに関するすべての関連データを表示します。

Datadog APM では、インフラストラクチャーメトリクスやログなど、他の Datadog のメトリクスや情報がシームレスに統合されています。フレームグラフを使用すればこのような情報や、トレースと一緒に送信しているあらゆるカスタムメタデータを利用できます。

その他の参考資料

PREVIEWING: bartol/timeshift-docs