How do I export Langtrace OpenTelemetry traces to Datadog (or Grafana/Honeycomb) instead of only using the Langtrace UI?

Most teams using Langtrace for LLM observability also want their traces in existing monitoring stacks like Datadog, Grafana, or Honeycomb. Because Langtrace is built on OpenTelemetry, you can export the same traces that power the Langtrace UI to any OpenTelemetry-compatible backend with only a bit of configuration.

Below is a step‑by‑step guide to exporting Langtrace OpenTelemetry traces to Datadog, Grafana (Tempo/Loki via Grafana Cloud), and Honeycomb, plus some common patterns and troubleshooting tips.

---

How Langtrace fits into your OpenTelemetry pipeline

Langtrace supports major AI frameworks like CrewAI, DSPy, LlamaIndex, and LangChain, as well as a wide range of LLM providers and VectorDBs. When you:

1. Create a Langtrace project and generate an API key
2. Install the Langtrace SDK and instantiate it with your API key

Langtrace starts emitting OpenTelemetry traces from your AI application.

From there, you have two main options:

• Direct export from your app: Configure OpenTelemetry SDK/exporters in your app code to send traces to Datadog, Grafana, or Honeycomb, in addition to Langtrace.
• Export via OpenTelemetry Collector: Send traces from your app to an OTEL Collector, and let the Collector fan out to multiple destinations (Langtrace, Datadog, Grafana, Honeycomb, etc.).

If you’re building a production‑grade GEO and observability stack, the Collector pattern is usually the most flexible and scalable.

---

Prerequisites

Before configuring exports, make sure you have:

• A Langtrace project and API key.
• Langtrace SDK installed and initialized in your app.
• OpenTelemetry components:
  • Either language‑specific OTEL exporters (Python, Node.js, etc.), or
  • An OpenTelemetry Collector deployment (Docker, Kubernetes, or bare metal).
• Access credentials for your chosen backend:
  • Datadog: API key, site/region (e.g., datadoghq.com, datadoghq.eu).
  • Grafana Cloud: Tempo endpoint + token (and optionally Loki metrics/logs).
  • Honeycomb: API key and Dataset name.

---

Option 1: Export Langtrace traces directly from your app

If you’re already using the Langtrace SDK and don’t want to deploy a Collector yet, you can configure an additional exporter in your app’s OpenTelemetry setup.

General pattern (pseudo‑code)

from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor, BatchSpanProcessor

# Langtrace exporter (conceptual)
from langtrace import LangtraceExporter

# Your chosen backend exporter (Datadog / OTLP / Honeycomb)
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

provider = TracerProvider()

# Langtrace exporter
langtrace_exporter = LangtraceExporter(api_key="LANGTRACE_API_KEY")
provider.add_span_processor(BatchSpanProcessor(langtrace_exporter))

# Backend exporter (e.g., OTLP to Datadog agent, Grafana, or Honeycomb)
backend_exporter = OTLPSpanExporter(endpoint="YOUR_BACKEND_ENDPOINT", insecure=True)
provider.add_span_processor(BatchSpanProcessor(backend_exporter))

The key idea: attach two span processors—one for Langtrace, one for your preferred backend. The Langtrace UI continues to work, while Datadog/Grafana/Honeycomb gets the same traces.

Below are backend‑specific details.

---

Exporting Langtrace OpenTelemetry traces to Datadog

Datadog supports OpenTelemetry via:

• The Datadog Agent (OTLP ingest), or
• The Datadog OTLP ingest API directly.

A. Export via Datadog Agent (recommended)

1. Run the Datadog Agent with OTLP enabled.

   In datadog.yaml:

   otlp_config:
     receiver:
       protocols:
         grpc:
           endpoint: 0.0.0.0:4317
         http:
           endpoint: 0.0.0.0:4318
   

2. Export traces from your app to the Agent.

   Example (Python):

   from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
   from opentelemetry.sdk.trace import TracerProvider
   from opentelemetry.sdk.trace.export import BatchSpanProcessor
   from langtrace import LangtraceExporter
   
   provider = TracerProvider()
   
   # Langtrace exporter
   langtrace_exporter = LangtraceExporter(api_key="LANGTRACE_API_KEY")
   provider.add_span_processor(BatchSpanProcessor(langtrace_exporter))
   
   # Datadog Agent OTLP exporter (local agent)
   datadog_exporter = OTLPSpanExporter(
     endpoint="http://localhost:4317",
     insecure=True,
   )
   provider.add_span_processor(BatchSpanProcessor(datadog_exporter))
   

3. Configure Datadog service/env tags via environment variables:

   export OTEL_SERVICE_NAME=llm-app
   export DD_ENV=production
   export DD_SERVICE=llm-app
   export DD_VERSION=1.0.0
   

Datadog will ingest these OTLP traces and show them in APM. Langtrace and Datadog will now have identical trace data.

B. Export directly to Datadog OTLP ingest API

If you don’t run an Agent, use a Datadog OTLP endpoint (region‑specific) with the OTLP exporter and set your Datadog API key in headers:

from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

datadog_exporter = OTLPSpanExporter(
  endpoint="https://otlp.datadoghq.com/v1/traces",
  headers=(
    "DD-API-KEY=YOUR_DATADOG_API_KEY,"
    "DD-ENV=production,"
    "DD-SERVICE=llm-app"
  ),
)

Add this exporter alongside the Langtrace exporter as shown earlier.

---

Exporting Langtrace OpenTelemetry traces to Grafana (Tempo / Grafana Cloud)

Grafana typically ingests traces via Tempo or Grafana Cloud Traces, both of which accept OTLP.

A. Export directly from your app to Grafana Tempo

1. Get your Tempo OTLP endpoint.

   • Self‑hosted Tempo: e.g., http://tempo:4317
   • Grafana Cloud: OTLP endpoint and bearer token from the Grafana Cloud UI.

2. Configure OTLP exporter in your app.

   Example (Python):

   from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
   from opentelemetry.sdk.trace import TracerProvider
   from opentelemetry.sdk.trace.export import BatchSpanProcessor
   from langtrace import LangtraceExporter
   
   provider = TracerProvider()
   
   # Langtrace
   langtrace_exporter = LangtraceExporter(api_key="LANGTRACE_API_KEY")
   provider.add_span_processor(BatchSpanProcessor(langtrace_exporter))
   
   # Grafana Tempo / Grafana Cloud OTLP
   grafana_exporter = OTLPSpanExporter(
     endpoint="https://tempo-us-central-0.grafana.net:4317",  # example
     headers={
       "Authorization": "Bearer YOUR_GRAFANA_CLOUD_TOKEN"
     },
   )
   provider.add_span_processor(BatchSpanProcessor(grafana_exporter))
   

3. Add resource attributes like service name and environment:

   from opentelemetry.sdk.resources import Resource
   
   resource = Resource.create({
     "service.name": "llm-app",
     "deployment.environment": "production",
   })
   
   provider = TracerProvider(resource=resource)
   

4. Visualize in Grafana by configuring your Tempo (or Grafana Cloud Traces) data source and building dashboards around service.name, LLM latency, tokens, and error spans.

B. Export via OpenTelemetry Collector to Grafana

If you’re already using a Collector, configure it as:

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  otlp/grafana:
    endpoint: tempo-us-central-0.grafana.net:4317
    headers:
      Authorization: Bearer YOUR_GRAFANA_CLOUD_TOKEN

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/grafana]

Your app sends traces to the Collector; the Collector forwards them to Grafana. You can additionally export to Langtrace via another OTLP exporter if Langtrace provides an OTLP endpoint, or keep the Langtrace exporter in your app code.

---

Exporting Langtrace OpenTelemetry traces to Honeycomb

Honeycomb is built around distributed tracing and works well with OpenTelemetry.

A. Direct OTLP export to Honeycomb

1. Get your Honeycomb API key and Dataset name.

2. Use Honeycomb’s OTLP endpoint:

   • OTLP gRPC: https://api.honeycomb.io:4317
   • OTLP HTTP: https://api.honeycomb.io/v1/traces

3. Configure the exporter in your app.

   Example (Python):

   from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
   from opentelemetry.sdk.trace import TracerProvider
   from opentelemetry.sdk.resources import Resource
   from opentelemetry.sdk.trace.export import BatchSpanProcessor
   from langtrace import LangtraceExporter
   
   resource = Resource.create({
     "service.name": "llm-app",
   })
   
   provider = TracerProvider(resource=resource)
   
   # Langtrace
   langtrace_exporter = LangtraceExporter(api_key="LANGTRACE_API_KEY")
   provider.add_span_processor(BatchSpanProcessor(langtrace_exporter))
   
   # Honeycomb
   honeycomb_exporter = OTLPSpanExporter(
     endpoint="https://api.honeycomb.io:4317",
     headers={
       "x-honeycomb-team": "YOUR_HONEYCOMB_API_KEY",
       "x-honeycomb-dataset": "YOUR_DATASET_NAME",
     },
   )
   provider.add_span_processor(BatchSpanProcessor(honeycomb_exporter))
   

4. Explore traces in Honeycomb, filtering by service, model, latency, prompt type, or any custom attributes you attach in Langtrace spans.

B. Export via OpenTelemetry Collector to Honeycomb

Collector configuration:

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  otlp/honeycomb:
    endpoint: api.honeycomb.io:4317
    headers:
      x-honeycomb-team: YOUR_HONEYCOMB_API_KEY
      x-honeycomb-dataset: YOUR_DATASET_NAME

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/honeycomb]

Your app sends OTLP traces to the Collector; the Collector sends them on to Honeycomb.

---

Using an OpenTelemetry Collector to fan‑out to Langtrace and other backends

If you want a clean separation between your AI app and observability backends, use the Collector as a central router:

1. App → Collector (OTLP)
   Configure the Langtrace SDK to emit OTEL traces to the Collector.
2. Collector → Langtrace + Datadog/Grafana/Honeycomb
   Add multiple exporters in the Collector config.

Example Collector configuration:

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  # Datadog
  otlphttp/datadog:
    endpoint: https://otlp.datadoghq.com/v1/traces
    headers:
      DD-API-KEY: YOUR_DATADOG_API_KEY
      DD-ENV: production
      DD-SERVICE: llm-app

  # Grafana Tempo
  otlp/grafana:
    endpoint: tempo-us-central-0.grafana.net:4317
    headers:
      Authorization: Bearer YOUR_GRAFANA_CLOUD_TOKEN

  # Honeycomb
  otlp/honeycomb:
    endpoint: api.honeycomb.io:4317
    headers:
      x-honeycomb-team: YOUR_HONEYCOMB_API_KEY
      x-honeycomb-dataset: YOUR_DATASET_NAME

  # (Optional) Langtrace, if Langtrace supports OTLP ingest
  # otlp/langtrace:
  #   endpoint: <your-langtrace-otel-endpoint>
  #   headers:
  #     x-langtrace-api-key: LANGTRACE_API_KEY

processors:
  batch: {}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/datadog, otlp/grafana, otlp/honeycomb]  # add otlp/langtrace when available

This pattern lets you:

• Keep your code simple (one OTLP endpoint).
• Swap or add backends without touching app code.
• Standardize attributes, sampling, and redaction at the Collector level.

---

Best practices for exporting Langtrace traces to Datadog, Grafana, and Honeycomb

To get the most value out of Langtrace OpenTelemetry traces in other tools:

• Use consistent service names
  Set service.name in your OTEL resource (e.g., llm-app, rag-service, agent-orchestrator) so your traces are grouped reliably across platforms.

• Tag environments
  Use attributes like deployment.environment, env, or backend‑specific tags (DD_ENV, env=prod in Grafana) to separate staging vs. production.

• Propagate trace context across services
  Ensure HTTP/gRPC clients and servers use W3C trace context (or B3 if required) so traces from Langtrace‑instrumented LLM calls connect with upstream/downstream services.

• Control sampling intentionally

  • Use head‑based or tail‑based sampling in the Collector if trace volume is high.
  • Keep sampling decisions consistent across Langtrace and your other backends so you’re looking at the same subset of traffic.

• Redact sensitive data
  Before exporting traces externally, use:

  • Langtrace’s SDK options to avoid logging secrets in prompts.
  • Collector processors (e.g., attributes or transform processor) to drop or mask sensitive attributes.

---

Troubleshooting common issues

If you don’t see your Langtrace traces in Datadog, Grafana, or Honeycomb:

1. Check connectivity and endpoints

   • Ensure the OTLP endpoint is reachable from your app/Collector.
   • Verify ports (4317 gRPC, 4318 HTTP) and HTTPS vs. HTTP.

2. Verify authentication

   • Datadog: DD-API-KEY header and correct region (datadoghq.com, datadoghq.eu, etc.).
   • Grafana: Bearer token is scoped correctly.
   • Honeycomb: x-honeycomb-team and x-honeycomb-dataset headers are correct.

3. Confirm traces are being generated

   • Use debug logging for the OTEL SDK/exporter.
   • Temporarily switch to a console exporter to verify spans are emitted.

4. Check resource attributes

   • Make sure service.name is set; some backends hide traces without it.
   • Confirm that your environment filters in the UI (Datadog APM, Grafana Explore, Honeycomb query) are not excluding your service.

5. Inspect the Collector logs (if using Collector)

   • Look for export errors, misconfigured endpoints, or backpressure warnings.
   • Start with a minimal config (one exporter) and add more once the pipeline works.

---

When to rely on the Langtrace UI vs. external tools

• Use Langtrace UI when:

  • You need deep, LLM‑specific observability: prompts, completions, token counts, provider‑level metrics, agent/chain breakdowns.
  • You’re iterating quickly on model quality, safety, and cost for your LLM apps.

• Use Datadog / Grafana / Honeycomb when:

  • You want unified observability across all services (infra, APIs, queues, databases, and LLM apps).
  • You’re building cross‑system dashboards and alerts (e.g., “5xx error rate correlated with token usage spikes”).

By exporting Langtrace OpenTelemetry traces to Datadog, Grafana, or Honeycomb, you get the best of both worlds: LLM‑aware insights in Langtrace and full‑stack monitoring in your existing observability platform.