Skip to main content
Dify Enterprise がデータプッシュを通じて発出するすべてのテレメトリシグナルのフィールドレベルリファレンスです。プッシュサービスの設定と運用は データプッシュ を参照してください。

クイック検索とトラブルシューティングガイド

すべてのテーブルを読む必要はありません。可観測性の目標に合ったシグナル層に直接ジャンプしてください。

シナリオとシグナルのマッピング表

テレメトリデータフローとルーティング

Dify がエクスポートするすべてのテレメトリシグナルは OpenTelemetry 仕様に完全に準拠しています。標準の OTel Collector で分割・ルーティングできます:

転送ルールとリソース属性

リソース属性

すべてのエクスポートされた OTel シグナルに付加されるグローバル環境メタデータ:

共通の追跡・エンティティ識別属性

Span では dify. プレフィックス付きの形式を使用します。指標ラベルとログの相関キー(trace_id、span_id、tenant_id、user_id)はプレフィックスなしの形式です。2 つの名称を併記した行は両形式が存在するフィールドです。 3 つの apprunner.* 属性は、デプロイ環境のワークフロー Span(dify.workflow.run)とノード Span(dify.node.execution)、およびそれらの付随ログに含まれます。指標のラベルには使用されません。

OTel と Prometheus の命名規則

OTel シグナル名は、Prometheus に取り込まれるとアンダースコア形式に自動変換されます。Counter には _total サフィックスが追加され、Histogram は _bucket、_sum、_count のシリーズを生成します。Histogram には単位サフィックスも付きます(単位が s の指標は _seconds)。 以下の表は一般的な例を示しています。その他の指標も同じ規則に従います。

Null 値とコンテンツ制御対象フィールド

  • Null 値の動作:値のない属性は Trace Span から省略されます。構造化ログの JSON 出力では明示的に null として表示されます。
  • コンテンツゲーティング:機密テキストを含み得る属性(Input/Output/Query/Prompt など)は、デプロイ側の ENTERPRISE_INCLUDE_CONTENT 設定でゲートされます。コンテンツプッシュが無効(デフォルト)の場合、元の値は null ではなく参照文字列(例:ref:{id_type}={uuid})に置き換えられます。
  • 高カーディナリティの警告:tenant_id、app_id、trace_id は高カーディナリティのディメンションです。無制限のテキストフィールドを Prometheus ラベルとして保存しないでください。

トレースとスパン

トレースは、単一の呼び出しの完全な時系列とネスト構造を示します。OTel trace_id はビジネス実行 ID から決定的に導出され、同一実行のすべてのシグナルで共有されます。Jaeger または Tempo ではこの trace_id で検索します。 dify.trace_id 属性は元のビジネス UUID(ワークフロー実行 ID など)を保持し、ビジネスデータとの結合に使用します。

dify.workflow.run

dify.node.execution

dify.node.execution.draft

dify.node.execution と同じ属性を持ちますが、Studio キャンバスでの単一ノードテストまたはドラフトプレビューの実行時にのみ生成されます。本番テレメトリとテスト実行の分離に使用します。

指標(Metrics)

カウンター(Counter)

すべてのカウンターは累積的で、サンプリングの対象外です。トレースのサンプリングレート(ENTERPRISE_OTEL_SAMPLING_RATE、環境変数リファレンス を参照)はカウンターに影響しません。

トークンカウンター

ラベル:tenant_id、app_id、operation_type、model_provider、model_name、node_type(node_execution の場合のみ)
ワークフローレベルの dify.tokens.total にはすべての node_execution のトークンが含まれています。二重カウントを避けるために operation_type でフィルタリングしてください。
トークン階層とクエリパターン トークン指標は複数のレベルで発出されます。階層構造を理解することで二重カウントを防ぎます:
重要なルール:workflow トークンにはすでにすべての node_execution トークンが含まれています。両方を加算しないでください。
  • トークン指標で使用可能なラベル: tenant_id、app_id、operation_type、model_provider、model_name、node_type。
  • アプリケーション名 はトレース側のみです。「Span 付随ログ」の dify.app.name として提供され、指標ラベルには含まれません。指標クエリには app_id を使用してください。
  • コスト:ノード付随ログの dify.node.total_price フィールドのみで提供されます(「Span 付随ログ」を参照)。コストの指標はありません。

リクエストカウンター

type ラベルが操作の種類を示します(例:dify_requests_total{type="workflow"})。その他のラベルは type によって異なります:

エラーカウンター

エラーカウンターも同じ type ラベルを使用します。その他のラベルは type によって異なります:

その他のカウンター

ヒストグラム(Histogram)

Counter は平均値しか計算できませんが、極端な値によって平均値は歪められます。Histogram は P50 / P95 / P99 パーセンタイル の計算をサポートし、実際の分布をより正確に表現します。Prometheus では各 Histogram は _bucket、_sum、_count の 3 つのシリーズに展開されます。低トラフィックの時間ウィンドウでは P95/P99 が NaN を返す場合があります。その場合はクエリウィンドウを広げてください。TTFT やツール呼び出しなど、レイテンシが 5 秒以内に集中する場合は、パーセンタイルの精度に限界があります。より高い精度で評価するには、クエリウィンドウを延長するか、bucket の設定について Dify チームにお問い合わせください。

構造化ログ

構造化ログは詳細なビジネスデータを提供します。ログは 2 種類に分類されます:Span 付随ログと独立ビジネスログ。
ENTERPRISE_OTEL_SAMPLING_RATE は、Jaeger や Tempo などの Trace バックエンドに送信される Span の数だけに影響します。構造化ログ(span_detail、metric_only)は常に 100% の頻度で Pod の標準出力に書き込まれ、サンプリングレートの影響を受けません。

Span 付随ログ

シグナルタイプ:span_detail。これらのログは Trace Span に密接に結合されており(trace_id と span_id を共有)、コンテンツ制御対象の詳細なコンテキストを含みます。

dify.workflow.run 付随ログ

共通属性: すべての Span 属性(トレースセクション参照)に加えて: イベント属性:
  • dify.event.name:dify.workflow.run
  • dify.event.signal:span_detail
  • trace_id、span_id、tenant_id、user_id

dify.node.execution および dify.node.execution.draft 付随ログ

共通属性: すべての Span 属性(トレースセクション参照)に加えて: イベント属性:
  • dify.event.name:dify.node.execution または dify.node.execution.draft
  • dify.event.signal:span_detail
  • trace_id、span_id、tenant_id、user_id

独立ログ

Trace Span を持たないログです。シグナルタイプは metric_only で、イベントは指標とこのログのみを生成し、付随する Span はありません。

dify.message.run

dify.tool.execution

dify.moderation.check

dify.suggested_question.generation

dify.dataset.retrieval

dify.generate_name.execution

dify.prompt_generation.execution

dify.app.created

dify.app.updated

dify.app.deleted

dify.feedback.created

dify.telemetry.rehydration_failed

テレメトリパイプラインの健全性を示す診断イベントです。バッファされたペイロードを再構築(rehydrate)できない場合に発出されます。継続的な発生はテレメトリデータの損失を示します。

コンテンツゲート属性

以下のフィールドには、ユーザー入力、モデル出力、ドキュメントコンテンツ、ツールパラメータ、フィードバックテキストが含まれる場合があります。 生の値が送信されるのは、デプロイ側でコンテンツプッシュ(ENTERPRISE_INCLUDE_CONTENT、デフォルト false。環境変数リファレンス を参照)が有効な場合のみです。無効の場合、これらの属性は ref:{id_type}={uuid} に置き換えられます。 id_type は関連エンティティ名です(例:workflow_run_id、node_execution_id、message_id)。その ID で Dify データベースの該当レコードを照会すると、元のコンテンツを取得できます。 dify.node.execution.draft のゲート対象フィールドは dify.node.execution と同じです。
本番環境では、デフォルトでコンテンツプッシュを無効にすることを推奨します。データ分類、アクセス制御、難読化要件、保持期間、監査義務を確認した上で、管理された環境で必要に応じて有効にしてください。

付録

操作タイプ

workflow、node_execution、message、rule_generate、code_generate、structured_output、instruction_modify これらの値は、トークン指標の operation_type ラベルと dify.prompt_generation.operation_type に属します。リクエストとエラーのカウンターは別の type ラベルを使用します(値は「カウンター」を参照)。

ノードタイプ

start、end、answer、llm、knowledge-retrieval、knowledge-index、if-else、code、template-transform、question-classifier、http-request、tool、datasource、variable-aggregator、loop、iteration、parameter-extractor、assigner、document-extractor、list-operator、agent、trigger-webhook、trigger-schedule、trigger-plugin、human-input

ワークフローステータス

running、succeeded、failed、stopped、partial-succeeded、paused

ペイロードタイプ

workflow、node、message、tool、moderation、suggested_question、dataset_retrieval、generate_name、prompt_generation、app、feedback

Invoke From の値

  • ワークフロー Span(dify.workflow.run の dify.invoke_from):api、webapp、debug
  • メッセージログ(dify.message.run の dify.invoke_from):service-api、web-app、debugger、explore

Null 値の動作

  • Spans:Null 値を持つ属性は省略されます。
  • Logs:Null 値を持つ属性は JSON 出力で null として表示されます。
  • コンテンツゲートフィールド:null に設定されるのではなく、参照文字列に置き換えられます。