前段时间热播的电视剧《开端》想必不少人都看过的,其新颖的拍摄手法和不落俗套的剧情着实颇具亮点。
(图片来自sohu.com)
为什么要说到这部剧呢?因为这部剧可以更好的帮我们理解什么是系统的可观测性,让你从一大堆技术概念中解脱出来。
我们都知道,为了保障一个软件系统的正常运行,通常我们都会为它增加监控手段,这里边主要有两类监控:黑盒监控与白盒监控。
什么是黑盒监控与白盒监控?
黑盒监控是指对服务器的监控,重点关注磁盘空间、CPU 使用率、内存使用率、平均负载等领域,这些是业内大多数人认为要监控的标准系统指标。
(图片来自pandorafms.com)
白盒监控是对在服务器上运行的应用程序的监控,可能是从Web 服务器收到的 HTTP 请求数量到应用程序生成的响应代码时间等的任何内容。
只有监控是不够的
在剧情里,主角们发现异常后多次进行警告和报警,但是问题始终没有完美解决。因为这个系统很复杂,甚至于牵扯到之前的一个系统问题(作案嫌疑人之女的交通事故)。仅仅是针对当前状态的监控与告警,是无法让这个系统快速的从故障中恢复,更别说进行一次有效的迭代提升质量了。
所幸,剧情中的循环就类似我们的代码一样,它可以重来让我们充分的debug。一次次的重置就像一次次的上线一样,那么问题来了,无论是剧情里还是现实中循环终究是有限制的,所以我们需要尽快找到解决问题的办法。
剧情里的可观测性
如果我们把公交车看成一个应用系统服务器,那个爆炸就是系统宕机的话,我们就会发现,这简直就是一部实现系统可观测性的好教材。
当男女主角身在公交车内时,对应的就是系统的白盒监控状态;当提前下车时,他们就和那些警察一样处于黑盒监控状态。
在两种状态相互交替下,他们会用心观查每个乘客的细节:每个人的位置、双肩包被紧紧抱住、行李箱非常扎眼、蛇皮袋被视若珍宝、高压锅用来装肉等等,这些是什么?聪明的你一定想到了,这些就是应用系统的部分指标数据(Metrics)。
(图片来自smzdm.com)
主角们记录的精确到几点几分的动作/行为,不仅忠实的还原了当时的情况,同时也为排查问题助了一臂之力,这不就是系统的日志数据(Logs)么。
随着剧情的推进,他们获取了更重要的数据,包括每个人物的关系,以及不同循环里事件的发展路径,这些也是对破案最为关键的信息,其实对应的就是系统的追踪数据(Traces)。
到此,构建可观测性的三大类数据支撑已经完备,我们也不难发现追踪数据(Traces)才是定位问题和解决问题的核心。
可观测性能定位根本问题
剧情最后,在主角们多轮艰苦卓绝的努力下,问题终于得到了圆满的解决。但是,我们该庆幸么?不,我们该反思。如果从一开始主角们就知道人物的关系和事件的先后顺序,破案还会这么困难么?答案自然是否定的。
回到我们的软件系统中,潜在复杂性的来源是永无止境的,监控可能变得异常复杂,以至于监控本身变得很脆弱、难以维护。因此,一套好的监控系统应该是简单并有效的,提供源自基于时间序列的设备、已知故障模式以及黑盒测试的关键业务和系统指标,而不是提供成百上千无太大意义的指标,意图“监控一切”的做法很多时候都是一种反面教材。
(图片来自dockone.io)
但可观测性则不同,它旨在提供对系统行为的高度精细的洞察以及丰富的上下文,非常适合指导调试并真正解决系统的问题。由于无法预测系统可能遇到的每一种故障模式,或预测系统可能出现异常的每一种可能方式,因此我们构建的可观测性是用证据而非推测进行调试系统,这很重要。