文 | David
编辑 | Vachel David
可观察性（Observability）本质上是指系统可以根据外部输出推断内部运行状态的过程。
这一概念最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。他定义：如果所有的内部状态都可以输出到信号，则此系统具有可观察性。
以现实中的一个例子来看：
汽车上都会安装各种传感器，用来测量各类指标，例如：里程、速度、发动机转速、油量等，还有一些涉及安全类的传感器，例如ABS传感器、机油压力传感器、水温传感器、碰撞传感器等。这些都是衡量汽车是否安全的必要指标。试想，如果一台汽车什么指标都没有，你还敢开吗？
随着互联网技术逐渐应用到生产的各个环节，服务的稳定性也越来越重要。许多工程师把电气工程相关的经验照搬到IT领域，开始对系统进行各个方面的监控：最开始是主要是网络监控和系统（CPU、内存、磁盘等基础指标）监控。随着IT系统变的逐渐庞大，领域更加细分化，出现了一大批开源的监控软件（例如Zabbix、Nagios、RRDTool）和商业化公司（例如NewRelic、DataDog、Dynatrace等），而监控也更加专注于业务/服务的监控。
近年来随着云原生技术的普及，PaaS和SaaS化的程度越来越高，传统的监控系统正在朝可观察性系统的放心演进。从数据角度来看，可观察性相比监控包含的范畴更广。可观察性不仅仅包括用于监控告警的系统指标，还增加了对系统内部运行行为的记录。从实用角度来看，传统监控的数据能够告诉你系统是否发生了异常，最多反应出异常的模块；而基于可观察性相关的数据，你能够快速的定位发生问题的模块以及根因。
一、Metrics Tracing Logging三板斧
上图是一个流传很广的图，这是Peter Bourgon在参加完2017 Distributed Tracing Summit后发表的一篇博文，简洁扼要地介绍了指标（Metrics）、链路（Tracing）、日志（Logging）三者的定义和关系。这三种数据在可观察性中都有各自的发挥空间，但每种数据都没办法完全被其他数据代替。
我们从一个典型的服务问题排查过程来看：
- 通过各式各样的预设报警发现异常（通常是Metrics/Logging）
- 打开监控大盘查找异常的曲线，并通过查询找到异常的模块（Metrics）
- 对这个模块以及关联日志进行查询分析，找到核心的报错信息（Logging）
- 通过详细的调用链数据定位到引起问题的代码（Tracing）
上述例子介绍了如何使用Metric、Tracing、Logging去联合排查问题，在不同的场景可能有不同的结合方案，例如简单的系统可以直接通过日志的错误信息去告警并直接定位问题，也可以根据调用链提取的基础指标（延时，错误数等）触发告警。但整体而言，一个具有良好可观察性的系统必须具备上述三种数据。
二、OpenTelemetry的前世今生
为系统暴露出Metric、Tracing、Logging这些客观性数据，目前已经有形形色色的开源系统和商业方案。简单上网逛一圈，可以整理出：
Metric：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
Tracing：Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus
Logging：ELK、Splunk、SumoLogic、Loki、Loggly
看完这些方案后你会觉得无所适从，不知道该从何处下手。然而现实也确实是这种混乱的状态，各个方案/公司都定义了一个自己的协议格式/数据类型，不同的方案之间很难兼容/互通。如果用到的所有组件都使用同一种方案还好，然而现实往往是各种方案混用，只能自己开发各类的Adapter去兼容，最后搞得焦头烂额。
这一问题在Tracing领域尤其凸显。Tracing的目的就是把系统中所有的模块和组件的交互通过Trace ID完全串联起来，如果某些组件Trace格式不统一，那这部分组件内部的调用记录就会断掉，Trace完全发挥不出价值。所以最开始的时候有了OpenTracing规范，OpenTracing定义了Trace的数据格式，各家公司可以基于这个标准去实现，基于不同实现的组件最终结合时可以完全兼容。
然而社区还有一个协议是Google发起的OpenCensus，OpenCensus除了Trace外还定义了Metric。OpenTracing和OpenCensus在云原生CNCF的大旗下最终合并成了OpenTelemetry，并成为了当今可观察性的一个准标准协议。
OpenTelemetry为我们带来了Metric、Tracing、Logging的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。除此之外，OpenTelemetry还为我们带来了众多福利：
- 统一SDK：OpenTelemetry为每个常见语言都实现了对应的SDK，未来我们的系统中只需要一个SDK就可以记录三种可观察性数据。
- 自动代码注入技术：OpenTelemetry也开始提供可以自动代码注入的实现，目前已经支持Java各类主流框架的自动注入。
- 厂商无关性：OpenTelemetry提供了Collector用于收集各个SDK发送的数据并支持对接到各种后端存储系统。
- 云原生：OpenTelemetry设计之初就已经考虑了云原生的特性，并且还提供了Kubernetes Operator用于快速部署使用。
三、OpenTelemetry万能了？
从上面的介绍，OpenTelemetry覆盖了各类Telemetry数据类型的规范定义、API定义、规范实现以及数据的获取与传输。未来我们的应用程序只需要一种SDK就可以实现所有类型数据的统一产生；在我们的集群中，只需要部署一个OpenTelemetry的Collector便可以实现所有类型数据的采集。而且Metrics、Tracing、Logging的具有相同的Meta信息，可以做无缝的关联。
一切看起来是如此的美好，但如果从可观察性的整体方案上讲，OpenTelemetry只做了数据统一生产的部分，后面如何存储、利用这些数据并没有明确的定义，而实际上这些问题也非常突出：
- 各类数据的存储方式：Metrics可以存在Prometheus、InfluxDB或者各类时序数据库；Tracing可以对接Jaeger、OpenCensus、Zipkin。如何选择以及运维这些后端是个很困难的问题
- 数据分析：如何对于采集到的数据进行统一的分析？我们需要在不同的软件对于不同的数据单独去做，可能还需要额外的一个数据库去存储分析的中间结果，然后再对中间结果继续处理...
- 可视化与关联：可观察性系统是为了可观察的，所以可视化、交互是非常重要的部分，想要在一个平台显示Metrics、Logging、Tracing并能够实现3者的关联跳转，需要很多定制化的开发工作。
- 异常检测与诊断：如何对系统进行更加有效的异常检测和根因诊断？这时就需要把OpenTelemetry的数据融入到AIOps相关的技术中。
图 | OpenTelemetry 所解决的问题是有限的
未来
虽然OpenTelemetry项目现在处于孵化阶段，各语言SDK以及Collector还没有处于准备状态，但从社区的活跃度上也能够看出各大公司对OpenTelemetry的看重，相信OpenTelemetry会在可观察性领域上大一统。
未来我们将持续关注OpenTelemetry的发展，并实时和大家分享如何基于OpenTelemetry更好地实现系统的可观察性。
