OpenTelemetry(OTel)是一个开源的、厂商中立的框架,用于生成、收集和导出遥测数据:追踪、指标和日志。它定义了数据模型、传输协议(OTLP)、应用使用的 SDK,以及接收和路由数据的 Collector。由于它没有自己的后端,你可以把同样的数据发送到 Grafana、Prometheus、Jaeger 或商业厂商,之后切换时无需重新插桩你的代码。

OpenTelemetry 中几乎所有东西都是用文本配置的:Collector 的 YAML 文件、SDK 的环境变量,以及越来越多的、同样用于 SDK 的声明式 YAML 文件。本系列专注于此,这样你的遥测配置就能像基础设施的其余部分一样被审查、版本化并可复现。

工作原理

应用使用 OpenTelemetry SDK(或注入一个 SDK 的零代码 agent)进行插桩。SDK 创建 span、指标和日志记录,并通常通过 OTLP 将它们导出到 Collector。Collector 接收数据,处理它(批处理、丰富、过滤、采样),并将其导出到一个或多个后端。

App + SDK ──OTLP──▶ Collector (receivers → processors → exporters) ──▶ Backends

核心概念

• Signals(信号) —— 追踪、指标和日志。Profile 正在成为第四种信号。
• SDK 与 API —— API 是插桩调用的东西,SDK 是负责采样、批处理和导出的实现。
• OTLP —— OpenTelemetry 协议,基于 gRPC(4317 端口)或 HTTP(4318 端口)。
• Collector —— 一个由 receiver、processor、exporter、connector 和 extension 构成的独立二进制,在 service.pipelines 中连接在一起。
• Resource(资源) —— 描述产生遥测数据的对象的属性,例如 service.name 和 deployment.environment.name。
• Semantic conventions(语义约定) —— 标准的属性名称,使来自不同语言和库的数据看起来相同。
• Sampling(采样) —— 决定保留哪些追踪,在 SDK(头部采样)或 Collector(尾部采样)中进行。
• Instrumentation(插桩) —— 手写代码、库,或零代码 agent,它们创建遥测数据。

为什么团队选择 OpenTelemetry

• 没有锁定。 通过编辑 Collector 配置来更换后端,而不是修改应用代码。
• 一条管线处理一切。 同一个 Collector 处理来自每种语言的追踪、指标和日志。
• 在边缘掌控。 在数据离开你的网络之前,对其进行过滤、脱敏、采样和路由。
• 一致的命名。 语义约定让仪表板和告警可以移植。
• 配置即代码。 Collector YAML 和 SDK 环境变量契合 Flux 和 Argo CD 之类的 GitOps 工具。

快速开始

用一个小的配置文件运行 Collector,用几个 OTEL_* 环境变量将应用指向它,并在 Collector 的 debug exporter 中观察数据。下面的指南从这里出发,带你了解零代码插桩、采样、Kubernetes 和生产加固。它们基于最近的 Collector 版本(0.16x 系列)和稳定的声明式配置 schema 编写;请查阅你所安装版本的 OpenTelemetry 文档,因为 Collector 组件的稳定性各不相同。