OpenTelemetry for LLM apps: instrument once, send traces to both Datadog and self-hosted Langfuse

In December 2025, Datadog announced that its LLM/Agent Observability product natively supports the OpenTelemetry GenAI Semantic Conventions, covering versions 1.37 and later.

It reads like a changelog entry, but it removes a knot that almost every FDE on an enterprise LLM project runs into: the client’s operations team already uses Datadog, while the data team wants to keep traces in a self-hosted Langfuse.

If each backend demands its own SDK, the application code becomes welded to that vendor. A shared standard changes the problem. Langfuse also states that it aims to comply with the same OpenTelemetry GenAI conventions, so a single round of instrumentation can serve both sides.

This is exactly the kind of work FDEs do on client sites: designing a pipeline so that the client’s choice of tools does not force a rewrite of application code.

What does OTel GenAI actually standardise?

OpenTelemetry is an open standard for traces, metrics and logs. The GenAI part adds a consistent set of attribute names for model calls, so that any backend receiving a trace can tell which span is an LLM call and which attribute holds what.

The authoritative source has moved. The GenAI conventions have been split out of the general semantic-conventions repo into a dedicated one, semantic-conventions-genai, which covers spans, metrics and events for GenAI clients. When debating an attribute name with a client, link to the new repo, not the old page.

Datadog describes the approach concisely: instrument the LLM application once with OTel, then export GenAI spans through an existing OTel Collector pipeline. Its documentation also states that OTel traces can be sent directly without the Agent Observability SDK or the Datadog Agent.

When should an FDE use it on a client site?

Picture a banking client. The SRE team wants agent latency right next to its infrastructure dashboards in Datadog. The AI team wants to read every prompt and response in Langfuse running on internal infrastructure. Install two SDKs and every framework change has to be made twice, while the two teams end up looking at two diverging pictures.

The cleaner route: instrument with OTel GenAI, send everything to one OTel Collector, and let the Collector split the same trace into two parallel branches. This fits even better when the client has not yet settled on a vendor, because switching backends later is just an exporter config change.

A minimal Collector configuration

The configuration turns on two details. Datadog routes OTLP spans into Agent Observability via the header dd-otlp-source=llmobs. Langfuse, including self-hosted deployments, receives OTLP traces at the /api/public/otel endpoint. A sketch might look like this, with endpoints and authentication headers filled in from each vendor’s documentation:

receivers:
  otlp:
    protocols:
      http:
      grpc:

exporters:
  otlphttp/datadog:
    endpoint: <DATADOG_OTLP_ENDPOINT>
    headers:
      dd-otlp-source: llmobs
      # add the API key header as described in the Datadog docs
  otlphttp/langfuse:
    endpoint: <LANGFUSE_HOST>/api/public/otel
    headers:
      # add the auth header as described in the Langfuse docs

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/datadog, otlphttp/langfuse]

(The comments in the config say: add the API key header per Datadog’s documentation; add the authentication header per Langfuse’s documentation.)

For Langfuse, otlphttp is mandatory. Langfuse supports OTLP over HTTP, with both HTTP/JSON and HTTP/protobuf, but does not yet support gRPC.

Datadog is different. Using otlphttp for it in this sketch keeps both branches on the same exporter type, which makes the config easier to read and debug; it is not a constraint imposed by Langfuse. If the client’s existing pipeline already sends traces to Datadog with a different exporter and works fine, leave that branch alone and add a separate HTTP exporter just for Langfuse.

Check Datadog’s documentation for the protocols the client’s endpoint accepts before changing anything.

Verify before calling it done

Do not stop at the Collector starting without errors. Send exactly one test LLM call from the application, then open both backends and look for that trace: in Datadog, the LLM/Agent Observability view; in Langfuse, the project’s trace list.

If the trace appears on only one side, the fault is already narrowed down. Missing from Langfuse: recheck the HTTP protocol, the /api/public/otel path and the running version. Missing from Datadog’s LLM view: recheck the dd-otlp-source header and the convention version the framework emits.

Three traps before the demo

The first trap is gRPC, as covered above. The second is versioning: Langfuse advises self-hosters who hit 4xx errors on the OTel endpoint to upgrade to the latest release, and its documentation says local deployments need v3.22.0 or later. Before blaming the Collector config, ask which Langfuse version the client is running.

The third trap is in the framework. Many libraries predate version 1.37 of the conventions. Datadog’s documentation says to set the environment variable OTEL_SEMCONV_STABILITY_OPT_IN so they emit 1.37+ compatible traces. If Datadog receives spans but they do not show up in the LLM view, check this first.

It is also worth knowing that Datadog accepts traces following the OpenInference conventions, not just OTel GenAI. That helps when a client has already instrumented with OpenInference, but do not take it as a guarantee that Langfuse will interpret them identically. The common ground the two definitely share is OTel GenAI.

What to learn first

Start with the OTel Collector, not the dashboards. Understanding receivers, exporters and pipelines is enough to build the configuration above in an afternoon. Then read the spans section of the semantic-conventions-genai repo and compare it with real traces your framework emits.

When reading FDE job descriptions, look for phrases such as “observability”, “OpenTelemetry” and “LLM tracing”. On a CV, a line like “built an LLM tracing pipeline on OTel GenAI, exporting in parallel to Datadog and self-hosted Langfuse” says more than a list of tool names.

If the client is still weighing observability tools, do not wait for them to decide. A standards-compliant OTel pipeline lets you start collecting traces today and leaves that debate to play out in a YAML file.