Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(sdk): support multiple OTLP span exporters (dual-write alongside Langfuse)

Abierto
  • ¿Algo no está bien?
#1,716 2 comentarios 1 reacción 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@hassiebp ya está trabajando en esto.

Desde el 18/6/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

feat-otel integration-otel integration-python-decorator sdk-python
Summary

We would like Langfuse SDKs to support exporting spans to more than one destination—specifically, keep the default Langfuse OTLP export and optionally forward the same spans to an additional OTLP endpoint (or custom SpanExporter).

This would follow the standard OpenTelemetry pattern of attaching multiple SpanProcessors to a single TracerProvider, without requiring users to replace Langfuse's built-in exporter.

Problem

Today, when instrumenting with the Langfuse Python SDK (@observe(), LangChain callbacks, etc.), spans are exported through Langfuse's internal OTLP pipeline to the configured Langfuse host.

Some deployments need parallel export to another OTLP-compatible backend—for example:

  • An internal observability or logging pipeline (same VPC / on-prem)
  • A secondary sink during migration or validation
  • Environment-specific routing (e.g. dev/staging copies to a local collector)

PR https://github.com/langfuse/langfuse-python/pull/1618 added optional span_exporter, which is helpful for customization, but it replaces the default Langfuse exporter rather than adding a second one. Setting generic OTEL_EXPORTER_OTLP_* env vars also does not appear to dual-write when using Langfuse's own TracerProvider initialization.

Proposed behavior

Support one or more additional exporters while preserving the default Langfuse export path.

Option A — constructor / client API

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

Langfuse(
    additional_span_exporters=[
        OTLPSpanExporter(endpoint="https://internal-collector.example.com/v1/traces"),
    ],
)

Option B — environment variables (no code changes)

# Existing Langfuse config unchanged
LANGFUSE_PUBLIC_KEY=...
LANGFUSE_SECRET_KEY=...
LANGFUSE_HOST=...

# Additional OTLP sink
LANGFUSE_ADDITIONAL_OTLP_ENDPOINT=https://internal-collector.example.com
LANGFUSE_ADDITIONAL_OTLP_HEADERS=Authorization=Bearer ...

Requirements we care about:

  • Default behavior unchanged when additional exporters are not configured
  • Additional exporters receive the same spans as Langfuse (no silent filtering unless explicitly configured later)
  • get_client() / singleton initialization should preserve additional exporters
  • Clear documentation on auth headers, timeouts, and failure isolation (one exporter failing should not break the other)
Alternatives considered
  1. Replace exporter via span_exporter (#1618) — loses default Langfuse export unless manually re-wired
  2. User-owned OTEL Collector sidecar — works but adds operational overhead; SDK-level dual export is simpler for many teams
  3. Application-level double instrumentation — fragile across frameworks and easy to break on upgrades
Questions for maintainers
  1. Is dual / multi-exporter export something the Langfuse SDK team would consider?
  2. Would you prefer an explicit additional_span_exporters API, env-based configuration, or both?
  3. Should this live in langfuse-python first, with parity in langfuse-js?
  4. Any concerns about performance, backpressure, or support burden we should address in a PR?

Happy to contribute a PR if there is alignment on the API shape. Thanks!

Lenguaje dominante
Python
Estrellas
468
Forks
349
Merge medio
16 h 1 min
PR fusionados (30 d)
20

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de langfuse/langfuse-python

Todos los issues de langfuse/langfuse-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.