OpenTelemetry 将指标、日志和跟踪的集合统一到单个 SDK 中，从而促进分布式系统的端到端可观察性。到 2025 年，采用该标准将使团队能够通过一致的管道监控云、边缘和本地应用程序。
为什么选择 OpenTelemetry？
- 标准化，不同语言（Java、Node.js、Go、Python）的统一API。
- 灵活性，可配置 Prometheus、Jaeger、Grafana Loki 等导出器。
- 可扩展性，高频收集而不影响性能。
- 与云提供商集成，对 AWS X-Ray、GCP Cloud Trace、Azure Monitor 的本机支持。
主要组件
- 收集器，接收仪器信号并将其转发到后端的代理。
- SDK，检测代码的库（自行检测或手动）。
- 导出器，将数据发送到存储/可视化系统的适配器。
信号如何流动
每个使用 OpenTelemetry SDK 检测的服务都会将其信号发送到中央收集器。 Collector 作为单个收集点工作，并将数据路由到适当的后端：指标发送到 Prometheus，跟踪发送到 Jaeger，日志发送到 Grafana Loki。反过来，Prometheus 为 Grafana 仪表板提供支持。这种设计将仪器与存储工具解耦，允许您交换或添加后端而无需接触应用程序代码。
自动与手动仪器
- 自我检测，只需启用代理（0），SDK 即可捕获 HTTP、DB、gRPC。
- 手动检测，为关键业务逻辑创建自定义范围。
在手动检测的情况下，逻辑很简单：应用程序获取一个命名跟踪器，在您想要观察的业务操作开始时打开一个跨度，并在结束时关闭它，即使出现错误也是如此。此跨度捕获执行时间和任何相关的自定义属性，从而提供对流程中关键点的精细可见性。
配置收集器
收集器配置分为三个块。首先，接收器定义信号如何到达，通常通过 OTLP，接受 gRPC 和 HTTP。然后，导出器指向目的地：一个端点供 Prometheus 公开指标，另一个端点供 Jaeger 接收跟踪。最后，服务块将所有内容绑定到管道中，声明指标从 OTLP 接收器到 Prometheus 导出器，跟踪从同一接收器到 Jaeger。接收、处理和导出之间的这种分离使 Collector 变得灵活。
可观察性最佳实践
- 上下文传播，在 HTTP 标头中保留 1 。
- 采样，调整采样率以避免过载（例如生产中的 10%）。
- 属性丰富，包括233、4。
- 基于 SLI/SLO 的警报，使用延迟和错误率指标。
实施清单
- 在应用程序中安装 SDK（Node、Java、Go、Python）。
- OpenTelemetry Collector 部署（[Kubernetes6 DaemonSet 或 sidecar）。
- 配置 Prometheus、Jaeger 和 Loki 的导出器。
- 定义采样和保留策略。
- 在 Grafana 中创建仪表板（延迟、吞吐量、错误）。
- 在Alertmanager 中配置警报。
- 记录跟踪模式和属性。
结论
OpenTelemetry 提供了一个统一的解决方案，用于观察复杂的系统，减少工具碎片并实现指标、日志和跟踪之间的关联。通过实施所描述的实践，您的团队可以获得完整的可见性，并可以对事件采取主动行动。
您已经使用 OpenTelemetry 了吗？在评论中分享您的经验！
另请阅读
- [分布式系统中的可观察性：日志、指标和跟踪7
- [超越日志的可观察性：OpenTelemetry 在实践中发生了什么变化8
- [站点可靠性工程指标：定义和监控 SLI、SLO 和 SLA9
- [Workers：调试、日志和 Workers Tail — 无需日志服务器即可在边缘进行观察10
- [边缘计算架构：分布式处理策略11
- [社区指标：监控在线活动中的 DAU、WAU 和 MAU12