IT领域的可观察性
可观察性（Observability）本质上是指系统可以根据外部输出推断内部运行状态的过程。
这一概念最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动态系统提出的概念。若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观察性。
以现实中的一个例子来看：
汽车上都会安装各种传感器，用来测量各类指标，例如：里程、速度、发动机转速、油量等，当然还有一些涉及安全类的传感器，例如空气流量计、ABS传感器、机油压力传感器、水温传感器、碰撞传感器等，这些都是衡量汽车是否安全的必要指标。试想，如果一台汽车什么指标都没有，你还敢开吗？
随着IT技术逐渐应用到生产的各个环节，系统的稳定性也越来越重要，我们把电气工程相关的经验照搬到IT领域，开始对系统进行各个方面的监控：最开始是主要是指基于SNMP（简单网络管理协议）的网络监控和系统（CPU、内存、磁盘等基础指标）监控。随着IT系统变的逐渐庞大，领域更加细分化，出现了一大批开源的监控软件（例如Zabbix、Nagios、RRDTool）和商业化公司（例如NewRelic、DataDog、Dynatrace等），而监控也更加专注于业务/服务的监控。
近年来随着云原生技术的普及，PaaS和SaaS化的程度越来越高，传统的监控系统正在朝可观察性系统的方向演进。从数据角度来看，可观察性相比监控包含的范畴更广。可观察性不仅仅包括用于监控告警的系统指标，还增加了对系统内部运行行为的记录。从实用角度来看，传统监控的数据能够告诉你系统是否发生了异常，最多反应出异常的模块；而基于可观察性相关的数据，你能够快速的定位发生问题的模块以及根因。
Metrics Tracing Logging三板斧
上面这幅图详细大家非常熟悉，这是Peter Bourgon在参加完2017 Distributed Tracing Summit后发表的一篇博文，简洁扼要地介绍了Metrics、Tracing、Logging三者的定义和关系。这三种数据在可观察性中都有各自的发挥空间，每种数据都没办法完全被其他数据代替。
以Grafana Loki中介绍中的一个典型问题排查过程来看：
1. 最开始我们通过各式各样的预设报警发现异常（通常是Metrics/Logging）
2. 发现异常后，打开监控大盘查找异常的曲线，并通过各种查询/统计找到异常的模块（Metrics）
3. 对这个模块以及关联的日志进行查询/统计分析，找到核心的报错信息（Logging）
4. 最后通过详细的调用链数据定位到引起问题的代码（Tracing）
上述例子介绍了如何使用Metric、Tracing、Logging去联合排查问题，当然根据不同的场景可以有不同的结合方案，例如简单的系统可以直接通过日志的错误信息去告警并直接定位问题，也可以根据调用链提取的基础指标（Latency、ErrorCode）触发告警。但整体而言，一个具有良好可观察性的系统必须具备上述三种数据。
OpenTelemetry的前世今生
当我们了解到需要为系统暴露出Metric、Tracing、Logging这些客观性数据后，开始上网查找一些开源/商业方案，形形色色的系统和方案映入眼帘。逛了一圈后，发现每种数据都有很多种方案，例如：
1. Metric：Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus
2. Tracing：Jaeger、Z</span></span>ipkin、SkyWalking、OpenTracing、OpenCensus
3. Logging：ELK、Splunk、SumoLogic、Loki、Loggly看完这些方案后你会觉得无所适从，不知道该从何处下手。然而现实也确实是这种混乱的状态，各个方案/公司都定义了一个自己的协议格式/数据类型，不同的方案之间很难兼容/互通。如果用到的所有组件都使用同一种方案还好（例如公司所有组件都用OpenTracing，依赖的所有开源/商业组件也都基于OpenTracing），然而现实往往是各种方案混用，只能自己开发各类的Adapter去兼容，最后搞得焦头烂额。
这一问题在Tracing领域尤其凸显，Tracing的目的就是把系统中所有的模块和组件的交互通过Trace ID完全串联起来，如果某些组件Trace格式不统一，那这部分组件内部的调用记录就会断掉，Trace完全发挥不出价值。所以最开始的时候有了OpenTracing规范，OpenTracing定义了Trace的数据格式，各家公司可以基于这个标准去实现，基于不同实现的组件最终结合时可以完全兼容。
然而社区还有一个协议是Google发起的OpenCensus，OpenCensus除了Trace外还定义了Metric。OpenTracing和OpenCensus在云原生CNCF的大旗下最终合并成了OpenTelemetry，并成为了当今可观察性的一个准标准协议。
OpenTelemetry为我们带来了Metric、Tracing、Logging（正在制定中，LogModel已经定义完毕）的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。除此之外，OpenTelemetry还为我们带来了众多福利：
1. 统一SDK：OpenTelemetry为每个常见语言都实现了对应的SDK，未来我们的系统中只需要一个SDK就可以记录三种可观察性数据。</li>
2. 自动代码注入技术：OpenTelemetry也开始提供可以自动代码注入的实现，目前已经支持Java各类主流框架的自动注入。</li>
3. 厂商无关性：OpenTelemetry提供了Collector用于收集各个SDK发送的数据并支持对接到各种后端存储系统。</li>
4. 云原生：OpenTelemetry设计之初就已经考虑了云原生的特性，并且还提供了Kubernetes Operator用于快速部署使用。</li>
万能的OpenTelemetry？
从上图中我们可以看到，OpenTelemetry覆盖了各类Telemetry数据类型的规范定义、API定义、规范实现以及数据的获取与传输。未来我们的应用程序只需要一种SDK就可以实现所有类型数据的统一产生；在我们的集群中，只需要部署一个OpenTelemetry的Collector便可以实现所有类型数据的采集。而且Metrics、Tracing、Logging的具有相同的Meta信息，可以做无缝的关联。
一切看起来是如此的美好，但如果从可观察性的整体方案上讲，OpenTelemetry只做了数据统一生产的部分，后面如何存储、利用这些数据并没有明确的定义，而实际上这些问题也非常突出：
1. 各类数据的存储方式：Metrics可以存在Prometheus、InfluxDB或者各类商业软件；Tracing可以对接Jaeger、OpenCensus、Zipkin。如何选择以及运维这些后端是个很困难的问题。
2. 数据分析：解决存储的问题后，如何对于采集到的数据进行统一的分析？我们需要在不同的软件对于不同的数据单独去做，可能还需要额外的一个DB去存储分析的中间结果，然后再对中间结果继续处理...
3. 可视化与关联：可观察性系统是为了可观察的，所以可视化、交互是非常重要的部分，想要在一个平台显示Metrics、Logging、Tracing并能够实现3者的关联跳转，需要很多定制化的开发工作。
4. 异常检测与诊断：解决了基本的温饱问题后，我们还会追求生活质量的提升，因此我们还会去研究如何对系统进行更加有效的异常检测和根因诊断，这时就需要把<span>OpenTelemetry的数据融入到</span>AIOps相关的技术中。
SLS与OpenTelemetry结合
从上面的分析来看，OpenTelemetry的定位是作为可观察性的基础设施，解决数据规范与获取的问题，后续部分依赖各个Vendor来实现。当然最佳的方式是能够有一个统一的引擎去存储所有的Metrics、Logging、Tracing，有一个统一的平台去分析、展示、关联这些数据。
这些事情与SLS的发展方向不谋而合，SLS（阿里云日志服务）从2017年就已经支持支持云原生相关的可观察性工作，并以日志类解决方案进入CNCF Landscape。
现在SLS还支持CNCF可观察性领域（Observability and Analysis）中的其他方案，包括CNCF官方维护的Prometheus、Fluentd、Jaeger等。我们的目的是去兼容各种可观察性的数据源，为这些数据提供一个统一的存储、分析服务，以更快捷、更低成本、更高可靠性、更低门槛的方式来构建业务的可观察性平台。
OpenTelemetry作为Logging、Tracing、Metrics未来的统一标准，目前是CNCF中除Kubernetes外最活跃的项目，SLS也是在持续跟进社区进度。目前我们已经以Vendor的方式进入了官方的Collector，通过Collector可以直接将OpenTelemetry各类可观察性数据直接存储到SLS后端。SLS能够为可观察性提供：
1. 统一的存储：SLS原生支持Tracing、Logging的存储，每天已有数十PB的写入；目前我们发布了时序存储引擎，并开始大规模使用。因此可以只用SLS就能支持所有Telemetry数据的存储。
2. 统一的分析：SLS对于所有数据均提供SQL92的分析方法，可以用SQL这一种语法实现对Metrics、Logging、Tracing的统一分析，并且我们还是支持跨Store的联合查询，因此可以实现一个SQL同时关联Metrics、Logging、Tracing，让数据的打通更加便捷。
3. 更低的成本: 从人力成本上看，SLS完全服务化，无需运维实例；从使用角度看，SLS使用按量计费的模式，无需单独购买机器、磁盘用于数据计算和存储。</li>
4. 更快的速度：SLS存储计算分离架构充分发挥集群能力，尤其在大量数据下端对端的速度提升显著。
5. 更智能的算法：SLS提供了各种<a href="https://help.aliyun.com/document_detail/93024.html" target="_blank">AIOps算法</a>，例如多周期估算、预测、异常检测、时序分类等，可以基于这些算法快速构建适应于公司业务的智能报警、诊断平台。
6. 更全的生态：利用SLS上下游生态打通的能力，可以将Telemetry数据对接流计算来获得更加快速的报警能力、对接数仓进行离线的统计分析、对接OSS进行归档存储等。
Metrics
SLS的MetricStore采用了存储计算分离的架构，数据通过Shard的方式分散在多台机器分布式存储，计算层集成Prometheus的QueryEngine模块，通过内部高速网络并行读取各个Shard的数据，并支持算子下推，轻松应对超大规模数据压力。
值得一提的是OpenTelemetry的Metrics官方建议的后端存储是Prometheus，而SLS的MetricStore完全兼容Prometheus的数据格式以及查询语法，并解决了标准Prometheus的单点问题（感兴趣的同学可以参考：高性能、高可用、免运维-云原生Prometheus方案与实践），可以说是OpenTelemetry最佳的Metrics存储方案。
Tracing
早在18年的时候，我们就已经支持了对接符合OpenTracing规范的Jaeger，目前Jaeger也是CNCF官方维护的Tracing实现，也是OpenTelemetry推荐的存储后端。SLS作为Jaeger的存储后端有众多优势，包括高可靠高性能、免运维、低成本等（感兴趣的同学可参考：开放分布式追踪（OpenTracing）入门与 Jaeger 实现）。
Logging
SLS在日志领域的能力这里就不多做介绍（感兴趣的同学可直接各类引擎搜索“日志服务SLS”）。SLS并没有完全定义日志的具体模型，可以理解为一个通用的日志类的存储引擎。目前OpenTelemetry的Logging正处于Incubating状态，但发展非常快速，目前已经制定好了LogModel，协议以及SDK的实现也即将到来，而SLS也将第一时间支持。
写给未来
虽然OpenTelemetry项目现在处于孵化阶段，各语言SDK以及Collector还没有处于Production Ready状态，但从社区的活跃度上（CNCF除Kubernetes外最活跃的项目）也能够看出各大公司对OpenTelemetry的看重，相信OpenTelemetry会在可观察性领域上大一统。未来我们将持续关注OpenTelemetry的发展，并实时和大家分享如何基于OpenTelemetry更好地实现系统的可观察性。
参考
<li data-lake-id="fac8ecc554cb050bf9983fddebddd0cf"><a href="https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html" target="_blank">Metrics, tracing, and logging</a></li>
<li data-lake-id="ccdad56daae82540a380d75742d5695b"><a href="https://grafana.com/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/" target="_blank">Loki: Prometheus-inspired, open source logging for cloud natives</a></li>
<li data-lake-id="43956f2a4b774c9918539c1f3fd8131f"><a href="https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/master/exporter/alibabacloudlogserviceexporter" target="_blank">https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/master/exporter/alibabacloudlogserviceexporter</a></li>
<li data-lake-id="1a75ac25da69d3153efdaf55ee9c7c8f"><a href="https://developer.aliyun.com/article/765358" target="_blank">https://developer.aliyun.com/article/765358</a></li>
<li data-lake-id="7c37e12dad67b1a10ed82a78b11e308e"><a href="https://github.com/open-telemetry/oteps/pull/97" target="_blank">https://github.com/open-telemetry/oteps/pull/97</a></li>
<li data-lake-id="e578f0ae43d1d121f22331f6bcc50af5"><a href="https://github.com/open-telemetry/opentelemetry-collector-contrib/pulls" target="_blank">https://github.com/open-telemetry/opentelemetry-collector-contrib/pulls</a></li>
