GitHub Repo
Dify Proposes OTLP/HTTP Tracing Integration to Connect Agent Execution Records to Common Observability Pipelines
On November 5, the Dify community proposed an OpenTelemetry tracing provider that lets applications and agents export execution records to compatible collectors. The proposal supports HTTP/protobuf, but has not been merged; full CI and end-to-end validation remain outstanding.

On November 5, 2026, the Dify community submitted PR #45659, proposing a general-purpose OpenTelemetry tracing provider. It would let applications and agents export execution records over OTLP/HTTP without first choosing an integration from a specific observability vendor. As of this check, the proposal remains open for review and should not be treated as a feature available in an official release. Proposal and status
The design focuses on preserving trace structure. According to the author, exported data includes trace and span IDs, parent-child relationships, timestamps, status, structured inputs and outputs, and available model and token attributes. It uses the existing pipeline, without adding a separate export thread or setting process-global OpenTelemetry state. For teams that already have a collector, the potential benefit is connecting agent execution data to their existing observability system, though cross-service trace propagation still needs to be tested. Design details
Protocol and endpoint configuration are key deployment considerations. The OpenTelemetry specification lists HTTP and gRPC as distinct transport options. HTTP traces are typically sent to /v1/traces, and path-composition rules differ depending on whether a generic base endpoint or a trace-specific endpoint is used. Engineers therefore need to verify the receiver’s protocol, encoding, and full path—not just the host and port. OTLP exporter configuration specification
The proposal currently supports HTTP/protobuf, with configuration fields for the endpoint, headers, service name, and resource attributes. The author also designed header credentials to be encrypted and write-only. When changing the export destination, users must re-enter the credentials or explicitly clear them, making destination changes part of credential handling. Configuration and credential design
Next, watch for maintainer review and complete validation. The author reported partial regression test results, but explicitly said that full CI on the target branch is not yet complete. They also did not claim to have passed full-node end-to-end or long-duration load testing. Teams preparing to try the feature should verify trace completeness, receiver compatibility, and delivery behavior on failure before evaluating it for production deployment. Validation limitations