OpenTelemetry终端用户讨论摘要（2023年3月）

作者：Reese Lee (New Relic) |

博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。

贡献者：Henrik Rexed (Dynatrace), Michael Hausenblas (AWS), Rynn Mancuso (Honeycomb), Adriana Villela (Lightstep), 和 Pranay Prateek (SigNoz)。

OpenTelemetry 终端用户小组每月举行一次会议，面向美洲 (AMER)、欧洲中东及非洲 (EMEA) 和亚太地区 (APAC) 的用户。

会议采用 Lean Coffee 形式进行讨论，参会者被邀请将他们的话题发布到 Agile Coffee 板上，然后所有参会者对他们想讨论的内容进行投票。

我们讨论了什么

采样和 Collector 功能仍然是大家关注的重点，此外还有关于插桩和采用的问题。

讨论要点

以下是本月讨论的总结。

OpenTelemetry Collector

1 - Azure App Services 中丢失 gRPC

问：在 Azure 中运行 OTel Collector 的托管模型中，只有 HTTP 被支持（在 Azure App Service 中运行）。失去 gRPC 功能有什么风险？

答：如果 Azure 支持 HTTP/2，gRPC 可能会在那里工作，因为 gRPC 本质上是基于 HTTP/2 的，并在其之上构建了额外的复杂性。一个建议是跟进微软关于 gRPC 支持的进展，因为它可能涉及非常长时间的连接。

2 - Uptime 监控/合成

问：OTel Collector 是否具备 Uptime 监控/合成的功能？如果没有，是否有计划朝着这个方向努力？

答：健康检查可能是一个有用的参考。也可以查看 HTTP 检查接收器。

3 - Collector 发行版

问：我应该使用供应商发行的版本还是社区 Collector 发行的版本？

答：每个供应商发行的版本都会有定制化的内容，而社区 Collector 发行的版本将包含所有内容：接收器和导出器。如果你需要灵活性，那么你应该使用 OTel Collector 发行版。

4 - 接收器上的速率限制

问：是否有计划为接收器启用速率限制和断路器？设想一下，有大量客户端将遥测数据发送到同一组 OTel Collector。

更多背景：当我有用于 traces、metrics 和 logs 的 Collector，并且接收来自 100 多个独立应用程序的流量时，我该如何进行速率限制？即使只有一个客户产生大量流量，也可能影响我的 Collector 的整体健康状况。

答：使用反向代理。需要注意的是，一旦数据进入 Collector，它已经被反序列化，你已经开始向 Collector 发送大量数据了，此时进行速率限制可能有点晚了。一种方法可能是当你在配置 SDK 时添加额外的头信息，其中包含额外的信息，这将有助于负载均衡。

5 - 连接器

问：什么是连接器？

答：连接器是一个 Collector 组件，它在一个管道中消耗遥测信号作为导出器，并在另一个管道中将其作为接收器发出。 在此处阅读更多信息。

6 - upstream、downstream 和 distro 的定义

问：upstream 是什么？downstream 是什么？distro 是什么？

答：“upstream”和“downstream”这两个术语指的是系统中的服务或组件是如何相互连接的。请查看 这篇文章，了解它在软件不同情况下的应用。

“distro”是“distribution”（发行版）的缩写。有关提供发行版的供应商列表，请参阅 供应商。

采样

1 - 尾部采样

问：与仅依赖头部采样相比，在所有具有错误或高延迟的 HTTP 请求上进行尾部采样有什么潜在的缺点？关于 trace 采样是否有最佳实践？尾部采样可能会非常昂贵。

答：通常不建议使用头部采样，因为你无法用它实现你想要做的所有事情，但尾部采样确实很昂贵。采样之所以是一个复杂的话题，是因为确实没有通用的答案；此外，它还取决于你的数据分析工具提供了什么功能。例如，你是否有数据摄取或存储成本？如果你有摄取成本，你需要在数据摄取之前进行采样；如果是存储成本，你将不得不删除很多数据，所以这取决于权衡。

一个需要考虑的方面是，你可以对属性使用尾部采样，例如当 span 出现错误时，但这确实需要更多的内存。建议进一步探索：

采用、迁移和实施

1 - 常见的迁移挑战

问：开发者在迁移到 OpenTelemetry 时面临哪些常见挑战？

更多背景：我们需要迁移数百个微服务，包括许多大型单体系统，其中有大量定制化的、锁定在特定供应商及其库中的 tracing。设置代理来促进这种迁移就像同时运行两套不同的可观测性系统。

答：一位用户分享了他们的经历：他们首先使用了一个支持 OpenTelemetry 的后端。他们面临的两个挑战是：工程师的心态需要文化上的转变，以及提高对 OpenTelemetry 的认识，这些比技术挑战更重要。关键在于不要提出一个大的变革；从基于供应商的解决方案迁移到 OpenTelemetry 的过程应该是一个循序渐进的过程，而不是进行一次全面的转型。

其他建议

  • 首先从开发或测试环境开始，以建立对软件的信任
  • 选择 OTel 更成熟的堆栈，例如 Java 和 Node.js
  • 为了应对开发者的抵制，首先使用自动插桩是一个不错的步骤

2 - 启动和扩展

问：从哪里开始使用 OpenTelemetry 是个好主意？例如，是从基础设施到数据收集，还是从应用程序开始？以及如何进行扩展？

更多背景：我们的用例是端到端的可见性；目前，我们正在使用一个供应商来监控日志、指标和 traces。我们还使用 RUM（真实用户监控）等功能。我们能否用 OpenTelemetry 以可扩展的方式实现同样的目标？

答：这取决于你是要在一个新项目中开始使用 OTel，还是试图重构一个现有或旧的项目。最好从一个过渡计划开始，确保性能影响不大，然后根据需要进行扩展。一个建议是开始尝试 Java OTel 插桩，因为整体性能影响微乎其微。

另一个建议是使用 Collector 中的 主机指标接收器，通过 OpenTelemetry 来尝试基础设施监控，因为它涵盖了大量的指标，并且没有依赖项。一位用户发现，当他们从特定供应商的代理迁移到主机指标接收器进行基础设施监控时，CPU 使用率降低了 20%。

3 - 自动插桩

问：有没有办法在不更改代码的情况下自动创建 spans？

答：这取决于具体用例。

  • 自动插桩选项在 OTel 中正在成熟；例如，Java JAR 代理可以处理应用程序使用的大多数库的插桩。自动插桩也适用于 Python、.NET 和 Node.js。
  • 如果你使用 Kubernetes，可以使用 OTel Operator，它负责 K8s 上部署的应用程序的插桩。OTel Operator 还支持注入和配置自动插桩库（如果可用）（见上文）。
  • 如果你使用 AWS Lambda，你应该查看 OTel Lambda 扩展。

4 - 利用 OTel 的遥测数据

问：是否有关于利用 OTel 遥测数据的遥控标准方面的工作？

答：遥控（Telecommand）是指发送给远程系统或未直接连接到发送遥控的地点进行控制的命令（根据维基百科）。请查看 这篇论文，以及 OpAMP。

5 - 消息队列

问：消息队列有哪些用例？

答：物联网用例（汽车制造商）。目前还在进行关于消息语义约定支持的工作。

更新和沟通

1 - 统一查询标准

问：关于即将到来的可观测性数据统一查询标准工作组以及在 KubeCon EU 的 O11y Day 上的讨论，有更新吗？

答：CNCF 内的可观测性 TAG 正在努力成立一个工作组，该工作组将分析各种查询语言，并找出用例，例如，你最常见的告警和诊断类型是什么，以及你希望提供哪些不常见的模式。然后，我们将尝试找出一种方法，为跨供应商的统一标准语言提出建议。也许是类 SQL 的？

我们将在月底正式启动工作组，章程正在征求意见中。在此处查看。我们将开始参加会议并收集反馈，第一个地点将在 Observability Day。请加入 CNCF 的 Slack 实例中 #telemetry-analysis 频道的讨论：#telemetry-analysis。

2 - 文档和搜索

问：你去哪里查找文档和问题的答案？

答：我们有许多资源，包括官方文档和 GitHub 仓库。

为了帮助我们改进资源，收集终端用户的反馈将非常有益——你的查找 OTel 信息的流程是什么？你是在 Stack Overflow 上搜索答案还是提问？社区正在研究有意义的选项，以便问题可以被索引以便搜索。一个选项是 Stack Overflow。请通过以下任一渠道分享你的答案！

会议记录和录音

关于以上主题的更深入的探讨，请查看以下内容

加入我们

如果您有关于您如何在组织中使用 OpenTelemetry 的故事要分享，我们很乐意倾听！分享方式

请务必在 Mastodon 和 Twitter 上关注 OpenTelemetry，并使用 #OpenTelemetry 标签分享您的故事！

最后修改日期：2025 年 3 月 21 日：[IA] 将 `/docs/{languages,zero-code}/net` 中的 `net` 重命名为 `dotnet`，添加重定向并调整链接（#6590）（d1ef521e）