- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
本番環境においてアプリケーションのパフォーマンスに問題がある場合、分散型トレーシングとプロファイリングによるコードスタックトレースのベンチマークを統合することで、パフォーマンスのボトルネックを特定する強力な方法となります。APM 分散型トレーシングと Continuous Profiler の両方が有効になっているアプリケーションプロセスは、自動的にリンクされます。
Code Hotspots タブでスパン情報からプロファイリングデータに直接移動し、パフォーマンス問題に関連する特定のコード行を見つけることができます。同様に、低速でリソースを消費するエンドポイントも、プロファイリング UI で直接デバッグできます。
Java サービスのプロファイリングを有効にすると、Code Hotspots の識別がデフォルトで有効化されます。手動でインスツルメントされたコードの場合、Continuous Profiler はスパンのスコープをアクティブにする必要があります。
final Span span = tracer.buildSpan("ServicehandlerSpan").start();
try (final Scope scope = tracer.activateSpan(span)) { // mandatory for Datadog continuous profiler to link with span
// worker thread impl
} finally {
// Step 3: Finish Span when work is complete
span.finish();
}
Python サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
dd-trace-py
バージョン 0.44.0+ が必要です。
Ruby サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
新しいタイムライン機能 (ベータ版) を有効にするには
dd-trace-rb
1.15 以上にアップグレードするDD_PROFILING_EXPERIMENTAL_TIMELINE_ENABLED=true
に設定するCode Hotspots (ベータ版) の識別は、Node.js サービスのプロファイリングを有効にする と、デフォルトでは有効になりません。この追加の環境変数を設定することで有効になります。
export DD_PROFILING_CODEHOTSPOTS_ENABLED=true
dd-trace-js
のバージョン 4.17.0 以降または 3.38.0 以降が必要です。
Go サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
新しいタイムライン機能 (ベータ版) を有効にするには、以下の環境変数を設定してください。
os.Setenv("DD_PROFILING_EXECUTION_TRACE_ENABLED", "true")
os.Setenv("DD_PROFILING_EXECUTION_TRACE_PERIOD", "15m")
これらの変数を設定すると、実行トレースデータが 15 分ごとに最大 1 分間 (または 5 MiB) 記録されます。
このデータは、
go_execution_traced:yes
を追加して Profile List で表示できます。プロファイルをクリックすると Profile Timeline が表示されます。さらに深く見るには、プロファイルをダウンロードし、go tool trace
または gotraceui を使用して、含まれている go.trace
ファイルを表示します。@go_execution_traced:yes
(@
に注意) を追加してトレースエクスプローラーで表示できます。スパンをクリックし、Code Hotspots
タブを選択してスパンタイムラインを表示します。実行トレースを記録している間、アプリケーションがガベージコレクションのように CPU 使用率の増加を観測する可能性があります。ほとんどのアプリケーションでは大きな影響はないはずですが、Go 1.21 にはこのオーバーヘッドをなくすためのパッチが含まれています。
この機能を利用するには、dd-trace-go
のバージョン 1.37.0 以上 (タイムラインベータの場合は 1.52.0 以上) が必要で、Go のバージョン 1.18 以上 (タイムラインベータの場合は 1.21 以上) で最適に動作します。
.NET サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
この機能を使用するには dd-trace-dotnet
のバージョン 2.30.0 以上が必要です。
PHP サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
dd-trace-php
のバージョン 0.71 以上が必要です。
各トレースのビューから、選択したスパンの範囲内のプロファイリングデータが Code Hotspots タブに表示されます。
左側の値は、選択されたスパンの間にそのメソッド呼び出しに費やされた時間を表します。ランタイムと言語によって、カテゴリーは異なります。
プラスアイコン +
をクリックすると、そのメソッドのスタックトレースが逆順に展開されます。値の上にカーソルを置くと、カテゴリー別に説明される時間の割合が表示されます。
Timeline ビューは、スパンの期間における時間ベースのパターンと作業分布を表示します。
スパンの Timeline ビューでは、次のことが可能です。
ランタイムや言語によって、レーンは異なります。
各レーンはスレッドを表します。共通のプールからのスレッドは一緒にグループ化されます。プールを展開すると、各スレッドの詳細を表示できます。
上のレーンは、余分なレイテンシーを追加するかもしれないランタイムアクティビティです。これらはリクエスト自体に関係ないこともあります。
タイムラインを使って p95 リクエストの遅延やタイムアウトをデバッグする方法については、ブログ記事 プロファイリングでリクエストの遅延を理解するを参照してください。
各レーンは goroutine を表します。これには、選択されたスパンを開始した goroutine と、その goroutine が作成した goroutine とその子孫が含まれます。同じ go
ステートメントで作成された goroutine はグループ化されます。グループを展開して各 goroutine の詳細を見ることができます。
上のレーンは、余分なレイテンシーを追加するかもしれないランタイムアクティビティです。これらはリクエスト自体に関係ないこともあります。
タイムラインを使って p95 リクエストの遅延やタイムアウトをデバッグする方法については、ブログ記事 Datadog のプロファイリングタイムラインによる Go リクエストレイテンシーのデバッグを参照してください。
Ruby でこの機能を有効にする方法については、前提条件を参照してください。
各レーンはスレッドを表します。共通のプールからのスレッドは一緒にグループ化されます。プールを展開すると、各スレッドの詳細を表示できます。
各レーンはスレッドを表します。共通のプールからのスレッドは一緒にグループ化されます。プールを展開すると、各スレッドの詳細を表示できます。
上のレーンは、余分なレイテンシーを追加するかもしれないランタイムアクティビティです。これらはリクエスト自体に関係ないこともあります。
内訳のデータタイプごとに、View In Full Page をクリックすると、同じデータが新しいページで表示されます。そこから、フレームグラフに視覚化を変更することができます。 Focus On セレクタをクリックすると、データの範囲を定義することができます。
Java サービスのプロファイリングを起動すると、エンドポイントプロファイリングがデフォルトで有効化されます。
Datadog プロファイラーの使用が必要です。JFR はサポートされていません。
Python サービスのプロファイリングを起動すると、エンドポイントプロファイリングがデフォルトで有効化されます。
dd-trace-py
のバージョン 0.54.0 以上が必要です。
Go サービスのプロファイリングを起動すると、エンドポイントプロファイリングがデフォルトで有効化されます。
dd-trace-go
バージョン 1.37.0 以上が必要で、Go バージョン 1.18 以降で最適に動作します。
Ruby サービスのプロファイリングを起動すると、エンドポイントプロファイリングがデフォルトで有効化されます。
dd-trace-rb
のバージョン 0.54.0 以上が必要です。
エンドポイントのプロファイリング (ベータ版) は、Node.js サービスのプロファイリングを有効にする と、デフォルトでは有効になりません。この追加の環境変数を設定することで有効になります。
export DD_PROFILING_ENDPOINT_COLLECTION_ENABLED=true
この環境変数を設定すると、エンドポイントのプロファイリングに必要な Code Hotspots (ベータ版) も有効になります。
dd-trace-js
のバージョン 4.17.0 以降または 3.38.0 以降が必要です。
.NET サービスのプロファイリングを起動すると、エンドポイントプロファイリングがデフォルトで有効化されます。
dd-trace-dotnet
のバージョン 2.15.0 以上が必要です。
PHP サービスのプロファイリングを起動すると、エンドポイントプロファイリングがデフォルトで有効化されます。
dd-trace-php
のバージョン 0.79.0 以上が必要です。
エンドポイントプロファイリングは、Web サービスの任意のエンドポイントでフレームグラフをスコープし、遅いエンドポイント、レイテンシーが多いエンドポイント、エンドユーザーエクスペリエンスが悪い原因となっているエンドポイントを見つけることができます。これらのエンドポイントは、デバッグが難しく、なぜ遅いのかを理解するのが困難な場合があります。遅い原因は、エンドポイントが多くの CPU サイクルを消費するなど、意図しない大量のリソースを消費している可能性があります。
エンドポイントプロファイリングを利用すると、以下のことが可能になります。
CPU やウォールタイムなどの貴重なリソースを消費している上位のエンドポイントを追跡することは価値があります。このリストは、エンドポイントが回帰していないか、あるいは新たに導入したエンドポイントが大幅にリソースを消費してサービス全体の速度を低下させていないかどうかを確認するのに役立ちます。
次のイメージは、GET /store_history
がこのサービスの CPU の 20% を消費して定期的に影響を与えていることを示しています。
Per endpoint call
を選択すると、トラフィックが時間の経過とともに変化しても、動作の変化を確認できます。これは、プログレッシブロールアウトのサニティチェックや日々のトラフィックパターンの分析に役立ちます。
次のビデオは、/GET train
のリクエストあたりの CPU が 2 倍になったことを示しています。
お役に立つドキュメント、リンクや記事: