背景

随着云原生概念和云原生架构的普及，传统单应用大型系统在成熟的云原生技术下被拆分成很多个职能单一的微服务模块，结合容器技术能实现应用的更快速部署、迭代和交付。但同时也极大的提升了系统的复杂性，对系统的运维也带来了更大的挑战。

在这种情况下，传统的监控方式已经无法满足云原生应用下的运维需求，至此，可观测性概念被引入云原生。

可观测性

"可观测性"源于控制论，上世纪60年代由匈牙利裔工程师鲁道夫·卡尔曼提出的概念；是指系统可以由其外部输出推断内部状态的程度。这个外部输出在IT系统中，通常是由各种应用服务产生，也就是我们常见的Trace、Metric、Log，这也是我们常说的可观测性的三大支柱。

关于可观测性和三大支柱的关系，Peter Bourgon在2017年2月的博客Metrics, tracing, and logging中有详细介绍，有兴趣的童鞋可以去看看了解下。

在云原生下的可观测性最早出现于Apple工程师Cindy Sridharan的博客"Monitoring and Observability", 其中阐述了可观测性与云原生监控的关系。

在Google，其著名的SRE体系中更是很早就奠定了可观测性的理论基础，也就是说在微服务、可观测性等概念或者出现以前，前辈们将这套理论称为监控，其中 Google SRE 特别强调白盒监控的重要性，而将当时技术圈常用的黑盒监控放在了相对次要的位置；而白盒监控正是应和了可观察性中 “主动” 的概念。

而关于监控和可观测性的概念和区别，Baron SchSchwarz大咖更是给了个明确的定义:

至此，可观测性 以新思维、新视角的方式成为云原生运维的解决方案。

OpenTelemetry

目前，主流的可观测性系统都是基于Trace、Metric、Log这三个支柱来构建的。这三个支柱的数据结构完全不一致，开源社区也是针对这三种数据类型构建了很多优秀的开源项目，比如: Pinpoint、Prometheus、Fluentd、ELK、Jaeger等。但是，这些项目都是专注于特定的支柱(数据类型)来解决特定应用场景的可观测性方案，每个项目都是独立的，提供特有的UI和使用方式；而在实际中云原生微服务的应用复杂度下，要定位具体问题往往需要三支柱的联合分析，在现有的方案中就存在多样的问题

• 系统过多: 针对三支柱，需要至少三个开源系统，每个系统还相对独立，各自维护

• 数据独立: 数据隔离且独立，无法发挥更大价值；三支柱系统都有自己的独立UI，在实际定位问题过程需要在三个系统中反复横跳

• 厂商绑定: 每个开源项目基于三支柱都有各自的数据格式，从采集端到展示端完全绑定，后续更换升级成本高

Trace、Metric、Log三支柱数据标准的不一致，是导致上面诸多问题的根本原因，而Opentelemetry正是为了统一三支柱数据格式而诞生的，目前在CNCF的孵化项目中。

OpenTelemetry是什么

在官方文档了明确定义了What is OpenTelemetry?

OpenTelemetry is a set of APIs, SDKs, tooling and integrations that are designed for the creation and management of telemetry data such as traces, metrics, and logs.

译: OpenTelemetry 是一组标准和工具的集合，旨在管理观测类数据，如 trace、metrics、logs 等。

OpenTelemetry 是 CNCF 的一个可观测性项目，旨在提供可观测性领域的标准化方案，解决观测数据的数据模型、采集、处理、导出等的标准化问题，提供与三方 vendor 无关的服务。

OpenTelemetry解决了什么

OpenTelemetry 通过 Spec 规范了观测数据的数据模型以及采集、处理、导出方法，包括 trace、metrics、logs等，详细内容见opentelemetry-specification。

为了多客户端的方便和统一数据格式，提供了具体的protobuf协议，详细内容见opentelemetry-proto。

同时作为一组标准和工具的集合，OpenTelemetry基于Spec，针对三支柱数据提供了更多的便捷功能

• 提供多语言SDK，支持主流的10+种开发语言，具体详见官方文档

• 提供基于配置管理的Collector服务，便于对trace、metric、log数据的采集、处理、导出等操作

• 提供对接各大主流厂商的Collector-Contrib服务，比如: 阿里云、AWS、Azure等

基于这些标准和工具集，开发人员能够很简单快速的实现观测数据的结构统一，并将数据发送到Collector服务，在该服务中再进行数据的额外处理(比如：traceId关联、k8s属性数据打标等)，同时数据的导出功能既兼容现有的各种开源项目也支持自定义的存储方案。

OpenTelemetry提供的可观测性标准方案为云原生应用带来了革命性的进步:

• 统一数据协议: 通过opentelemetry-specification规范了metric、trace、log的统一标准，让三支柱数据有了相同的数据格式，可以轻松实现数据互相关联，提升数据价值。

• 统一Agent: 通过Collecote的Agent模式，可以轻松完成所有可观测数据的采集、处理和传输。减少了原各自数据采集的多种Agent，既降低了系统资源的占用，也让系统架构更加简单易维护

• 云原生友好: 孵化于CNCF，对各类云原生下系统的支持更加友好，同时有越来越多的云厂商已经宣布支持OpenTelemetry，包括但不限于阿里云、AWS、Azure，未来在云上的使用会更加便捷。

• 厂商无关: 基于数据的统一标准，从数据采集到导出，不依赖任何特定的厂商，完全中立。可随意选择/更换服务商。

• 兼容性良好: 无论是数据采集还是数据的导出上，都无缝兼容现有的主流可观测性系统，包括但不限于Prometheus、OpenTracing、OpenCensus、Fluntd、Jaeger等。

OpenTelemetry的局限

OpenTelemetry规范了观测数据的统一标准，定位成为可观测性的基础设施，解决了三支柱数据的采集、传输、处理、收集的问题。但在这之后的诸多工作(数据存储、数据计算、数据关联、数据展示)暂时还是依赖各个Vender平台自己去实现，目前没有一个统一的解决方案。

虽然这些并不是Opentelemetry的目标，但其作为基础设施继续完善之后以及各种主流云厂商的加入，相信之后会有一个统一的引擎去存储Trace、Metric、Log数据，同时提供统一的平台去分析、关联、展示这些数据。

OpenTelemetry前景如何

OpenTelemetry最早是由Opentracing和OpenCensus两个开源项目合并而来，其中后者是来自Google贡献的。

2019年5月，两个开源项目合并，官方随即宣布开源OpenTelemetry项目。不久后CNCF技术监督委员会（TOC）投票同意将OpenTelemetry 作为 CNCF 的孵化项目。

2021年2月，Trace Spec达到1.0 Release！其他的也在稳步推进中，详情可见官方Status。

截止目前，各数据的统一指标进展如下

同时有越来越多的云厂商关注和贡献，从他们的贡献代码中可以看出部分云服务商提供了数据采集Receiver部分，更多的是关注数据导出Exporter部分，便于将标准化的数据导入到自身的服务中，比如阿里云的SLS。

目前项目已经处于CNCF的孵化阶段，社区非常活跃，背靠Google大爹，同时有众多主流云厂商的加入和贡献，相信在略微有点久的未来就能从CNCF毕业，成为云原生下可观测性方案的事实标准。

总结

政采云运维团队为了提升公司复杂业务下日常运维的效率，制定了开发可观测性平台的目标。在6月经过一周多调研对比后，我们选择采用OpenTelemetry作为可观测性的基础设施来实现；同时在解决OpenTelemetry局限性的问题上已经有了初步的方案和实现: 针对三支柱的采集方式都开发了一定的扩展插件用于支持数据的统一存储方案；同时通过Flink实时计算引擎去提供数据的分析、关联等操作，提升数据的价值。

在之后的文章中基于我们的方案和具体实现会为大家一一展开，尽请关注。