使用原生的OTLP支持Jaeger
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
早在 2022 年 5 月，Jaeger 项目就宣布了对 OpenTelemetry 协议 (OTLP) 的原生支持。在此之前，Jaeger 客户端库在多种语言中已经提供了慷慨的弃用周期。通过这些更改，OpenTelemetry 用户现在可以使用行业标准的 OTLP 将 traces 发送到 Jaeger，Jaeger 客户端库的仓库也已最终归档。
我们打算在不久的将来弃用 OpenTelemetry 中的 Jaeger 导出器，并正在征求您的反馈以确定弃用阶段的长度。提供反馈的最佳方式是填写一份 4 个问题的调查问卷或在现有的草案拉取请求上发表评论。
OpenTelemetry 支持
这种互操作性对 Jaeger 用户和 OpenTelemetry 用户来说都是一个巨大的胜利。然而，我们还没有完成。OpenTelemetry 规范仍然需要支持跨语言的 Jaeger 客户端导出器。
这给 Jaeger 用户和 OpenTelemetry 维护者都带来了挑战
令人困惑的选择
目前，用户面临导出器的选择（Jaeger 或 OTLP），这可能是一个困惑的来源。用户在将遥测数据导出到 Jaeger 时，可能会倾向于简单地选择 Jaeger 导出器，因为名称匹配（尽管 Jaeger 现在积极鼓励使用 OTLP）。
如果我们能消除这种潜在的令人困惑的选择，我们就可以改善用户体验，并继续标准化单一的可互操作协议。我们喜欢“开箱即用”的感觉！
维护和重复
由于 Jaeger 客户端库现已归档，它们将不会收到更新（包括安全补丁）。为了继续正确支持 Jaeger 客户端导出器，OpenTelemetry 作者将需要重新实现一些它以前利用 Jaeger 客户端的功能。
现在 Jaeger 支持 OTLP，这感觉像是倒退：它导致了维护负担的增加，但带来的好处却微乎其微。
用户影响
该提议是将 OpenTelemetry 中的以下导出器弃用，转而使用 Jaeger 的原生 OTLP
- HTTP 上的 Jaeger Thrift
- gRPC 上的 Jaeger protobuf
- UDP 上的 Jaeger Thrift
除了应用程序配置更改之外，还可能存在其他架构方面的考虑。HTTP 和 gRPC 应该是简单的替代方案，尽管可能需要暴露端口 4317 和 4318（如果它们尚不可用）。
UDP 上的 Thrift 暗示使用 Jaeger agent。具有此部署配置的用户需要进行稍微复杂的更改，通常是以下之一
- 直接摄取。应用程序将从使用 Thrift+UDP 更改为直接向其 `jaeger-collector` 实例发送 OTLP traces。这可能还会有采样方面的考虑。
- 用 OpenTelemetry Collector 实例替换 Jaeger agent。这可能会影响采样，并需要更改您的基础设施部署代码。
弃用意向 - 我们希望征求您的反馈！
为了更好地支持用户以及 OpenTelemetry 和 Jaeger 之间的互操作性，我们打算弃用并最终移除 OpenTelemetry 中对 Jaeger 客户端导出器的支持。
我们希望征求您的反馈！我们想听听可能受到此更改影响的用户。为了做出更明智的决定，我们准备了一份简短的 4 个问题的调查问卷。
您的意见将帮助我们选择在移除之前弃用多久。
在规范中已创建了草案 PR 以支持此弃用。如果您想贡献和提供反馈，请访问上面的链接并添加一些评论。我们希望听到您的声音。