OpenTelemetry 2023年1月份终端用户讨论总结

借由 Adriana Villela (Lightstep) |

由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（采集器）
  • Service Graph Processor（采集器）
  • 信号相关性（例如指标/追踪相关性、日志/追踪相关性）

我们将对这些主题进行详细探讨和介绍！

讨论重点

以下是本月讨论的摘要。

OpenTelemetry 采集器

1- OpenTelemetry Transformation Language (OTTL)（OpenTelemetry 转换语言）

问： 输出器会支持 OTTL 吗（一种用于转换 OpenTelemetry 数据的语言）？使用案例：需要对数据进行转换，但不想在处理器中进行转换。

答： 由于关注点分离的原因，不太可能在输出器中加入 OTTL；但这可能是连接器（一种新的采集器组件，作为输出器/接收器对加入流水线起到连接作用）或路由处理器的使用案例。路由处理器可以从 HTTP 请求或属性中读取数据，并将其路由到指定的输出器。

2- Service Graph Processor（服务图处理器）

问： 如何利用 OpenTelemetry 生成服务图、生成指标并将数据发送到可视化工具？

答： Service Graph Processor 可以生成服务图。此处理器目前仍处于 alpha 版本，因此在与服务图相关的依赖项映射方面存在一些已知问题。一个追踪片段并不包含完整的上下文，为了获得完整的画面，您需要将追踪片段发送到一个集中式服务。

3- 在流水线中分流数据

问： 如果我想使用采集器将不同数据集发送到不同后端时，有什么最佳方法？

答： Connectors （一种新的采集器组件，作为输出器/接收器对加入流水线起到连接作用）可以用来解决这个问题。即将推出连接器。有关更多信息，请参阅连接器 PR 这里。

另一种方法是使用 路由处理器。路由处理器可以从 HTTP 请求或属性中读取数据，并将其路由到指定的输出器。这是通过创建新的网络连接来完成的，这可能会导致此方法效率低下。

4- 处理遥测数据中的时间漂移

问： 当服务器的时钟不同步时，可能会出现一些数据点被记录在未来的情况。在 OTel 采集器中能否实施一些措施来减轻这个问题？

答： 时钟偏差总是会发生的。在微服务架构中尤其如此，时钟不可能同步。生成遥测数据的系统所有者更适合理解时钟细微差别。采集器不适合解决这个问题。

5- 高级采集器部署和配置

问： 在什么情况下应该水平扩展我的 Pod，而不是修改单个采集器的配置？何时添加更多采集器或更改采集器配置？

答： 在部署和配置采集器时有几点需要考虑。

  • 如果采集器中只有无状态组件，可以根据度量指标进行扩展（添加更多副本）。
  • 您可能需要根据正在进行的处理类型来分片流水线。例如，创建一个指标流水线、一个日志流水线和一个追踪流水线，因为每个流水线的工作负载是不同的。
  • 您可能希望根据正在处理的数据类型来拆分采集器。如果有一个命名空间中有更多的数据与个人身份信息（PII）相关，那么您可能希望为该命名空间专门使用一个采集器，该采集器使用属性处理器。

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与Perl的问题。还请参阅此页面以获取更多信息。

2- Python 仪表化

问： Python 自动仪表化有多成熟？使用 OpenTelemetry Python 的开发人员有什么经验？

答： Python 自动仪表化仍处于测试阶段；但有公司在生产中使用 OTel Python，因此它可能不会在生产环境中引起任何问题。作为一个 SIG，OTel Python 尽量减少破坏性变更，但像其他所有库一样，不能保证不存在破坏性变更。尚没有确定 Python 仪表化将何时被标记为稳定的时间表。

其他事项

1- OpenTelemetry 样例

问： 用户在哪里可以了解更多关于样例以及它们在实际世界中的使用方法？

答： 样例用于将 OpenTelemetry 的指标与追踪进行关联。样例目前仍处于早期开发阶段，还有很多工作需要做。有关样例的最新信息，请参阅 CNCF 上的#otel-metrics 频道Slack。还请参阅Michael Hausenblas 最近关于此主题的演讲。

2- 追踪和日志之间的关联

问： 有没有更容易将追踪与日志关联起来的方法？

答： 实施关联需要时间，并且还在不断改进中。对于某些语言（如 Java、Go），关联工作比其他语言更成熟。最好的方法是在适用于您情况的特定语言存储库中提出此问题。一种可能的解决方法是从日志级别开始追踪，即每个日志将有其自己关联的追踪。

3- Profiling

问： OpenTelemetry 的 Profile 功能的情况如何？

答： OpenTelemetry 的 Profile 功能有一个被接受并且正在积极进行讨论和开发的提案。目前的重点是在开始 SDK 工作之前完成协议的最终化。您可以查看 GitHub 上的Profiling 仓库以及 GitHub 上的Profiling Vision pull request。

4- 上下文传播

问： 浏览器不能自动追踪上下文传播，必须手动进行。目前的解决方法会带来很大的开销。该问题如何解决？

答： 解决此问题的方法是加入JavaScript SIG并在那里提出问题。如果有人积极开发一个 API 来解决这个问题，那么将它贡献给 OTel 社区将是一件好事。

会议记录和录像

如果您想要深入了解上述主题，请参阅以下链接：

未来，我们将记录所有终端用户讨论会议。

加入我们！

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

请确保关注 OpenTelemetry 的 Mastodon 和 Twitter，并使用 #OpenTelemetry 标签分享您的故事！