背景
什么是可观测性
可观测性让我们无需了解具体内部细节变能够从外部了解系统并提出问题。发现问题后可观测性还应该帮助我们简单的定位并解决问题。为了实现提供可观测性的目标，需要从应用采集链路、度量和日志等足以支撑分析的数据。但如果只是单纯的通过各种工具收集到数据，不在监控和排查问题中发挥作用，也不具备可观测性。
综上可观测性描述的是 “观测-判断-优化-再观测” 这个闭环的连续性、高效性。
可观测性三剑客
要实现可观测，需要多种数据支撑，其中最为重要的三种如下
- 日志：记录特定时间发生的各种离散事件的信息。
- 指标：描述软件系统或组件随时间变化的度量数据，如微服务的 CPU 利用率等。
- 追踪：描述分布式系统各部分之间的依赖关系。
可观测现状
如同所示，可观测性领域的工具可以说是五花八门了，每个工具都有自己的数据采集、加工、展现方式
先前对各组件进行了简单的了解 https://juejin.cn/post/7152052860396503076
OpenTelemetry 简介
Opentelemetry 是去年 CNCF 除了 k8s 第二火爆的项目，旨在统一可观测性的数据采集，https://opentelemetry.io/
系统要具备可观测性，就必须采集链路、度量和日志等遥测信息。然后将遥测数据发送到可测性后端进行分析和展示。目前有许多可观察性后端，从开源工具(如Jaeger、Zipkin和Skywalking)到商业SAAS产品。每种可观测性后端采集数据的方式是不一样的，这意味着如果公司要切换可观察后端，必须重新接入新的采集器并测试代码，以便向所选的新工具发送遥测数据。
意识到这个问题后，由谷歌、微软等巨头牵头，合并了 OpenTracing、OpenCensus 两大开源项目形成了 OpenTelemetry，后续又合并了 OpenMetrics 规范。
OpenTelemetry，也被称为 OTel。是一个供应商无关的开源可观测性框架，用于测量、生产、收集、导出遥测数据。遥测数据主要包含、traces 链路、metrics 度量和 logs 日志。作为一种行业标准，已经得到了许多供应商的支持。
引入 OpenTelemetry 后带来了哪些改变如下图所示
OpenTelemetry 架构
OpenTelemetry 主要由四部分组成
- 跨语言的可观测性定义
- 用于收集、转换和导出遥测数据的收集器工具
- 为不同语言编写的 SDK
- 自动采样库以及社区贡献库
如图所示，左上角是 OpenTelemetry 为微服务应用提供的 SDK 和 API 通过自动或者手动的方式采集遥测数据。采集到的数据可以直接导入三方系统，也可以导入 OpenTelemetry 通用收集器，各大供应商也提供了支持将自身的遥测数据导入 OpenTelemetry 通用收集器。通用收集器对遥测数据进行统一处理后写入各类存储系统供分析查看使用。
OpenTelemetry 为我们做了什么
- 每种主流语言都提供了一个供应商无关的采样库，支持自动采样和手动采样
- 一个供应商无关的统一收集器
- 实现端到端的遥测数据生成、发送、收集、处理和导出
- 通过简单的配置，将处理完的遥测数据并行发送到多个可观测性后端
- 开发标准的语义约定，确保不绑定任何特定供应商
- 支持多种上下文传播格式，可以随着标准的发展演化迁移
- 对可观测性领域的承诺，永久开源，绝不弃坑
OpenTelemetry 不做什么
OpenTelemetry 不提供可观测性后端，作为替代，OpenTelemetry 通过插件架构支持将遥测数据轻松导入各种可观测性后端。
OpenTelemetry SDK
目前 OpenTelemetry 官方提供的 SDK 已经覆盖
- c++
- .NET
- Erlang
- Go
- Java
- JavaScript
- PHP
- Python
- Ruby
- Rust
- Swift
OpenTelemetry 的采集后端如图所示，可以高效的进行标准数据的采集和转换，这样我们就能做到一次采集处处可用。
目前已经支持
- 接收器 https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver
- 导出器 https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter
