OpenTelemetry 介绍
承蒙大家厚爱,我的《Go语言之路》的纸质版图书已经上架京东,有需要的朋友请点击 此链接 购买。
OpenTelemetry 可以用于从应用程序收集数据。它是一组工具、API 和 SDK 集合,我们可以使用它们来检测、生成、收集和导出遥测数据(指标、日志和链路追踪),以帮助分析应用的性能和行为。
为什么需要分布式追踪
随着云计算、微服务架构和日益复杂的业务需求的兴起,越来越需要对软件和基础设施可观测性的需求。特别是在微服务架构中,每个请求最终可能会经过数个甚至数十个微服务)并在其间进行多次网络调用。
参照下图Uber 2018 年的微服务架构,该架构拥有 3000 多个服务。
在这种复杂的系统中,仅靠传统的日志和指标监控数据很难实现一览全局的视角,排除故障会非常困难。
- 指标:在监控/指标平台中,组件(例如服务、主机)是被观察的基本单元。我们可以通过监控/指标平台查询有关该单元随着时间推移的实际情况。例如,该服务在特定时间范围内的运行状况/吞吐量/错误率是多少?
- 日志:对于日志,被观察的基本单位是事件——例如,每当代码执行期间发生事件时,就打印一些信息。这些“事件”是开发人员在编写代码时主观定义的。使用日志的问题在于它们之间都是相互脱节的,每个组件都以自己的形式单独打印日志消息,没有简单的方法将它们联系在一起,使其更有意义。
相比之下,分布式链路追踪观察的是单个请求穿越多个组件时的情况。这使我们能够顺着请求链路查询整个分布式系统的问题,并了解复杂的互连系统中发生了什么。
借助分布式链路追踪能够帮助我们在复杂的分布式系统中快速定位问题、排除故障。
OpenTelemetry 演进历史
- Google 2010年发布的 Dapper 论文是分布式链路追踪的开端
- 2012年 Twitter 开源了 Zipkin。
- 2015年 Uber 发布了 Jaeger 的开源版本。目前 Zipkin 和 Jaeger 仍然是最流行的分布式链路追踪工具之一。
- 2015年 OpenTracing 项目被 CNCF 接受为它的第三个托管项目,致力于标准化跨组件的分布式链路追踪。
- 2017年 Google 将内部的 Census 项目开源,随后 OpenCensus 在社区中流行起来。
- 2019年初,两个现有开源项目:OpenTracing 和 OpenCensus 被宣布合并为 OpenTelemetry 项目。
- 2021年, OpenTelemetry 发布了V1.0.0,为客户端的链路追踪部分提供了稳定性保证。
- 2023 年对于 OpenTelemetry 来说是一个里程碑,因为其三个基本信号,链路追踪、指标和日志,都达到了稳定版本。
如何实现分布式链路追踪
把请求链路中进行的每个网络调用都会被捕获并表示为一个跨度。
分布式链路追踪工具将唯一的链路追踪上下文(trace ID)插入到每个请求的标头中,并借助各种实现工具确保链路追踪上下文在整个请求链路中传播。
什么是OpenTelemetry
对于 OpenTelemetry,不同的角色(Dev和Ops)侧重点也不尽相同。
如果你的角色是Dev,那么你可能更关注如何通过编写代码使程序获得可观测性。
如果你的角色是Ops,那么你可能更关注如何从多个服务中收集 traces、metrics 和 logs 数据,并将它们发送到可观测后台。
OpenTelemetry,也称为 OTel,是一个与供应商无关的开源可观测性框架,用于检测、生成、收集和导出遥测数据,如链路追踪(traces)、指标(metrics)和日志(logs)。
作为一个行业标准,OpenTelemetry 得到了40多个可观测性供应商的支持,被许多 库、服务和应用程序集成,并被众多终端用户采用。
相关概念
信号
OpenTelemetry 的目的是收集、处理和输出信号。 信号是用于描述操作系统和平台上运行的应用程序基本活动的系统输出。信号可以是你想在特定时间点测量的东西,如温度或内存使用率,也可以是你想追踪的分布式系统组件中发生的事件。你可以将不同的信号组合在一起,从不同角度观察同一项技术的内部运作。
OpenTelemetry 目前支持 traces、metrics、logs和baggage。
- trace:在分布式应用程序中的完整请求链路信息。
- 指标是在运行时捕获的服务指标,应用程序和请求指标是可用性和性能的重要指标。
- 日志是系统或应用程序在特定时间点发生的事件的文本记录。
- baggage:是在信号之间传递的上下文信息。
关于Tracing、Metrics和Logging之间的关系。
日志系统,指标系统,追踪系统这三个关注的重点不一样、占用的磁盘资源也不一样。
OTLP
开放遥测协议(OTLP)规范描述了遥测源、中间节点(如采集器和遥测后端)之间的遥测数据编码、传输和交付机制。
OTLP 是在 OpenTelemetry 项目范围内设计的通用遥测数据传输协议。
Collector
OpenTelemetry Collector 提供了一种与供应商无关的接收、处理和导出遥测数据的方式。它无需运行、操作和维护多个代理/收集器。它具有更好的可扩展性,支持向一个或多个开源或商业后端发送开源可观测性数据格式(如 Jaeger、Prometheus、Fluent Bit 等)。本地收集器代理是仪器库导出遥测数据的默认位置。
可观测后台
Jaeger 和 Zipkin 是社区中比较流行的方案,他们都提供有可视化的WebUI方便查询。
下图是 Jaeger UI界面。
更多
Apache SkyWalking 是一个开源的应用程序性能监控解决方案,用于分布式系统的应用程序性能监视工具,特别是为微服务、云原生和基于容器(Kubernetes)架构设计的,提供链路追踪、指标聚合、报警和可视化。
OpenTelemetry Go 语言相关内容,请查看OpenTelemetry Go快速指南。
参考资料
https://segmentfault.com/a/1190000041700848
https://hackernoon.com/distributed-tracing-past-present-and-future
https://tracetest.io/blog/tracing-the-history-of-distributed-tracing-opentelemetry
https://cloudnative.to/blog/why-the-latest-advances-in-opentelemetry-are-significant/
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
https://opentelemetry.io/docs/
https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html