- はじめに
- エージェント
- インテグレーション
- Watchdog
- イベント
- ダッシュボード
- モバイルアプリケーション
- インフラストラクチャー
- サーバーレス
- メトリクス
- ノートブック
- アラート設定
- APM & Continuous Profiler
- CI Visibility
- RUM & セッションリプレイ
- データベース モニタリング
- ログ管理
- セキュリティプラットフォーム
- Synthetic モニタリング
- ネットワークモニタリング
- 開発者
- API
- アカウントの管理
- データセキュリティ
- ヘルプ
本番環境においてアプリケーションのパフォーマンスに問題がある場合、分散型トレーシングとプロファイリングによるコードスタックトレースのベンチマークを統合することで、パフォーマンスのボトルネックを特定する強力な方法となります。APM 分散型トレーシングと Continuous Profiler の両方が有効になっているアプリケーションプロセスは、自動的にリンクされます。
Code Hotspots タブでスパン情報からプロファイリングデータに直接移動し、パフォーマンス問題に関連する特定のコード行を見つけることができます。同様に、低速でリソースを消費するエンドポイントも、プロファイリング UI で直接デバッグできます。
サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。手動でインスツルメントされたコードの場合、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();
}
以下が必要です:
サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
トレーシングライブラリのバージョン 0.44.0 以降が必要です。
サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
トレーシングライブラリのバージョン 0.49.0 以降が必要です。
Go の Code Hotspots の識別を有効にするには、サービスのプロファイリングを有効化し、以下を確認します。
DD_PROFILING_CODE_HOTSPOTS_COLLECTION_ENABLED=true
が設定されているか、 tracer.WithProfilerCodeHotspots(true)
オプションが tracer.Start()
に渡されていること。このオプションは dd-trace-go バージョン 1.37.0+ でデフォルトで有効になっています。profiler.CPUDuration(60*time.Second)
と profiler.WithPeriod(60*time.Second)
が profiler.Start()
に渡されていること。これらの値は dd-trace-go バージョン 1.37.0+ でデフォルトで設定されています。警告: Go 1.17 以下には、特に CGO を多用する場合に、この機能の精度を低下させる可能性のあるいくつかのバグ (GH-35057、GH-48577、CL-369741、CL-369983 参照) があります。これらは 1.18 リリースで修正される予定です。
サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
トレーシングライブラリのバージョン 2.7.0 以降が必要です。
サービスのプロファイリングを起動すると、コードのホットスポット識別がデフォルトで有効化されます。
トレーシングライブラリのバージョン 0.71 以降が必要です。
各トレースのビューから、選択したスパンの範囲内のプロファイリングデータが Code Hotspots タブに表示されます。
左側の詳細ビューは該当するスパンを実行している時間集計のタイプのリストです。このタイプリストの内容はランタイムと言語に応じて異なります。
これらのタイプのうちひとつをクリックし、時間を要したメソッドに対応するリスト (開始時間順) を確認します。プラス (+
) マークをクリックすると当該メソッドのスタックトレースが逆の順で開きます。
その他の説明のつかない時間の記録が少ない (10% 未満) ことは通常ありません。その他の時間が記録される可能性は次の通りです。
詳細画面の各タイプについて、View profile をクリックするとそのデータをフレームグラフ形式で表示させることができます。Span/Trace/Full profile セレクタをクリックして、データのスコープを定義します。
Python サービスでプロファイリングを有効にすると、エンドポイントプロファイリングがデフォルトで有効になります。この機能を利用するには、 dd-trace-py
バージョン 0.54.0 またはそれ以上が必要です。
Go サービスでプロファイリングを有効にすると、エンドポイントプロファイリングはデフォルトで無効になります。これを有効にするには、以下を確認する必要があります。
DD_PROFILING_ENDPOINT_COLLECTION_ENABLED=true
が設定されているか、 tracer.WithProfilerEndpoints(true)
オプションが tracer.Start()
に渡されていること。このオプションは dd-trace-go バージョン 1.37.0+ でデフォルトで有効になっています。警告: Go 1.17 以下には、特に CGO を多用する場合に、この機能の精度を低下させる可能性のあるいくつかのバグ (GH-35057、GH-48577、CL-369741、CL-369983 参照) があります。これらは 1.18 リリースで修正される予定です。
Ruby サービスでプロファイリングを有効にすると、エンドポイントプロファイリングがデフォルトで有効になります。この機能を利用するには、dd-trace-rb
バージョン 0.54.0 またはそれ以上が必要です。
エンドポイントプロファイリングは、Web サービスの任意のエンドポイントでフレームグラフをスコープし、遅いエンドポイント、レイテンシーが多いエンドポイント、エンドユーザーエクスペリエンスが悪い原因となっているエンドポイントを見つけることができます。これらのエンドポイントは、デバッグが難しく、なぜ遅いのかを理解するのが困難な場合があります。遅い原因は、エンドポイントが多くの CPU サイクルを消費するなど、意図しない大量のリソースを消費している可能性があります。
エンドポイントプロファイリングを利用すると、以下のことが可能になります。
CPU やウォールタイムなどの貴重なリソースを消費している上位のエンドポイントを追跡することは価値があります。このリストは、エンドポイントが回帰していないか、あるいは新たに導入したエンドポイントが大幅にリソースを消費してサービス全体の速度を低下させていないかどうかを確認するのに役立ちます。