IT系统为什么需要可观测性（解读版）

May the force be with you.

“the force”，即原力，来描述可观测性的作用。

可观测性无论对工程师、架构师还是技术主管都是一种赋能。

对工程师而言，可观测性能够让大家抓住技术趋势，深入理解云原生技术和分布式系统。让开发工程师理解基础设施，让系统和网络工程师理解应用。云原生时代，全栈能力是一个工程师自我修养的重要部分，当然也是大家未来职业道路中升职加薪的保证。

对于架构师而言，通常面临的挑战是如何让IT系统能够支撑业务量以十倍速增长。这样的增速，不采用云原生等新技术是无法实现的。然而，技术创新的背后是巨大的风险。可观测性为新技术的采用奠定了坚实基础。一方面通过监控自服务，大大加快新业务的开发测试速度，另一方面通过全栈链路追踪，保障业务上生产之后的稳定运行。

对于CTO等技术领袖而言，组织能力的提高极为重要。公司数字化业务虽在快速增长，但IT团队组织架构，人力资源等却难有大的变化。因此，需要借助可观测性建立“数据即事实”的团队协作原则，以此消除部门之间的协作壁垒，有效提升组织的协同作战能力。

说到这里，解释下可观测性为何可以比做“原力”。

可观测性的数据，本就存在，只是散布在各个部门。而可观测性平台的建立，就是数据的汇聚，可以认为是从各个部门收集到了原力。可观测性服务，则是通过汇聚的数据去反哺各个部门，即形成能够控制的“原力”，成为Y、Yoda老师那样的绝地武士。

可观测性有很多种不同的定义，最广为流传的是三大支柱说。三大支柱即metrics、tracing、logging。

三大支柱说广为流传的原因，在于他最容易被工程师理解并接受。

然而，三大支柱的提出者，Peter Bourgon的原意恐怕不是所有人都真正理解。

Peter非常务实的指出，讨论可观测性，需要明确讨论对象，对不同的数据类型应该有不同的优化处理方法。注意，Peter原意并不是说可观测性就是三大支柱，而是让大家具体问题具体分析。即便是Metrics，在不同场景下也有不同的含义和处理方法。

Google Dapper（谷歌的分布式追踪系统）作者Ben Sigelman更是直言，metrics、tracing、logging只是三种数据类型。言外之意，还是具体问题要具体分析。Google Dapper的论文，大家多少应该去了解一下。看看google是如何通过零侵扰、轻量级的追踪技术，帮助团队调试和诊断分布式应用的。

因此，三大支柱的合理解读，应当是可观测性需要多类数据类型，每类数据也要在不同场景下选择不同的处理方法。希望大家能够记住这点。如果将来看到把可观测性等同于三类数据结构的兄弟，最好建议他去读读Peter的Blog原文。

Charity Majors是我非常尊重的一位创始人，她是连续创业者，也在Facebook工作过，近几年创立了Honeycomb公司，专注可观测性。

她提出了一个非常独到的看法，即可观测性是用来解释“unknown-unknown“问题的，这个说法听起来似乎有点儿玄而又玄的感觉。

我跟大家解读下：unknown-unknown可以简单理解为探索未知问题。

软件工程中，有一套完整的debug工具，帮助开发人员发现软件中的未知问题。

分布式系统监控中，可观测性扮演了类似debug工具的角色，通过交互式的追踪，定位未知问题。

这里请大家注意，探索未知的说法，其实是Charity借用了软件工程的理论来做可观测性。这样的思路，跟Google SRE的思路完全一致。

在Google SRE Book的第十二章中，明确说到了，可观测性的目的就是：快速排障。

由此可见，软件工程是可观测性绕不过去的门槛。要想唤醒大家对软件工程的记忆，不妨重读下《人月神话》，必然会有新的体会。

Peter、Ben、Charity再牛，也只能算是三体文明，而这位是真正的神级文明，因为他发明定律。

鲁道夫卡尔曼，现代控制理论之父，他提出了系统的可观测性理论，并且基于这个理论，把人类送上了月球。

那么，在神级文明的定义下，可观测性是什么呢？以下定义均来自维基百科。

首先：控制理论中的可观测性是指：系统可以由其外部输出推断其内部状态的程度。

其次：一系统具有可观测性当且仅当：针对所有的状态向量及控制向量，都可以在有限时间内，只根据输出信号来识别目前的状态。

这样定义非常抽象，但我可以帮大家划重点：

首先是外部输出，其次是内部状态，最后是有限时间。

比如新冠核酸检测：外部输出是被棉签捅着的东西...，内部状态是肺部是否被冠状病毒感染，有限时间是3~8个小时。

如果不是外部输出，那就意味着需要抽血或者开刀；如果不是内部状态，那就无法进行分诊治疗；如果不是有限时间，那要么疫情泛滥，要么没法出行。

理解了这三个重点在防疫中的含义，下面就可以讲讲他们在IT系统中的解读。

现代控制理论，用状态空间来描述系统，通过可观测性和可控性解决复杂系统的控制问题。

借用控制理论中可观测性理论，引出我对IT系统可观测性的认知。

首先，状态空间代表白盒监控，即对系统内部状态要有清晰的理解，否则难以实现复杂应用的诊断。

其次，外部输出意味着对系统应是零侵扰的，尤其是对业务是零侵扰的，否则干扰系统运行，无法实现控制目的。

再次，内部状态一定是多维度的，对IT系统而言，就是我们常说的全栈，包括应用、系统、网络及各类中间件。

最后，有限时间意味着实时性，从开发测试角度而言，调试速度应该是分钟级的，从生产保障而言，故障响应速度至少也是分钟级的。因此，要支持分钟级的工作流，可观测性平台的响应速度必须是秒级的。

基于上述分析，我也提出自己对可观测性的理解：

简单而言，可观测性就是为复杂IT系统寻求白盒监控能力。

IT系统的可观测性应具备零侵扰、多维度、实时性等关键特性。

去年12月跟某保险公司的IT架构部门交流，谈到传统APM要给应用插码，腾讯会议对面的一个小姑娘突然跳出来说：“你们咋打桩？”。

当时我就非常吃惊，原来插码这种工作，已经上升到了“打桩”的难度，如上图。但“打桩”，为何要小姑娘来做？

另一个真实的case，去年10月给某股份制银行做POC汇报，观测到对方普罗米修斯服务响应时间超过30s，客户说，“这个正常”。

让985毕业的小姑娘去打桩？让每一次检索数据消耗写一行新代码的时间？

这不是新一代IT人该有的样子，残酷的现状需要改变。

可观测性，必须要解决以下问题：

1）在数百个服务中发现瓶颈：提供非采样，秒级精度，提供HTTP/DNS/GRPC等性能指标数据

2）在数千个访问中追踪应用：提供应用层Trace追踪数据，网络层Flow追踪数据

3）在数万个容器中定位根因：提供全栈（API、主机、基础设施）端到端指标数据、日志数据

关于零侵扰判据：

传统APM/NPM等工具，要么需要应用程序中打桩插码，要么需要基础设施中分光镜像，均会对IT系统进行侵扰。可观测性要求使用外部数据做分析，因此需要采用零侵扰的方式获取监控数据。不需要打桩插码、分光镜像，而是通过开放系统架构直接获取监控数据。零侵扰的另一方面是要求低功耗，不能因为采集数据而影响应用或基础设施性能，例如，通常采集点功耗不能超过业务功耗的1%。

关于多维度判据：

要保障云原生应用稳定运行，可观测性必须包含多维度数据分析能力。具体来说，要将应用的API、容器、主机、网络等监控数据进行全栈关联分析。传统的APM工具，可以定位代码层问题，却无法追踪容器或主机网络服务引起的故障。而传统的NPM工具，又不能关联应用的TraceID从而追踪穿越NAT、LB等网元的流量。因此，多维度的全栈数据分析，是可观测性的第二个需求。

关于实时性判据：

自动控制中，过大的传感器反馈时延，会导致系统震荡而不可控。与之类似，云原生应用的动态性要求可观测性平台必须具备实时性。如果应用的升级/扩容在分钟级完成，那么监控系统就必须提供秒级的反馈能力。注意，这里的反馈需要对海量指标/追踪/日志数据进行查找分析，因此对可观测性平台的海量数据实时处理能力提出了极高要求。

再回到原力的类比，如果没有零侵扰，可观测性平台，也就是原力收集平台，无法被大家接受。如果没有多维度，原力无法关联，自然失去了其意义。如果没有实时性，原力无法有效释放，被大家掌控。人的感知时间是秒级别的，因此实时性必须做到秒级。

有了上述判据，就可以定量评估可观测性技术了。

纸上得来终觉浅。可观测性实战要真正落地，大家又面临哪些问题呢？

既然可观测性是一种原力，而原力的掌控能力是一种增长的过程，那么我这里就借亚马逊的飞轮模型，来说明如何增长可观测性。

增长的第一步是理解和体验，体验可观测性的最佳方式当属各类SaaS服务，这些可观测性的SaaS服务可以让大家快速理解可观测性的价值。

增长的第二步是加速业务创新，也就是要满足业务部门的快速发展需求。开源是技术团队应对快速创新的最佳路径。因此，如何用开源技术构建可观测性平台是增长飞轮的第二步。

增长的第三步是满足生产需求，创新一旦完成，就要面临合规性、稳定性、安全性等一系列挑战，集成能力之于可观测性，就是赋能本身，让业务团队、基础设施团队、安全团队都能有效运转起来。

构建可观测性的第一种方法，也是最快捷高效的方法，就是使用SaaS服务。

目前，云厂商独立第三方企业均提供可观测性的SaaS服务。

国内的第三方提供商，目前云杉网络也提供名为DeepFlow Cloud的SaaS产品，方便大家体验。

SaaS服务的主要问题，是用户的应用大概率需要跑在公有云上，并且观测数据要由第三方管理。

此外，SaaS的计费模式相当复杂，有按主机规模计算的部分，也有按数据量计算的部分，总之很难准确规划这方面的预算。

因此，对于中小企业SaaS是首选，但对于中大型客户，尤其是采用混合云架构，合规性要求高，项目预算制的大型行业客户来说，很难仅仅依赖SaaS提供可观测性服务。

因此，才有了飞轮中的另外两种构建模式，开源和集成。

这个时代，整个IT系统都是构建在开源之上的，可观测性也不例外。

依托开源技术构建可观测性平台，是快速技术创新的必由之路。

如图所示，自底向上构建基于开源的可观测性平台，可供选择的开源组件非常丰富。

采集层，要实现零侵扰采集，可以采用K8S的daemonset采集器，java agent，普罗米修斯的部分exporter等等

采集层要注意的是，云原生体系下，监控数据要遵循开放标准，这样整套系统框架才能不断演进，扩展。采集层的开放标准主要是statsd和opentelemetry，尤其是opentelemetry，大有一统江湖的趋势。

采集层之上是数据层，之所以是数据而不是存储层，是因为要满足实时性要求，读存写必须分离。

本质上数据层就是一个实时数仓，要针对应用场景，进行深度的读存写优化。实时数仓方面对技术要求较高，可以跟有经验的团队或厂商一起开发。

数据层之上，是展示层。指标、追踪、日志、告警，分别由grafana、skywalking、kibana、prometheus等常用组件支持。

让这些开源项目支持更多种类的数据展示，同时为不同部门提供不同场景的APP、WEB、CLI、API，是可观测性平台团队的主要工作。

第三种构建可观测性的方式就是集成，integration。

集成听起来没有SaaS和开源性感，但我认为，集成的难度最大，因为集成的约束条件太多。

这些约束条件包括，理解业务需求，提出合理预算，满足行业合规，推动部门合作等等。

每一个地方出现问题，都会造成集成项目无法落地，或者无法创造价值，最终导致项目失败或难以持续发展。

集成的问题非常复杂，我这里提出两种解决思路。

第一个思路是”数据即事实“，部门之间的协作应该建立在数据事实的基础之上，而不是个人主观的描述，避免责任推诿，促进团队协作。

第二个思路是”业务为中心“，无论开发、测试、系统、网络、安全等团队，均需要深入理解业务，从对代码、系统、设备的负责，变为对业务上线速度、交易量、健康度的负责。

下面我通过一些实战用例来说明可观测性的价值。

第一个用例来自某智能车企，其业务变化非常快，公司采用公有云+容器化部署核心业务，并通过整合各类开源监控软件，构建“统一业务监控平台”。

公司业务迭代速度非常快，但微服务观测不全一直是困扰着业务快速上线的一大问题。业务上线后遇到故障只能靠猜、靠逐段抓包诊断故障原因，费时费力。

近期在生产环境中，nginx-control上线过程中出现了某API（xxx-api）调用某服务（xxx-service.prod.k8s.xxx.com）超时的情况。

虽然现有系统能定位到工作负载和服务域名（即源和目的），但其间经过多个微服务和网络服务，到底是谁引发了访问中断却不得而知。

由于客户端、服务端均没有（或无法）部署Skywalking监控、没有采集日志，开发人员不知道超时原因。这个问题经过一整天排查未有结论，严重影响业务上线进度。

借助可观测性的全栈能力，SRE团队在15分钟内定位到了根因，即问题出自一个特定的Ingress Control的容器POD。反馈到开发人员后通过修复Nginx快速恢复了故障。

第二个用例来自某股份制银行，该行私有云平台上运行着10万多个微服务，数十万个POD支撑业务，每分钟业务产生的访问数亿次。

该行业务运维人员经常遇到关键资源访问量徒增问题，尤其是云上云下互访时，“谁动了我的数据库！”是常见抱怨。要追查出到底是谁动了关键资源，难点重重。

难点之一是可疑分子太多，可疑分子隐藏在8万多个POD，8千多个Node、1千多VM、1千多Host之中。

难点之二是每个可疑分子到关键资源之间，至少经过两次地址转换，且POD、Node、VM、Host、PIP、GW的访问路径非常复杂。

难点之三是业务POD上不允许抓包，网关GW上也难以抓包（网关抓包丢包率高达40%)。

上述问题通过可观测性就得到了良好解决。

首先，可观测性平台提供POD、Node、VM、Host、GW资源上全量网络流量采集，解决了流量采集难的问题；

其次，可观测性平台同步了云平台NAT、LB等转换规则，通过服务端源IP地址、目的IP地址，分钟级在海量数据中，找到对应的POD、Node、VM、Host；

最后，可观测性平台为业务部门梳理出来常见的全栈链路观测模板，助力业务部门分钟级定位业务性能峰值问题。

如图所示，根据业务场景，访问路径非常复杂，需要层层梳理。否则不可能解决”谁动了我的数据库！“问题。

详细用例我就不再举例，这里再简单介绍10个用例进一步说明价值。

第一个用例，是某银行在开发测试中遇到业务周期性抖动，持续一周无法上线。最终通过可观测性发现了底层路由器环路导致。

第二个用例，某地产商的电子流应用，上云后每周都出现问题。最终通过可观测性发现了服务商DNS不稳定、开发团队违规升级代码、依赖第三方服务异常等一系列问题。

第三个用例，某大型金融企业，电商业务运行的容器平台，每扩展一个POD竞耗时超过1小时，而且要反复不停重试。后根据可观测性分析，逐步定位到某物理网卡对ARP请求产生了内部回路，更换机器后恢复正常。

第四个用例，某运营商省公司在集团对应用的可用性考核中，年年全省垫底。最终通过可观测性，发现了LVS、nginx和某物理交换机之间的链路有丢包，彻底排除了困扰已久的问题。

第五个用例，某大型私有云客户，发现其关键业务中的SQL集群频繁主备切换，虽然业务没有中断，但风险极高。后经可观测性平台分析，发现是SQL切换仲裁在并发并不高的情况下就停止了服务，最终导致了不必要的切换。

第六个用例，某银行个人贷款业务突然访问变慢，在大家都怀疑是网关丢包的情况下，通过可观测性平台，定位到了DNS服务异常。而且，进一步发现不仅仅是该业务的可用区DNS异常，其他区域也有普遍现象，根本原因是DNS配置错误。

第七个用例，某BI业务，运行过程中出现性能抖动。业务侧看到的只是客户端到BI的访问路径，而可观测性平台看到的是业务端-NGINX-BI-RPC-MongoDB的整体依赖。后定位为RPC服务中有一个容器出现问题，排除此容器后业务恢复正常。

第八个用例，某省消防队，经常被省里通报，尤其是护网期间通报，必须排除通报的安全问题。由于全省消防内网复杂，而通报又只针对不到10个对外服务的IP，如何追查内部攻击源变得非常困难。通过可观测性平台，该省消防队实现了10分钟内应答通报的能力。

第九个用例，某大型容器云平台，按传统pcap分析方式运维，一次简单故障平均查找数千个数据包，耗费专家数小时的宝贵时间。通过可观测性平台，业务排障由抓包分析变为微服务RED指标监控和全栈链路追踪，排障效率从小时级变为分钟级。

第十个用例，某农商行，视频业务上云后访问量增长近10倍，经常出现业务访问慢问题，几次扩容都不能解决问题。后根据可观测性平台分析，发现是某个隐藏服务异常发送RST包导致，优化服务的队列和超时设置之后，业务恢复正常。

为什么需要可观测性，就是给大家”赋能“。

让工程师、架构师、以及技术管理人员能够提升自我的认知能力、创新能力和组织能力。

如何理解可观测性，介绍了三种不同的视角。

三大支柱说，也就是three pillars，来自Peter Bourgon，背后是数据结构理论。

探索未知说，也就是unknown-unknown，来自Charity Majors，背后是软件工程理论。

白盒监控说，也就是white-box monitoring，是我根据控制理论中可观测性的定义推导出来的。

如何评估可观测性，主要三个方面，零侵扰、多维度、实时性。之前的介绍中也给出了详细的判据和背后的技术趋势。

至于如何构建可观测性，介绍了三种方法，SaaS用于体验、开源用于创新、集成用于合规。

谢谢大家，欢迎指正。