OpenTelemetry 原生与否:LLM 可观测性里的锁定问题
2026-06-13 · OpenTelemetry, observability, lock-in
快速答案
如果一个工具是 OpenTelemetry 原生的 —— 它摄取或发出 OTLP,并遵循 OTel GenAI 语义约定 —— 那么以后切换离开它几乎不花成本,因为你的插桩代码不变,只需把端点改个指向。如果它依赖私有 SDK 或私有追踪格式,那么你写的每一行插桩都是切换成本。在我们追踪的 37 个追踪/可观测性工具里,29 个是 OpenTelemetry 原生的,8 个不是。
挑选 LLM 可观测性工具时,"它和 X 集成吗?"是个错误的首要问题。真正决定你未来迁移账单的问题是:它是 OpenTelemetry 原生的,还是把你锁进一个私有 SDK?
为什么重要
OpenTelemetry(OTel)是追踪与指标的厂商中立标准。当一个可观测性工具原生支持 OTLP 时,你的应用发出标准的 OTel span,你只需把它们指向该工具即可。用不下去了,或者想把同一份数据同时送往两个后端?改个端点就行,不用改代码。而当一个工具改用自己的 SDK 和追踪格式时,你的插桩本身就是锁定:离开就意味着把一切重新插桩。
如何分辨
我们查的是每个工具自己的文档和代码仓库,而不是它的营销话术。只有当 OTLP / OpenTelemetry SDK / GenAI 语义约定是一等公民路径(而非次要的"集成")时,我们才算它 OTel 原生。原生的例子包括 Arize Phoenix(构建于 OTel 之上)、SigNoz(从第一天起就是 OTel 优先)、Pydantic Logfire(对 OTel 的薄封装)、OpenLIT,以及 Traceloop/OpenLLMetry(其约定已被上游合入 OTel 本身),还有提供原生 OTLP 端点的托管平台(Langfuse、Datadog、New Relic、Grafana、Dynatrace)。私有优先的例子,则是主路径为自家装饰器 SDK 或日志代理、而非 OTLP 的那些工具。
其中的微妙之处
OTel 原生并不自动等于"更好" —— 私有 SDK 可能提供更丰富、更有取舍的数据采集。而且在我们自己的插桩开销基准里,所有被测 SDK 的单 span 成本相对真实 LLM 延迟都可忽略不计(远低于一次典型调用的 0.05%),尽管最轻的 OTel 路径与较重的私有路径之间相差约 7 倍。所以应把 OTel 原生当作一个战略属性 —— 它封住了你的下行风险、保持可移植 —— 而非性能裁决。
Frequently asked questions
对一个 LLM 可观测性工具来说,OpenTelemetry 原生意味着什么?
意味着该工具把摄取或发出 OpenTelemetry(OTLP)、遵循 OTel GenAI 语义约定作为一等公民路径,因此你用标准 OpenTelemetry 而非私有 SDK 来插桩 —— 并且可以重新指向端点或双路导出而不必改写代码。
有多少 LLM 可观测性工具是 OpenTelemetry 原生的?
在本索引追踪的 37 个追踪/可观测性工具中,29 个是 OpenTelemetry 原生的,8 个依赖私有 SDK 或私有追踪格式。
OpenTelemetry 原生总是更好的选择吗?
不一定。私有 SDK 可能采集到更丰富、更有取舍的数据。OTel 原生最好理解为一个把锁定降到最低、保持可移植的战略属性,而非性能排名。
不同工具的插桩开销差别大吗?
在我们的微基准里,所有被测 SDK 的单 span 开销相对真实 LLM 延迟都可忽略不计(低于一次典型 500ms 调用的 0.05%),尽管最轻的 OpenTelemetry 路径与较重的私有路径之间相差约 7 倍。