OpenTelemetry终端用户讨论摘要（2023年2月）
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
贡献者：Henrik Rexed (Dynatrace), Michael Hausenblas (AWS), Rynn Mancuso (Honeycomb), Reese Lee (New Relic), and Adriana Villela (Lightstep).
OpenTelemetry 终端用户组每月为美洲 (AMER)、欧洲中东非洲 (EMEA) 和亚太 (APAC) 地区的最终用户举行会议。
讨论采用精益咖啡 (Lean Coffee) 格式进行，与会者可以就他们想讨论的话题发布到Agile Coffee 板上，然后所有参会者投票决定要讨论的内容。
我们讨论了什么
本月讨论的一些有趣话题包括：
- 跟踪采样
- 发出业务指标
- 监控 OpenTelemetry Collector 的健康状况
- OTel Collector 的备份/缓冲能力
讨论要点
以下是本月讨论的摘要。
OpenTelemetry Collector
1 - 监控 OTel Collector 的健康状况
问：关于监控 OTel Collector 健康状况或收集代理遥测数据的模式，有什么建议吗？
答：可以使用 Collector 来收集其他 Collector 的遥测数据，这实际上不需要一个独立的遥测系统。用户还应该考虑收集多种信号，这样即使一种信号失败，他们也会收到其他信号的警报。这是一篇文章讨论了这一点。
2 - OpAMP 扩展的时间表
问：是否有关于实现OpAMP 规范以进行代理管理的任何时间表？
答：目前 OpAMP 扩展不是首要任务。如果社区中有 OpAMP 的维护者会很好。要跟踪进度，请参见issue #16462。
3 - OTel Collector 的缓冲能力
问：当端点不可用时，OTel Collector 有哪些备份/重试缓冲能力？
答：目前正在开发一个实验性的存储扩展，用于支持缓冲和数据持久化。
4 - 定期对 Collector 进行性能分析以提高性能
问：是否有任何关于定期对 Collector 进行性能分析并持续改进性能的工作？
答：有一个 GitHub action 会对 OpenTelemetry Collector 运行负载测试，但目前没有人致力于改进它。
OpenTelemetry 语言 API 和 SDK
1 - Go SDK 的时间表
问：OTel Go SDK 完全符合规范的时间表是什么？
答：在 Go OTel SDK 中，目前的进展主要集中在 Metrics。Logging 的开发已暂停。Metrics SDK 正在进行主要工作。要跟踪 Go Metrics 的进展，请参见Metric 项目表。一旦 Metrics 完成，Logging 就会被处理。
OpenTelemetry Traces
1 - 跟踪采样
问：是否有办法根据 Span 的数量来采样 Traces？例如：丢弃/截断包含单个 Trace 中超过 1000 个 Span 的 Traces。
更多背景：有时，由于应用程序本身的问题，某些 Traces 会生成大量不需要的 Spans。OpenTelemetry 是否有办法控制这一点？更具体地说，是否有办法设置一个条件，如果某个 Trace 包含的 Spans 超过“n”个，则可以丢弃或截断 Spans 的数量。
答：基于尾部的采样处理器 (Tail-based sampling processor) 为用户提供了多种采样策略。Span 数量是其中一种策略。您也可以组合多种策略。这是关于尾部采样处理器的链接。Span 数量策略基于最小 Span 数量。一些用户可能在寻找某种排除策略。
2 - Span links 的用例
问：Span links 的用例是什么？
答：Span links 用于暗示一个或多个 Span 之间的因果关系。它是原始 Traces 规范的一部分，现在状态稳定。它可以用于链接相关但异步运行的 Traces。
例如，Span links 可用于批处理操作，以链接由多个发起 Span 启动的 Spans。Span 可以通过 Links 实现多对多映射。Jaeger 在其 UI 中支持 Span links。
OpenTelemetry Metrics
1 - 支持其他指标格式
问：OTel Collector 是否支持由 statsd 库等其他库生成的指标？
答：OpenTelemetry Collector contrib 包含许多适用于不同类型指标的接收器。例如，如果您以 Prometheus 格式发送指标，则可以配置 OTel Collector 来抓取 Prometheus 指标。还有一个可用的statsd 接收器。如果您有已经正常工作的组件，则无需更改它。您可以查看接收器列表。
2 - 发出业务指标
问：您使用哪些信号来发出业务指标？例如，在任意时间点，发出类似计数器的东西，但只发出一次。
答：目前有一个关于此的issue，您可以跟踪。业务指标的例子可以是用户访问特定页面，这可以用计数器来跟踪。
OpenTelemetry 采用与赋能
1 - 提高 APAC 地区的贡献度
问：如何提高 APAC 地区的贡献度？
答：社区的建议：
- 联系当前的 OpenTelemetry 维护者并分享挑战
- 创建一个来自 APAC 地区的维护者列表，人们可以联系他们
- 为 OpenTelemetry 用户举办本地线下聚会
- 一个很好的起点是任何 OTel 存储库中的 `good first issues`，并在 GitHub issues 中寻求帮助
- 加入OTel slack 社区并在相关频道中进行ping
其他重要讨论点
社区还讨论了以下重要问题：
自动发现收集遥测数据的源
问：OTel Collector 是否能够自动发现已知源并从中收集遥测数据？
答：目的是让 OTel Collector 自行配置以从已知源收集遥测数据。Prometheus 在 Kubernetes 中具有自动服务发现功能。目前，Collector 中没有任何功能可以解决这个问题。
有一个接收器创建器，可以根据观察到的端点是否匹配配置的规则，在运行时实例化其他接收器。要使用接收器创建器，您必须首先配置一个或多个观察器。通过使用Kubernetes 观察器，用户应该能够通过 Kubernetes API 检测和报告 Kubernetes Pod、端口和节点端点。
在 Azure 中托管 OTel Collector 的模式建议
问：在 Azure 中托管 Collector 以收集 Azure App Services 和 Azure functions 遥测数据的模式有什么建议吗？
答：通常，社区依赖 Microsoft 的人提供最佳实践。在 OTel 1.4 版本和 Azure functions 7 版本中存在一个问题。
会议记录和录音
关于以上主题的更深入的探讨，请查看以下内容
立即加入我们！
如果您有关于您如何在组织中使用 OpenTelemetry 的故事要分享，我们很乐意倾听！分享方式
- 加入 #otel-endusers 频道，该频道位于 CNCF Community Slack
- 加入我们每月一次的 最终用户讨论小组电话会议
- 加入我们的 OTel 实践会议
- 在 OpenTelemetry 博客 上分享您的故事
请务必在 Mastodon 和 Twitter 上关注 OpenTelemetry，并使用 #OpenTelemetry 标签分享您的故事！