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

借由 Reese Lee (New Relic) |

由Henrik Rexed (Dynatrace)、Michael Hausenblas (AWS)、Rynn Mancuso (Honeycomb)、Adriana Villela (Lightstep)和Pranay Prateek (SigNoz)共同贡献。

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

讨论采用精益咖啡形式，每个人都可以在Agile Coffee的看板上发布话题，与会者可以投票选择他们想讨论的话题。

我们讨论了什么

抽样和收集器功能仍然是感兴趣的话题，除此之外还有关于仪表和采用的问题。

讨论亮点

以下是本月讨论的摘要。

OpenTelemetry收集器

1 - Azure App Services丧失gRPC的问题

Q： 在查看Azure中OTel收集器的托管模型时，只支持HTTP（用于在Azure App Service中运行）。丧失gRPC功能会有什么风险？

A： 如果Azure支持HTTP/2，则在那里可能可以使用gRPC，因为gRPC在底层是建立在HTTP/2之上的，但额外加入了一些复杂性。建议是与Microsoft跟进关于gRPC支持的问题，因为它可能有非常长时间运行的连接。

2 - 可用性监测/合成监测

Q： OTel收集器是否具备进行可用性监测/合成监测的能力？如果没有，是否有计划朝着这个方向发展？

A： 可以参考 健康检查，也可以查看 HTTP检查接收器。

3 - 收集器版本

Q： 我应该使用供应商分发版本还是社区收集器分发版本？

A： 每个供应商分发版本都会带有定制化，而社区收集器分发版本会包括所有内容：接收器和导出器。如果需要灵活性，建议使用OTel收集器发行版。

4 - 接收器的速率限制

Q： 是否有计划在接收器上启用速率限制和断路器功能？想象一下，有很多客户端将遥测发送到相同的一组OTel收集器的情况。

更多背景： 在我有跟踪、指标和日志的收集器，我接收来自100多个独立应用程序的流量的情况下，如何进行速率限制？如果有一个客户端正在产生大量流量，可能会影响到我的收集器的整体健康状况。

A： 使用反向代理。需要注意的是，一旦数据在收集器内部，数据已经被反序列化，而且已经开始批量发送到收集器，所以在那一点上进行速率限制有点晚了。其中一种方法可能是在配置SDK时添加附加信息的头部，这有助于负载平衡。

5 - 连接器

Q： 什么是连接器？

A： 连接器是作为一种导出器在一个管道中接收遥测信号，然后作为接收器在另一个管道中发出的收集器组件。 在这里阅读更多。

6 - 上游、下游和发行版的定义

Q： 上游是什么？下游是什么？发行版是什么？

A： “上游"和"下游"这些术语用于描述系统中的服务或组件彼此如何连接。可以查看 这篇文章以了解更多信息，因为它适用于软件中的不同情况。

术语"发行版"是"分发"一词的简称。有关提供发行版的供应商列表，请参见Vendors。

抽样

1 - Tail抽样

Q： 针对所有具有错误或长延迟的HTTP请求，相对于仅依赖于基于头的抽样，尾部抽样有哪些被认为是不好的一面？关于跟踪抽样，有哪些最佳实践？尾部抽样可能会非常昂贵。

A： 通常不建议使用基于头的抽样，因为它无法满足您想要达到的100%的目标，但尾部抽样确实很昂贵。抽样如此复杂的原因在于没有一个通用的答案；此外，它还取决于数据分析工具所提供的功能。例如，您是否有数据摄取或存储成本？如果有数据摄取成本，您将希望在数据被摄取之前进行抽样；如果是存储成本，您将不得不删除大量数据，所以这取决于权衡。

有一件事要考虑的是，您可以在属性上使用尾部抽样，比如对于跨度中是否有错误，但这会占用更多的内存。建议进一步探索以下内容：

采用、迁移和实施

1 - 常见的迁移挑战

Q： 开发人员在迁移到OpenTelemetry时面临的常见挑战是什么？

更多背景： 我们有数百个需要迁移的微服务，其中包括具有大量自定义跟踪的大型单体系统和特定供应商及其库的锁定。设置代理以促进这种迁移就像同时运行两套不同的可观测性系统一样。

A： 一位用户分享了他们的经验：他们开始使用一个支持OpenTelemetry的后端。他们所面临的两个挑战是：工程师思维方式的文化变革，以及提高对OpenTelemetry的认知，这些挑战比技术挑战更大。关键是不提议进行一次大的变革；从基于供应商的解决方案向OpenTelemetry的移动应该是一个逐步的过程，而不是进行全面的转变。

其他建议：

  • 首先从开发或测试环境开始，以建立对软件的信任
  • 选择OTel更强大的堆栈，例如Java和Node.js
  • 对于应对开发人员的抵制态度，使用自动仪表模块是一个好的开始

2 - 开始和扩展

Q： 使用OpenTelemetry，从基础架构到数据收集，或者从应用程序开始，哪个是一个好的起点？如何扩展它？

更多背景： 我们的用例是端到端的可视性；目前，我们使用供应商进行日志、指标和跟踪的监控。我们也使用像RUM（实时用户监控）这样的功能。我们能否使用OpenTelemetry进行相同的操作，并且可以扩展到规模？

A： 这取决于您是在一个新项目中开始使用OTel，还是尝试重组现有或旧项目。最好是从一个过渡计划开始，确保性能影响不大，并在需要时进行扩展。一种建议是从Java的OTel仪表化开始实验，因为整体性能影响可以忽略不计。

另一个建议是使用OpenTelemetry进行基础架构监控，可以利用收集器中的 主机度量接收器，它涵盖了许多度量，并且没有依赖性。有一个用户在从特定供应商的代理切换到主机度量接收器进行基础架构监控后，CPU使用率减少了20%。

3 - 自动仪表化

Q： 是否有一种无需更改代码而自动创建跨度的方法？

A： 这取决于用例：

  • OpenTelemetry中的自动仪表化选项正在不断成熟；例如，Java JAR代理负责为应用程序仪表化大部分库。还可以为Python、.NET和Node.js进行自动仪表化。
  • 如果使用Kubernetes，可以使用OTel运算符，它负责K8s上部署的应用程序的仪表化。OTel运算符还支持在可用的情况下注入和配置自动仪表化库（见上面的点）。
  • 如果使用AWS Lambda，可以看一下 OTel Lambda扩展。

4 - 利用OTel的遥测数据

Q： 是否有与利用OTel的遥测数据相关的远程系统控制标准工作？

A： “远程控制指的是从发送遥控指令的地方控制着未直接连接的远程系统或系统（根据维基百科）。可以查看 这篇论文和 OpAMP。

5 - 消息代理

Q： 有哪些消息代理的用例？

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

更新和通信

1 - 统一的查询标准

Q： 关于可观测数据的统一查询标准工作小组和在KubeCon EU的O11y Day上的讨论是否有更新？

A： CNCF的可观测性技术咨询组（TAG）正在努力启动一个工作组，该工作组将分析各种查询语言，并制定用例，例如，你最常见的警报和诊断类型是什么，你想要有哪些不常见模式可用？然后，我们希望看看是否有任何方式可以提出一个统一的标准语言建议，跨供应商。也许是SQL-ish？

我们将于本月底正式启动工作组；章程已经开放供评论。 在这里查看。 我们将开始参加会议巡回赛并汇集反馈，第一个地方将是 可观测性日活动。 加入讨论，在CNCF的Slack实例的 #telemetry-analysis频道。

2 - 文档和搜索

Q： 您在哪里查找文档和问题的答案？

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

为了帮助我们改进我们的资源，从您作为终端用户的角度收集反馈将非常有帮助 - 您查找OTel信息的过程是什么？您是否在Stack Overflow上搜索答案或发布问题？社区正在研究合理的选择，以便问题可以进行索引。一个选择是Stack Overflow。请使用以下任一途径分享您的答案！

会议记录和录音

想深入了解上述话题，请查看以下内容：

加入我们

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

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