Dify、OTLP/HTTP トレース統合を提案　エージェント実行記録を共通の可観測性パイプラインへ

Difyコミュニティは2026年11月5日、汎用のOpenTelemetryトレースプロバイダーを追加するPR #45659を提出した。この提案により、アプリケーションやエージェントは特定の可観測性ベンダー向け統合を選ばずに、OTLP/HTTP経由で実行記録をエクスポートできる。確認時点では、提案はオープンレビュー中であり、正式リリース済みの機能とは見なせない。提案とステータス

設計の要点は、トレース構造を保つことだ。作者の説明によると、エクスポート内容にはトレースとスパンの識別子、親子関係、時刻、ステータス、構造化された入出力、取得可能なモデルおよびトークン属性が含まれる。送信には既存のパイプラインを使い、専用のエクスポートスレッドを新設せず、プロセス全体に適用されるOpenTelemetryの状態も設定しない。すでにコレクターを運用しているチームにとっては、エージェントの実行データを既存の可観測性システムに接続できる可能性がある。ただし、サービス間の連携効果は実地検証が必要だ。設計の説明

プロトコルとエンドポイントの設定は、デプロイ時の重要な確認事項となる。OpenTelemetry仕様では、HTTPとgRPCは別々の転送方式として定義されている。HTTPによるトレースは通常 /v1/traces に送信され、共通のベースエンドポイントを使う場合とトレース専用エンドポイントを使う場合とでは、パスの結合規則も異なる。そのため、エンジニアはホストとポートだけでなく、受信側のプロトコル、エンコーディング、完全なパスも確認する必要がある。OTLPエクスポーター設定仕様

提案は現在、HTTP/protobufに対応し、エンドポイント、ヘッダー、サービス名、リソース属性を設定できる。作者はヘッダーの認証情報を暗号化し、書き込み専用として設計した。エクスポート先を変更する際は、認証情報を再入力するか、明示的に消去する必要がある。このため、送信先の変更には認証情報の取り扱いも伴う。設定と認証情報の設計

今後は、メンテナーによるレビューと完全な検証の進展に注目したい。作者は一部の回帰テスト結果を公開しているが、対象ブランチでの完全なCIは未完了であり、エンドツーエンドのノード全体テストや長時間負荷テストに合格したとも述べていない。試験導入を検討するチームは、正式導入を判断する前に、トレースの完全性、受信側との互換性、失敗時の配信動作を確認する必要がある。検証上の制約