支持本地 OTLP 的 Jaeger

借由 Jason Plumb (Splunk) |

2022 年 5 月，Jaeger 项目 宣布原生支持 OpenTelemetry 协议 (OTLP)。这是在许多语言的 Jaeger 客户端库进行了 慷慨的废弃周期 之后。通过这些变化，现在 OpenTelemetry 用户可以使用行业标准的 OTLP 将跟踪信息发送到 Jaeger，并且 Jaeger 客户端库的存储库已经被归档。

我们打算在不久的将来废弃 OpenTelemetry 中的 Jaeger 导出器，并希望收集您的反馈以确定废弃阶段的长度。提供反馈的最佳方式是通过 填写一个 4 个问题的调查或在 现有的草案拉取请求上发表评论。

OpenTelemetry 支持

这种互操作性对于 Jaeger 用户和 OpenTelemetry 用户来说都是一个巨大的胜利。然而，我们还没有完成。OpenTelemetry 规范仍然需要支持各种语言中的 Jaeger 客户端导出器。

这对于 Jaeger 用户和 OpenTelemetry 维护者都带来了挑战：

  1. 令人困惑的选择

    目前，用户面临着导出器的选择（Jaeger 或 OTLP），这可能会导致困惑。用户在将遥测导出到 Jaeger 时，可能会倾向于选择 Jaeger 导出器，因为名称匹配（尽管 Jaeger 现在积极鼓励使用 OTLP）。

    如果能消除这种可能令人困惑的选择，我们将能够提高用户体验并继续在单个互操作协议上标准化。当事情"为开箱即用"时，我们感到很高兴！

  2. 维护和复制

    由于 Jaeger 客户端库现已被归档，它们将不会接收更新（包括安全补丁）。为了继续正确支持 Jaeger 客户端导出器，OpenTelemetry 的作者将需要重新实现一些它之前从 Jaeger 客户端库中利用的功能。

    现在 Jaeger 支持 OTLP，这感觉就像是退步：它增加了维护负担，但好处却很少。

用户影响

建议废弃以下 OpenTelemetry 中的导出器，以使用原生的 OTLP 导出到 Jaeger：

  • Jaeger Thrift over HTTP
  • Jaeger protobuf via gRPC
  • Jaeger Thrift over UDP

除了应用程序配置更改之外，还可能涉及其他架构考虑。HTTP 和 gRPC 应该是直接替换，尽管如果之前没有访问它们，可能需要开放端口 4317 和 4318。

Thrift over UDP 意味着使用 Jaeger 代理。 使用此部署配置的用户将需要进行稍微复杂的更改，通常有以下两种选择之一：

  1. 直接接收。应用程序将从使用 Thrift+UDP 更改为直接将 OTLP 跟踪信息发送到它们的 jaeger-collector 实例。这也可能会带来抽样影响。
  2. 用一个附属的 OpenTelemetry 收集器 实例替换 Jaeger 代理。这可能会有抽样影响，并且需要更改您的基础架构部署代码。

废弃意图 - 我们希望听取您的反馈！

为了更好地支持用户和 OpenTelemetry 与 Jaeger 之间的互操作性，我们打算废弃并最终移除 OpenTelemetry 中对 Jaeger 客户端导出器的支持。

我们想听取您的反馈！我们希望听取受此更改影响的用户的意见。为了更好地做出数据驱动的决策， 我们准备了一个简短的 4 个问题的调查。

您的意见将帮助我们决定在移除之前废弃这些导出器的时间长度。

一个 草案拉取请求已经在规范中被创建 以支持这一废弃。如果您愿意贡献并提供反馈，请访问上面的链接并添加一些评论。我们希望听到您的声音。