构建可观测性的核心能力是什么？

云原生时代，企业从单体架构发展到分布式架构，广泛采用微服务、容器、Serverless等部署方式，IT基础设施变得愈发不可控。

这导致传统的监控技术和工具很难跟踪这些分布式架构中的通信路径和相互依赖关系，更别提排查问题并定位根本原因了。

Gartner认为数字化转型以业务为中心，服务和用户体验是关键目标。而IT监控以系统可用为中心，仅关注系统可用性指标对于转型中的企业而言是一场灾难。到2023年，依赖于“正常运行时间”指标的监控实践将抑制90%的转型计划。

当监控无法再单独以运维的视角、被动地解决故障为目标，而要追随IT架构的改变和云原生技术的实践，融入开发与业务部门的视角，具备比原有监控更广泛、更主动的能力，“可观测性”概念诞生了。

“可观测性”究竟是什么？实现“可观测性”的核心能力有哪些？

2018年，可观测性（Observability）被引入IT领域，CNCF-Landscape率先出现了Observability的分组。自此以后，“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。

近两年，可观测性红遍IT运维领域，火起来的导火索是CNCF在云原生定义中提到 Observerbility，并声称这是云原生时代的必备能力。加之包括谷歌在内的众多大厂一拥而上，“可观测性”正式出道。

谷歌给出可观测性的核心价值很简单：快速排障（troubleshooting）。

随着系统越来越精细，越来越复杂，越来越动态，越来越庞大，潜藏的问题和风险也就越来越多。因此，任何一个软件的成功，不仅仅要依靠软件架构的合理设计、软件开发的代码质量，更要依靠软件系统的运行维护。而运行维护的基础，就是可观测性，通过提前发现异常，快速定位根本原因，迅速排除或者规避故障。

因此，可观测性是从系统内部出发，基于白盒化的思路去监测系统内部的运行情况。可观测性贯穿应用开发的整个声明周期，通过分析应用的指标、日志和链路等数据，构建完整的观测模型，从而实现故障诊断、根因分析和快速恢复。

虽然可观测性是由传统监控发展而来，但是他们有着本质的不同。

传统监控更多的是指运维自动化工具，主要用途是替代人自动监控系统运行情况，在系统发生异常时告警，最终还是需要人工去分析异常、故障诊断和根因分析。

但现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。

可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念，实现全景监控、智能运维和自修复能力等体系化的服务能力。

有业界专家一句话总结传统监控与可观测性的区别：“监控告诉我们系统的哪些部分是工作的；可观测性告诉我们那里为什么不工作了。” 

在CNCF对于云原生的定义中，已经明确将可观测性列为一项必备要素。

CNCF云原生生态也整合了可观测性体系，在CNCF生态全景图中可观测性主要是按照 Monitoring监控指标、Logging事件日志、Tracing链路追踪三个维度来分类。

 监控指标（Monitoring）

云原生监控指标可观测产品大都是从传统的监控产品发展而来的，传统监控中Zabbix以其高可用和图形化展示而广受欢迎。

而在云原生时代，CNCF孵化的监控工具Prometheus取代了以Zabbix为代表的众多传统监控工具，已基本成为云原生监控体系通用的解决方案，并可以通过配合Grafana工具实现监控数据图形化进行可视化分析。

 事件日志（Logging）

在业界中，事件日志可观测产品也已经是一片红海。日志管理方案大都包含日志收集、日志聚合、日志存储与分析几个模块，具体过程是日志收集工具与应用程序容器一起运行，并直接从应用程序收集消息，然后将消息转发到中央日志存储以进行汇总和分析。

在这方面Elastic Stack日志解决方案独占鳌头，几乎覆盖了日志管理的全流程，其中一大变数是用于日志聚合、过滤等业务的Logstash效能较差，在未来可能会被CNCF孵化的Fluentd取代。

 链路追踪（Tracing）

比起监控日志与事件日志，链路追踪可观测的产品竞争要相对激烈得多。其根本原因在于链路数据与实际业务和业务实现协议、编程语言等细粒度具体场景密切相关。

这也导致针对不同产品实现和网络协议的链路追踪产品层出不穷，但是他们在功能实现上并没有太本质的差距，却又受制于实现细节，彼此互斥，很难搭配工作。

传统的工具是垂直向的，在引入一个新的组件的同时也会引入一个与之对应的观测工具。尽管保证了数据的全面性，但丢失了数据的关联性和分析排查的连贯性。

如果有一个统一的数据平台，把所有数据放在一个平台，似乎就能解决关联性的问题。

但实际情况往往是，建立了一个观测指标、日志、链路的统一平台，数据堆在了一个地方，用的时候还是按传统的方式各看各的，关联性还得靠人的知识和经验。

因此，可观测性能力的构建，最关键的其实是解决数据统一和关联的问题：把之前需要人去比对、过滤的事交给程序去处理，人的时间更多的用在判断和决策上。

中国信通院《可观测性技术发展白皮书》指出，可观测平台能力的构建，需要具备统一数据模型、统一数据处理、统一数据分析、数据编排、数据展示的能力。

那么，如何做数据统一和关联呢？

在统一数据平台上，由于数据是来自于各种观测工具的，虽然在数据格式上统一了，但不同工具的元数据截然不同。如果在统一数据平台上去梳理和映射这些元数据，将是庞杂、难维护、不可持续的。

那么该如何做呢？答案就是标准化。

只有将标准化、结构化的数据喂给观测平台，观测平台才能从中发现巨大价值。统一数据平台只是在数据格式上进行了标准化，而要想将数据关联还必须建立context的标准化，context就是数据的空间信息，再叠加上时间信息的关联就可以发挥真正的观测价值。

目前，CNCF为了统一这一乱象，推出了Open Telemetry以期实现理想状态下的大一统：统一Logs、Trace、Metrics三种数据协议标准，使用一个Agent完成所有可观测性数据的采集和传输，适配众多云厂商，兼容CNCF上众多的开源与商业项目。

可以说Open Telemetry是一套与平台无关、与厂商无关、与语言无关的追踪协议规范，意在让链路追踪可观测更加规范化。

但遗憾是，至今未有厂商或开源项目可以统一Open Telemetry后端，三种数据源的统一存储、展示与关联分析仍面临极大挑战，而解决以上问题的前提，仍然是统一数据源（数据格式）。

总的来说，云原生可观测性方兴未艾，因为云原生的应用系统趋于规模化和复杂化，越是复杂的庞大机器越是会强调其可靠性和稳定性。

未来，云原生可观测未来需要一个大一统的可落地产品，通过统一的标准汇聚三者的数据，挖掘交叉区域的价值。

本文来自微信公众号 “科技云报道”（ID：ITCloud-BD），36氪经授权发布。