Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#1,716 2 条评论 1 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@hassiebp 已经在做这个了。

开始于 2026年6月18日。

评估

这个 Issue 还没有评估数据。

描述

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!

主要语言
Python
星标
468
派生
349
平均合并
16 小时 1 分钟
30 天内合并 PR
20

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

langfuse/langfuse-python 的其他 Issue

查看 langfuse/langfuse-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。