IT 领域中，可观测性（observability）的争论源于 2017 年 Peter Bourgon（Go Kit 作者）的一篇文章《Metrics, tracing, and logging》。文中将可观测性问题映射到了如何处理指标（metrics）、追踪（tracing）、日志（logging）三类数据上。其后，Cindy Sridharan 在其著作《Distributed Systems Observability》中，进一步讲到指标、追踪、日志是可观测性的三大支柱（three pillars）。云监控领域的领导者，Datadog 也在其网站上用三大支柱来阐述可观测性。

三大支柱流传甚广，很大程度是因为，明确数据类型和优化处理方法，是广大开发者们最易理解的方式。但三大支柱只是讲到了如何实现可观测性，而非为何要采用可观测性。Ben Sigelman （Google Dapper 作者）对此即有争论，说这样的定义毫无意义，因为这只是三种数据类型。Charity Majors（Honeycomb CTO）也反对上述说法。她更进一步指出如果说传统监控工具是用来解决“known-unknown”问题（已知问题），那么可观测性是用来解决“unknown-unknown”问题（未知问题）的。

既然标题是为什么需要可观测性，那么实在无需讨论三大支柱相关内容。就新技术采用的决策者来说，为什么需要可观测性比如何实现可观测性更为重要。如果答案仅仅是 Charity Majors 所说的“unknown-unknown”，则实在有点玄之又玄的感觉了。因此，下文将从可观测性的实际案例分析其价值，尝试说明为什么需要引入可观测技术。

价值

从实用主义出发，理解可观测性解决什么问题，比理解可观测性如何实现更有价值。Google SRE book 第十二章给出了简洁明快的答案：快速排障。

There are many ways to simplify and speed troubleshooting. Perhaps the most fundamental are:

• Building observability—with both white-box metrics and structured logs—into each component from the ground up

• Designing systems with well-understood and observable interfaces between components.

Google SRE Book, Chapter 12

为何快速排障需要可观测性？这是由于 IT 系统不断增加的复杂度决定的。大量云原生技术的采用，导致 IT 系统越来越复杂，快速排障变得越来越难。传统的应用监控（APM）和网络监控（NPM）工具，可以发现某个函数调用失败或者某个链路性能下降，却难以在复杂的云环境下找到故障发生的根本原因。下面通过几个典型的实战案例说明可观测性的价值：

案例 1：“谁动了我的数据库！”

某大型银行，采用私有云基础设施部署微服务架构的应用。随着业务不断上云，经常遇到这样一个棘手问题：核心数据库访问量陡增，只知道来自某个云资源池，却由于其中的 80000 多个容器 POD 都做了不止一次的 IP 地址转换，而无法定位到底是哪些 POD 造成了核心数据库的流量陡增。

如果采用传统的监控方式，只能发现陡增这个现象，而难以快速定位到引发问题的容器 POD。通过可观测性，则可以建立 80000 多个容器 POD 到核心数据库每一次访问的性能指标和关联关系，进而在 1 分钟内定位上述问题，避免由核心数据库带来的业务风险。

案例 2：“审批系统每周都出问题！”

某地产公司，将面向全球数万员工的业务审批系统部署在公有云基础设施之上。该系统由 30 多个微服务构成，并依赖 10 多个外部系统，应用调用关系复杂，故障定位极其困难。

自从上了公有云，该业务审批系统每周都出现问题。即便尝试了拨测和 APM 等监控工具，依然没有达到每周 99.9%时间可用。通过引入可观测性，一系列问题立即被发现：外包开发团队私自升级代码、某公有云平台 DNS 服务中断、内部存储微服务丢包达 30%以上、3 个外部应用错误率超过 10%...。云上业务故障的多样性可见一斑。没有全面的可观测性，无法分钟级定位上述问题，自然就不可能达到 99.9%（每周最多中断 10 分钟）的可用性。

案例 3：“开发测试环境带来生产隐患！”

某大型金融机构，开发测试和生产系统均构建在两地三中心的私有云基础设施之上。开发测试环境中，新业务的性能出现了“一会儿好一会儿不好”的问题。无论使用云平台自带监控，还是进行人工抓包分析，数周来一直没有找到根因，即无法确定是应用还是基础设施的问题。

如果新业务真的“带病”上生产，一旦发生业务自身问题带来的生产事故，责任是极其重大的。通过引入可观测性，首先精确监测到特定虚拟机每 5 分钟出现 100ms 的时延波峰，其次根据特定虚拟机的全栈链路（即虚拟机-云主机-路由器等）实时监测，快速定位出故障在特定云主机到某路由器之间，进而发现路由器配置疏漏导致换路产生，造成周期性丢包。

从以上实战中可以看出来，云原生技术的广泛采用，大大增加了 IT 系统故障的复杂性，进而为快速排障带来了困难。通过引入可观测性，分布式应用和复杂的基础设施由黑盒变成白盒，有效提高了排障速度。

可观测性如何实现更多不同业务场景下的快速排障？每一个云原生应用如何具备可观测性能力？如何搭建一套适合自身的可观测性设施？我们能否让基础设施内生地提供这样的能力，让它就像原力（The Force）一样，无处不在