2023 年 1 月 OpenTelemetry 终端用户讨论摘要
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
来自 Henrik Rexed (Dynatrace)、Michael Hausenblas (AWS)、Pranay Prateek (SigNoz)、Rynn Mancuso (Honeycomb) 和 Reese Lee (New Relic) 的贡献。
每个月，OpenTelemetry (OTel) 社区的用户会聚在一起讨论他们如何在实际生活中使用 OpenTelemetry。为美洲 (AMER)、欧洲中东非洲 (EMEA) 和亚太地区 (APAC) 的用户举办了会议。讨论采用 精益咖啡（Lean Coffee）格式进行，与会者被邀请将他们想讨论的主题发布到 Agile Coffee 板上，如下所示，所有与会者投票决定他们想谈论的内容。
这是结识 OpenTelemetry 社区中其他用户、学习和分享在实际中如何使用 OpenTelemetry 的宝贵经验的好方法。每次会议都会有一位 OTel 治理委员会成员和/或维护者参加，以帮助回答问题、倾听用户反馈，并提供有关所讨论主题的额外背景信息和见解。
这是我们每月 OTel 终端用户讨论摘要系列博客文章的第一篇，从 2023 年 1 月的会议开始。
我们讨论了什么
本月，我们在三次会议中看到了几个共同的主题。
- OpenTelemetry 采用与赋能
- Connectors (Collector)
- Service Graph Processor (Collector)
- 信号关联（例如，metrics/traces 关联，logs/traces 关联）
我们将深入探讨这些以及更多内容！
讨论亮点
以下是本月讨论的摘要。
OpenTelemetry Collector
1- OpenTelemetry 转换语言 (OTTL)
问： Exporters 是否会支持 OTTL（一种用于转换 OpenTelemetry 数据的语言）？用例：需要转换数据，但不想在 processor 中进行。
答： 由于关注点分离，OTTL 不太可能被添加到 exporters 中；但是，这可能是 connectors（一种新的 Collector 组件，充当 exporter/receiver 对来连接管道）或 routing processor 的用例。路由处理器从 HTTP 请求或属性读取数据，并将其路由到指定的 exporter。
2- 服务图处理器
问： 如何使用 OpenTelemetry 生成服务图、生成指标并将数据发送到可视化工具？
答： Service Graph Processor 可生成服务图。此处理器仍处于 alpha 阶段，因此，关于服务图在依赖关系映射方面存在一些已知问题。一个 span 没有完整的上下文，为了获得完整的图景，您需要将 spans 发送到集中式服务。
3- 管道中数据的分叉
问： 如果我想使用 Collector 将不同数据集发送到不同的后端，最好的方法是什么？
答： 可以使用 Connectors（一种新的 Collector 组件，充当 exporter/receiver 对来连接管道）来解决此问题。Connectors 即将发布。有关更多信息，请参阅 Connector PR。
另一种方法是使用 routing processor。路由处理器从 HTTP 请求或属性读取数据，并将其路由到指定的 exporter。这是通过建立新的网络连接来完成的，这可能会使此方法效率低下。
4- 管理遥测数据中的时间漂移
问： 当服务器上的时钟不同步时，可能会导致一些数据点在未来被记录。是否可以在 OTel Collector 上实现一些功能来缓解这种情况？
答： 时钟偏移总是会发生。时钟无法完全同步，尤其是在微服务架构中。生成遥测数据的系统的所有者更能理解时钟的细微差别。Collector 不适合解决这个问题。
5- Collector 的高级部署和配置
问： 我应该何时水平扩展我的 pod，何时修改单个 collector 的配置？何时添加更多 collector 或更改 collector 配置？
答： 在部署和配置 Collectors 时，需要考虑一些因素。
- 如果您的 Collector 中只有无状态组件，您可以根据指标进行扩展（添加更多副本）。
- 您可能需要根据您正在进行的处理类型来分片您的管道。例如，创建一个 metrics 管道、一个 logs 管道和一个 traces 管道，因为这些管道的工作负载是不同的。
- 您可能需要根据正在处理的数据类型来拆分您的 Collectors。如果有一个命名空间，其中有更多数据是 个人身份信息 (PII)，您可能希望为该命名空间有一个专用 Collector，它使用 attributes processor。
OpenTelemetry 采用与赋能
问： 那么，您已决定在您的组织中使用 OpenTelemetry……接下来呢？在不让开发人员感到不知所措的情况下，推广 OpenTelemetry 采用并让他们对使用 OpenTelemetry 感到兴奋的最佳方法是什么？
答： 社区提出的一些建议：
- 寻找愿意成为 OpenTelemetry 推广者的人。
- 让新手开发人员与更熟悉 OpenTelemetry 的开发人员配对。
- 直到插桩了几个服务，才能看到 OpenTelemetry 的真正价值，才能了解事物是如何被串联起来的。
- 开发人员必须在思想上准备好开始插桩他们的代码。请记住，这可能意味着要修改现有代码以进行插桩。
- 采用 OpenTelemetry 的“大爆炸”方法可能不是最佳选择，因为它可能对组织来说过于庞大。从一两个组件开始。
OpenTelemetry 语言 API 和 SDK
1- 新语言的插桩
问： 如何查找有关不同语言 OTel 实现的信息，例如 Dart 和 Lua？
答： CNCF Slack 始终是开始搜索的好地方。那里有特定于语言的频道，遵循 otel-<language_name> 的命名约定。如果您找不到您所需语言的频道，请随时在 OpenTelemetry CNCF Slack 频道或 GitHub 上发起讨论，例如 这个关于 OTel for Perl 的 issue。请同时查看 此页面以获取更多信息。
2- Python 插桩
问： Python 自动插桩的成熟度如何？使用 OpenTelemetry Python 的用户有哪些经验？
答： Python 自动插桩处于 beta 阶段；但是，有些公司已在生产环境中使用 OTel Python，因此它可能不会导致生产环境出现任何问题。作为 SIG，OTel Python 试图最大限度地减少发布破坏性更改，但与所有事物一样，无法保证不会发生破坏性更改。关于 Python 插桩何时被标记为稳定，目前没有确切的时间表。
杂项
1- OpenTelemetry 示例
问： 用户可以在哪里了解更多关于 Exemplars 的信息以及它们在现实世界中的使用情况？
答： Exemplars 用于关联 OpenTelemetry metrics 与 traces。Exemplars 目前处于开发的早期阶段，仍有许多工作要做。有关 Exemplars 状态的更多信息，请查看 CNCF Slack 中的 #otel-metrics 频道。另请参阅 Michael Hausenblas 最近关于此主题的演讲。
2- Trace 和 Logs 之间的关联
问： 是否有更轻松地将 traces 与 logs 相关联的方法？
答： 实现关联需要时间和持续的努力。对于某些语言（例如 Java、Go），关联工作比其他语言更成熟。最好的方法是在与您的情况相关的特定语言的存储库中提出此问题。一种可能的解决方法是从日志级别开始追踪，这样每个日志都会有自己关联的追踪。
3- 剖析
问： OpenTelemetry 中 Profiling 的状态如何？
答： 有一个关于 profiling 的 OTel 提案，该提案已被接受并正在积极进行中和讨论中。目前的重点是最终确定协议，然后才能开始 SDK 工作。您可以在 GitHub 上的 profiling 存储库以及 GitHub 上的 Profiling Vision pull request 中查看。
4- 上下文传播
问： 浏览器无法自动跟踪上下文传播，因此必须手动完成。当前解决方法带来了很多开销。如何解决这个问题？
答： 解决此问题的方法是加入 JavaScript SIG 并在此处提出问题。如果有人正在积极开发 API 来在内部解决此问题，将其贡献给 OTel 社区将非常有益。
会议记录和录音
要深入了解以上主题，请查看以下内容：
今后，我们将录制所有终端用户讨论会议。
立即加入我们！
如果您有关于您如何在组织中使用 OpenTelemetry 的故事要分享，我们很乐意倾听！分享方式
- 加入 #otel-endusers 频道，该频道位于 CNCF Community Slack
- 加入我们每月一次的 最终用户讨论小组电话会议
- 加入我们的 OTel 实践会议
- 在 OpenTelemetry 博客 上分享您的故事
请务必在 Mastodon 和 Twitter 上关注 OpenTelemetry，并使用 #OpenTelemetry 标签分享您的故事！