Linux と macOS 上で Java サービスのプロファイリングを有効化 すると、Trace to Profiling の統合はデフォルトで有効になります。Windows では利用できません。

手動インスツルメントしたコードでは、Continuous Profiler がスパンと関連付けるために Scope のアクティベーションが必要です:

final Span span = tracer.buildSpan("ServicehandlerSpan").start();
try (final Scope scope = tracer.activateSpan(span)) { // Datadog Continuous Profiler がスパンに関連付けるために必須
    // ワーカー スレッドの実装
  } finally {
    // ステップ 3: 作業が完了したら Span を終了する
    span.finish();
  }

次の場合に Trace to Profiling の統合が有効になります:

• dd-trace-py を 2.12.0+、2.11.4+、または 2.10.7+ にアップグレードする。
• 環境変数 DD_PROFILING_TIMELINE_ENABLED を true に設定する。

Linux と macOS 上で Node.js サービスのプロファイリングを有効化 すると、Trace to Profiling の統合はデフォルトで有効になります。機能は Windows では利用できません。

dd-trace-js 5.11.0+、4.35.0+、および 3.56.0+ が必要です。

Go サービスのプロファイリングを有効化 し、以下の環境変数を設定すると、Trace to Profiling の統合が有効になります:

os.Setenv("DD_PROFILING_EXECUTION_TRACE_ENABLED", "true")
os.Setenv("DD_PROFILING_EXECUTION_TRACE_PERIOD", "15m")

これらの変数を設定すると、実行トレース データを最大 1 分 (または 5 MiB) まで、15 分ごと に記録します。

このデータは次の場所で確認できます:

• Profile List で、検索クエリに go_execution_traced:yes を追加します。プロファイルをクリックして Profile Timeline を表示します。さらに深く調査するには、プロファイルをダウンロードして go tool trace または gotraceui を使い、含まれている go.trace ファイルを表示します。
• Trace Explorer で、検索クエリに @go_execution_traced:yes を追加します ( @ に注意)。スパンをクリックし、Profiles タブを選択して Span Timeline を表示します。

実行トレースを記録している間、アプリケーションでガーベジ コレクションに似た CPU 使用率の増加が観測される場合があります。ほとんどのアプリケーションにとって重大な影響はないはずですが、Go 1.21 にはこのオーバーヘッドを解消するための パッチ が含まれています。

この機能には dd-trace-go バージョン 1.37.0+ (タイムライン ビューでは 1.52.0+) が必要で、Go バージョン 1.18 以降で最適に動作します (タイムライン ビューは 1.21 以降)。

.NET サービスのプロファイリングを有効化 すると、Trace to Profiling の統合はデフォルトで有効になります。

この機能には dd-trace-dotnet バージョン 2.30.0+ が必要です。

PHP サービスのプロファイリングを有効化 し、次の条件を満たすと、Trace to Profiling の統合が有効になります:

• dd-trace-php バージョン 0.98+ を使用している。
• 環境変数 DD_PROFILING_TIMELINE_ENABLED=1 または INI 設定 datadog.profiling.timeline_enabled=1 を設定している。

各レーンは スレッド を表します。共通のプールからのスレッドはグループ化されます。プールを展開して各スレッドの詳細を表示できます。

上部のレーンは、追加のレイテンシーを引き起こす可能性のあるランタイム アクティビティです。

リクエスト自体とは無関係の場合があります。タイムラインを使って遅い p95 リクエストやタイムアウトをデバッグする方法の詳細は、ブログ記事 プロファイリングでリクエスト レイテンシを理解する を参照してください。

Python でこの機能を有効化する方法は、前提条件 を参照してください。

各レーンは スレッド を表します。共通のプールからのスレッドはグループ化されます。プールを展開して各スレッドの詳細を表示できます。

各レーンは ゴルーチン を表します。選択したスパンを開始したゴルーチン、およびそれが生成したものとその子孫が含まれます。同じ go 文で作成されたゴルーチンはまとめてグループ化されます。グループを展開して、各ゴルーチンの詳細を表示できます。

上部のレーンは、追加のレイテンシーを引き起こす可能性のあるランタイム アクティビティです。リクエスト自体とは無関係の場合があります。

タイムラインを使って遅い p95 リクエストやタイムアウトをデバッグする方法の詳細は、ブログ記事 Datadog の Profiling Timeline で Go リクエスト レイテンシをデバッグする を参照してください。

この機能を Ruby で有効化する方法は、前提条件 を参照してください。

各レーンは スレッド を表します。共通のプールからのスレッドはグループ化されます。プールを展開して各スレッドの詳細を表示できます。

各レーンは スレッド を表します。同じ名前のスレッドはグループ化されます。グループを展開して各スレッドの詳細を表示できます。コードで明示的に作成されたスレッドは Managed Threads の下にグループ化されます。

上部のレーンは、追加のレイテンシーを引き起こす可能性のあるランタイム アクティビティです。リクエスト自体とは無関係の場合があります。

この機能を Node.js で有効化する方法は、前提条件 を参照してください。

JavaScript スレッド は 1 つのレーンです。

上部のレーンは、リクエストに追加のレイテンシーをもたらす可能性のあるガーベジ コレクタの ランタイム アクティビティ です。

この機能を PHP で有効化する方法は、前提条件 を参照してください。

各 PHP スレッド に対して 1 つのレーンがあります (PHP NTS では 1 つのみ)。この スレッド 内で実行される Fiber は同じレーンに表示されます。

上部のレーンは、ファイル コンパイルやガーベジ コレクションに起因して、リクエストに追加のレイテンシーをもたらす可能性のあるランタイム アクティビティです。

Java サービスのプロファイリングを有効化 すると、エンドポイント プロファイリングはデフォルトで有効になります。

Datadog プロファイラの使用 が必要です。JFR はサポートされません。

Python サービスのプロファイリングを有効化 すると、エンドポイント プロファイリングはデフォルトで有効になります。

dd-trace-py バージョン 0.54.0+ が必要です。

Go サービスのプロファイリングを有効化 すると、エンドポイント プロファイリングはデフォルトで有効になります。

dd-trace-go バージョン 1.37.0+ が必要で、Go バージョン 1.18 以上で最適に動作します。

Linux と macOS 上で Node.js サービスのプロファイリングを有効化 すると、エンドポイント プロファイリングはデフォルトで有効になります。この機能は Windows では利用できません。

dd-trace-js バージョン 5.0.0+、4.24.0+、または 3.45.0+ が必要です。

.NET サービスのプロファイリングを有効化 すると、エンドポイント プロファイリングはデフォルトで有効になります。

dd-trace-dotnet バージョン 2.15.0+ が必要です。

PHP サービスのプロファイリングを有効化 すると、エンドポイント プロファイリングはデフォルトで有効になります。

dd-trace-php バージョン 0.79.0+ が必要です。