什么是可观测性（Observability）
可观测性指如何从外部输出推断及衡量系统内部状态，描述的就是“观测-判断-优化-再观测”这个闭环的连续性、高效性。当下，应用架构从单体系统逐步转变为微服务，其中的业务逻辑随之变成微服务之间的调用与请求。资源角度来看，传统服务器这个物理单位也逐渐淡化，变成了看不见摸不到的虚拟资源模式。从以上两个变化可以看到这种弹性、标准化的架构背后，原先运维与诊断的需求也变得越来越复杂。为了应对这种变化趋势，诞生了一系列面向 DevOps 的诊断与分析系统，包括集中式日志系统（Logging）、集中式度量系统（Metrics）和分布式追踪系统（Tracing）。
、
图 1可观测三大支柱- Logging - 用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。
- Metrics 用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP请求个数可被定义为一个计数器，新请求到来时进行累加。
- Tracing -用于记录请求范围内的信息。例如，一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器。可以有效地监控微服务的网络延时并可视化微服务中的数据流转。
而日志（Logging）、度量（Metrics）、追踪（Tracing）这三个系统也被称为可观测性的“三大支柱”。
在工业界，目前针对可观测性的产品竞争激烈，但经过多年的厮杀，日志、度量两个领域基本尘埃落定。日志收集和分析大多被统一到Elastic Stack(ELK)技术栈上，如果说未来还能出现什么变化的话，也就是其中的 Logstash 能看到有被 Fluentd 取代的趋势，让 ELK 变成 EFK，但整套 Elastic Stack技术栈的地位已是相当稳固。度量方面，抛开商业化的产品，跟随着 Kubernetes 统一容器编排的步伐，Prometheus 也击败了度量领域里以 Zabbix 为代表的众多前辈，即将成为云原生时代度量监控的事实标准，虽然从市场角度来说 Prometheus 还没有达到 Kubernetes 那种“拔剑四顾，举世无敌”的程度，但是从社区活跃度上看，Prometheus 已占有绝对的优势，在 Google 和 CNCF（云原生计算基金会） 的推动下，未来前途可期。
而追踪方面的情况与日志、度量有所不同，追踪是与具体网络协议、程序语言密切相关的，这决定了追踪工具本身有较强的侵入性，通常是以插件式的探针来实现；这也意味着追踪领域很难出现一家独大的情况，通常要有多种产品来针对不同的语言和网络。近年来各种链路追踪产品层出不穷，市面上主流的工具既有AWS X-Ray 和 Google Stackdriver Trace 这样的云计算厂商产品，还有像Zipkin、Jaeger 这样来自开源社区的优秀产品。而本文将着重介绍追踪技术。
图 2 CNCF INTERACTIVE LANDSCAPE中列出的监控（度量）、日志、追踪领域的著名产品分布式追踪发展
大家应该都听说过APM(Application Performance Monitoring)，也应该听说过Distributed Tracing(分布式跟踪)，其中后者是前者的子集。分布式跟踪该名词随着微服务的流行而兴起，主要是为了解决微服务架构中请求链路过长导致的定位和监控难问题。现代分布式链路追踪公认的起源是 Google 在 2010 年发表的论文《Dapper : a Large-Scale Distributed Systems Tracing Infrastructure》，这篇论文介绍了 Google 从 2004 年开始使用的分布式追踪系统 Dapper 的实现原理。此后，所有业界有名的追踪系统，无论是国外 Twitter 的Zipkin、Naver 的Pinpoint，抑或是国内阿里的鹰眼、大众点评的CAT都受到 Dapper 论文的直接影响。广义上讲，一个完整的分布式追踪系统应该由数据收集、数据存储和数据展示三个相对独立的子系统构成，而狭义上讲的追踪则就只是特指链路追踪数据的收集部分。譬如Spring Cloud Sleuth就属于狭义的追踪系统，通常会搭配 Zipkin 作为数据展示，搭配 Elasticsearch 作为数据存储来组合使用，而前面提到的那些 Dapper 的徒子徒孙们大多都属于广义的追踪系统，广义的追踪系统就常被称为“APM 系统”（Application Performance Management）。
目前该领域可以说是竞争异常激烈，但是由此带来一个问题：每一家都有自己的一套数据采集标准和SDK，虽然几乎都是基于谷歌Dapper协议，但是彼此的实现是大相径庭的。为了推进追踪领域的产品的标准化，OpenTracing和OpenCensus应运而生，我们先来分别看看这两个规范。
OpenTracing
OpenTracing制定了一套平台无关、厂商无关的Trace协议，使得开发人员能够方便的添加或更换分布式追踪系统的实现。在2016年11月的时候CNCF技术委员会投票接受OpenTracing作为Hosted项目，这是CNCF的第三个项目，第一个是Kubernetes，第二个是Prometheus，可见CNCF对OpenTracing背后可观察性的重视。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing协议。
OpenCensus
OpenCensus的发起者为谷歌，也就是最早提出Tracing概念的公司，而OpenCensus也就是Google Dapper的社区版。OpenCensus和OpenTracing最大的不同在于除了Tracing外，它还把Metrics也包括进来，这样也可以在OpenCensus上做基础的指标监控；还一点不同是OpenCensus并不是单纯的规范制定，他还把包括数据采集的Agent、Collector一股脑都搞了。OpenCensus也有众多的追随者，最大的新闻就是微软也宣布加入，OpenCensus可谓是如虎添翼。
OpenTracing 和 OpenCensus 迅速形成了可观测性的两大阵营，一边是在这方面深耕多年的众多老牌 APM 系统厂商，另一边是分布式追踪概念的提出者 Google，以及与 Google 同样庞大的 Microsoft。对追踪系统的规范化工作，并没有平息厂商竞争的混乱，反倒是更加混乱了。
OpenTelemetry横空出世
正所谓天下大势，分久必合。OpenTracing其实是一个规范，Jaeger就是基于OpenTracing实现的开源工具，而OpenCensus则是由google开源的度量工具，简单来说，这两者在可观测性领域功能高度重合，因此，在CNCF主导下两者进行了合并，形成OpenTelemetry项目，由OpenTracing跟OpenCensus共同推进。两者各自的官网 基本不再继续维护，同时OpenTelemetry也致力于Tracing 、Logging、Metrics间的关联性。通过将OpenTracing 和OpenCensus 合并为一个开放的标准，OpenTelemetry提供了如下便利：
- 选择简单：不必在两个标准之间进行选择，OpenTelemetry可以同时兼容 OpenTracing和OpenCensus。
- 跨平台性：OpenTelemetry 支持各种语言和后端。它代表了一种厂商中立的方式，可以在不改变现有工具的情况下捕获并将遥测数据传输到后端。
- 简化可观测性：正如OpenTelemetry所说的"高质量的观测下要求高质量的遥测"。希望看到更多的厂商转向OpenTelemetry，因为它更方便，且仅需测试单一标准
。
而OpenTelemetry的核心工作目前主要集中在3个部分：
- 规范的制定，包括概念、协议、API，除了自身的协议外，还需要把这些规范和W3C、GRPC这些协议达成一致；
- 相关SDK、Tool的实现和集成，包括各类语言的SDK、代码自动注入、其他三方库（Log4j、LogBack等）的集成；
- 采集系统的实现，目前还是采用OpenCensus的采集架构，包括Agent和Collector。
由此可见，OpenTelemetry的自身定位很明确：只做数据采集和标准规范的统一，对于数据如何去使用、存储、展示、告警，官方是不涉及的，目前官方推荐使用Prometheus + Grafana做Metrics存储、展示，使用Jaeger做分布式跟踪的存储和展示。
OpenTelemetry解决了什么？
OpenTelemetry 通过 Spec 规范了观测数据的数据模型以及采集、处理、导出方法，包括 Trace、Metrics、Logs 等。
同时作为一组标准和工具的集合，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，未来在云上的使用会更加便捷。
- 厂商无关: 基于数据的统一标准，从数据采集到导出，不依赖任何特定的厂商，完全中立，可随意选择/更换服务商。
- 兼容性良好:无论是数据采集还是数据的导出上，都无缝兼容现有的主流可观测性系统，包括但不限于 rometheus、OpenTracing、OpenCensus、Fluntd、Jaeger 等。
OpenTelemetry前景
OpenTelemetry的目标是实现Metrics、Tracing、Logging的融合，作为可观测性的终极解决方案。Metrics方面：提供量化的系统内/外部各个维度的指标，一般包括Counter、Gauge、Histogram等。Tracing方面：提供了一个请求从接收到处理完毕整个生命周期的跟踪路径，通常请求都是在分布式的系统中处理，所以也叫做分布式链路追踪。Logging方面：提供系统/进程最精细化的信息，例如某个关键变量、事件、访问记录等。
这三者在可观测性上缺一不可：基于Metrics的告警发现异常，通过Tracing定位问题（可疑）模块，根据模块具体的日志详情定位到错误根源，最后再基于这次问题调查经验调整Metrics（增加或者调整报警阈值等）以便下次可以更早发现/预防此类问题。
在OpenTelemetry中试图使用Context为Metrics、Logging、Tracing提供统一的上下文，三者均可以访问到这些信息，同时Context可以随着请求链路的深入，不断往下传播：
Context数据在Task/Request的执行周期中都可以被访问到
提供统一的存储层，用于保存Context信息，并保证在各种语言和处理模型下都可以工作（例如单线程模型、线程池模型、CallBack模型、Go Routine模型等）
多种维度的关联基于元信息(标签)实现，元信息由业务确定，例如：通过Env来区别是测试还是生产环境等
提供分布式的Context传播方式，例如通过W3C的traceparent/tracestate头、GRPC协议等。
OpenTelemetry得到了越来越多的云厂商关注和贡献，从他们的贡献代码中可以看出部分云服务商提供了数据采集Receiver部分，更多的是关注数据导出Exporter部分，便于将标准化的数据导入到自身的服务中，比如阿里云的SLS。目前项目已经处于 CNCF 的孵化阶段，社区非常活跃，背靠 Google，同时有众多主流云厂商的加入和贡献，相信不久的未来就能从 CNCF 毕业，成为云原生下可观测性方案的事实标准。
从谷歌Dapper协议提出到现在已经很多年了，江湖也已经乱战了很多年，这次谷歌和微软下定决心结束江湖之乱，对于未来分布式系统的可观测性真是巨大的利好消息。我们也有理由相信在这两家巨头的主导，该项目会越发展越好，未来会有越来越多的开源项目、框架、平台，原生的使用OpenTelemetry，最终实现监控数据标准的大一统。
目前，新华三集团U-Center统一运维平台正深耕业务运维可观测领域，结合用户体验管理和应用程序性能管理，实现对业务端-端全链路监控。支持业务统一建模、统一呈现、统一分析，最终实现业务故障快速发现、快速分析、快速恢复，帮助运维部门实现技术运维向业务运维转型。
平台基于开放容器底座，实现“云、网、端”异构全域混合资源“一站式”管理，以IT资源配置管理为平台底层核心能力，通过构建运维数据中台，萃取运维数据价值，实现高效统一运维。
同时，以业务为中心，构建三层立体式数字化服务管理模型，实现端到端业务服务质量分析、实时感知用户体验。依托U-Center 统一运维平台的开放能力，以行业化客户需求为导向，联合优质生态伙伴共同构建整体运维解决方案，为企业数字化转型保驾护航。
