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

借由 Pranay Prateek (SigNoz) |

由Henrik Rexed (Dynatrace)、Michael Hausenblas (AWS)、Rynn Mancuso (Honeycomb)、Reese Lee (New Relic) 和Adriana Villela (Lightstep) 的贡献。

OpenTelemetry 终端用户组每个月都会举行会议，面向美洲（AMER）、欧洲中东与非洲（EMEA）和亚太地区（APAC）的用户。

讨论以精简咖啡形式进行，与会者可以通过Agile Coffee 栏位发布他们想要讨论的话题，与会者会对他们想要讨论的话题进行投票。

我们讨论的内容

本月讨论的一些有趣话题包括：

  • 跟踪采样
  • 发布业务指标
  • 监控 OpenTelemetry Collector 的健康状况
  • OTel Collector 的备份/缓冲能力

讨论重点

以下是本月讨论的摘要。

OpenTelemetry Collector

1 - 监控 OTel Collector 的健康状况

Q: 有关于监控 OTel Collector 的健康状况的建议或者收集代理遥测数据的模式吗？

A: 采集器可以用来从其他采集器中采集遥测数据，这不一定需要是一个不同的遥测系统。用户还应考虑收集多个信号，这样即使一个信号失败，他们也可以通过另一个信号收到警报。这里有一篇文章讨论了这个话题。

2 - OpAMP 扩展的时间表

Q: 实施OpAMP 规范的时间表是什么？

A: 目前它不是首要任务。希望社区能有一个对 OpAMP 有贡献的维护者。要追踪进展，请查看问题 #16462。

3 - OTel Collector 的缓冲能力

Q: 在终端不可用的情况下，OTel Collector 有什么备份/重试缓冲功能？

A: 目前正在开发一个实验性的存储扩展，用于支持缓冲和数据持久化。

4 - 定期剖析采集器以改善性能

Q: 是否有定期剖析采集器并持续改进性能的努力？

A: 有一个 GitHub 执行操作，可以对 OpenTelemetry 采集器进行负载测试，但没有人在改进它。

OpenTelemetry 语言 API 和 SDK

1 - Go SDK 的时间表

Q: OTel Go SDK 的完整规范兼容性的时间表是什么？

A: 在 Go OTel SDK 中，目前的进展主要集中在指标上。日志开发已被冻结。主要工作正在指标 SDK 上进行。要追踪 Go 指标的进展，请查看Metric 项目表。一旦指标完成，日志将会处理。

OpenTelemetry 跟踪

1 - 跟踪采样

Q: 是否有一种方式可以根据跨度数量对跟踪进行采样？例如：删除/截断具有超过1000个跨度的单个跟踪。

**更多背景信息：**有时，由于应用程序本身的问题，某些跟踪会生成许多不需要的跨度。在 OpenTelemetry 中是否有一种方式可以控制这个问题？更具体地说，是否有一种方式可以设置一个条件，即如果某个特定跟踪具有超过n个跨度，我们可以删除或截断跨度的数量。

A: 尾部采样处理器为用户提供了一系列采样策略。跨度计数是其中一种策略。您还可以组合多个策略。这是尾部采样处理器的链接。跨度计数策略基于最小跨度计数。某些用户可能会寻找某种排除策略。

2 - 跨度链接的用途

Q: 跨度链接的用途有哪些？

A: 跨度链接用于表示一个或多个跨度之间的因果关系。它是原始跟踪规范的一部分，现在的状态是稳定的。它可以用于链接相关但异步运行的跟踪。

例如，跨度链接可在批处理操作中使用，以链接由多个开始跨度启动的跨度。通过链接，跨度可以具有多对多的映射关系。Jaeger 在其用户界面中支持跨度链接。

OpenTelemetry 指标

1 - 支持其他指标格式

Q: OTel Collector 可以支持从其他库生成的指标，比如 statsd 库吗？

A: OpenTelemetry Collector contrib 拥有很多用于不同类型的指标的接收器。例如，如果您正在以 Prometheus 格式发送指标，您可以配置 OTel Collector 来抓取 Prometheus 指标。还有一个可用的statsd 接收器。如果您有一个已经工作的实现，那么您不需要更改它。您可以在这里查看接收器列表。

2 - 发布业务指标

Q: 您使用哪些信号来发布业务指标？例如，在某个任意时间点，发布类似计数器的内容，但仅发布一次。

A: 目前有一个与此相关的问题，您可以跟踪。业务指标的一个示例是用户着陆在特定页面，这可以通过计数器进行跟踪。

OpenTelemetry 采用和启用

1 - 如何改进来自亚太地区的贡献

Q: 我们如何改进来自亚太地区的贡献？

A: 来自社区的建议：

  • 联系当前的 OpenTelemetry 维护者并分享挑战
  • 创建来自亚太地区的维护者列表供人们可以联络
  • 为 OpenTelemetry 用户举办本地线下聚会
  • 从任何 OTel 存储库的“初学者问题”开始，并在 GitHub 问题中寻求帮助
  • 加入OTel Slack 社区，并在相关频道中提及

其他重要讨论要点

社区还讨论了以下重要要点：

自动发现要收集遥测数据的来源

Q: OTel Collector 可以自动发现已知来源并从中收集遥测数据吗？

A: 这个想法是让 OTel Collector 自行配置以从已知来源收集遥测数据。Prometheus 在 Kubernetes 中有自动服务发现。目前，采集器中没有解决此问题的功能。

有一个接收器创建者，可以根据一个观察到的端点是否与配置的规则匹配来在运行时实例化其他接收器。要使用接收器创建者，首先必须配置一个或多个观察者。使用Kubernetes 观察者，用户应能够通过 Kubernetes API 检测和报告 Kubernetes 的 pod、端口和节点端点。

OTel Collector 在 Azure 中的托管模式建议

Q: 关于在 Azure 中托管 Collector 以从 Azure App Services 和 Azure functions 收集遥测数据，有什么建议吗？

A: 通常，社区依赖于 Microsoft 的最佳实践。最新版本的 OTel 和 Azure functions 存在一些问题。您可以在这里跟踪它here。

会议笔记和记录

要更深入地了解以上主题，请查看以下内容：

加入我们！

如果您有关于如何在您的组织中使用 OpenTelemetry 的故事，我们非常乐意听到您的分享！以下是一些分享的方式：

记得在Mastodon和Twitter上关注 OpenTelemetry，并使用**#OpenTelemetry**主题分享您的故事！