简介

OpenTelemetry 简称 OTel，是 CNCF 的一个可观测性项目
OpenTelemetry 旨在提供可观测性领域的标准化方案
- 解决遥测数据的数据建模、采集、处理和导出等标准化问题，并能将数据发送到后端 - 避免厂商锁定

历史

在 OpenTelemetry 之前，已经出现过 OpenTracing 和 OpenCensus 两套标准
在 APM 领域，有 Jaeger、Pinpoint、Zipkin 等多个开源产品，都有独立的数据采集标准和 SDK
OpenTracing 制订了一套与平台和厂商无关的协议标准，能够方便地添加或者更换底层 APM 实现
- 2016 年 11 月，CNCF 接受 OpenTracing 成为第三个项目 - Kubernetes + Prometheus
OpenCensus 由谷歌发起，包括 Metrics，而微软也加入了 OpenCensus
在功能和特性上，OpenTracing 和 OpenCensus 差不多，都想统一对方，此时 OpenTelemetry 横空出世
OpenTelemetry
- 同时兼容 OpenTracing 和 OpenCensus
- 支持各种语言和后端 - OpenTelemetry 本身不提供后端
- 支持厂商中立 - 在不改变现有工具的情况下捕获遥测数据并将其传输到后端

Specification + API / SDK + Collector

跨语言规范描述了所有实现的跨语言要求和数据模型
- 遥测客户端内部实现所需要的标准和定义 + 与外部通信时需要实现的协议规范
主要包含
- API - 定义用于生成和关联 Tracing、Metrics 和 Logs 的数据类型和操作
- SDK - 定义 API 特定语言实现的要求，同时还定义配置、数据处理和导出等概念
- 数据 - 定义遥测后端可以支持的 OpenTelemetry 协议和与厂商无关的语义约定
OTLP - OpenTelemetry Protocol
- OTLP 是 OpenTelemetry 原生的遥测信号传递协议
- OpenTelemetry 项目组件支持 Zipkin V2 或 Jaeger Thrift 协议格式的实现 - 第三方贡献库
- OTLP 的数据模型定义是基于 ProtoBuf 完成的

API 可以让开发者对应用程序代码进行 Instrument，而 SDK 是 API 的具体实现，与开发语言是相关的
Instrument 是将系统状态数据（遥测数据-Telemetry）发送到后端，遥测数据包括 - Metrics + Logs + Tracing
- 遥测数据记录了处理特定请求时的代码行为，可以对应用系统的状态进行分析
Instrument 的方式 - 手动增加代码生成遥测数据 + 以探针的方式自动收集数据
OpenTelemetry 为每种语言提供了基础的监控客户端 API 和 SDK

部署模式

Agent 模式
- 把 Collector 部署在应用程序所在的主机内（Kubernetes DaemonSet or Kubernetes Sidecar）
Gateway 模式
- 把 Collector 当作一个独立的中间件，应用把采集到的遥测数据发往到该中间件

OpenTelemetry 在 Logs 方面还不稳定

Grafana Tempo
- Grafana Tempo 是一个开源、易于使用且大规模的分布式追踪后端
- Tempo 具有成本效益，只需要对象存储即可运行，可以和 Grafana、Prometheus 和 Loki 深度集成
- Tempo 可以与任何开源 Tracing 协议一起使用 - Jaeger、Zipkin、OpenTelemetry
Grafana Loki - Like Prometheus, but for logs
- Grafana Loki 是一个水平可扩展、高可用性、多租户的日志聚合系统
- Grafana Loki 的设计非常经济高效且易于操作，不会为日志内容编制索引，而是为每个日志流编制一组标签
- OpenTelemetry 为对应的日志打上 TraceId 和 SpanId 等标签
- Grafana Loki 并不能高效分析和处理大型生产系统的日志