本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客
1、什么是可观测性
可观测性最早是1948年由电气工程领域的控制理论家Claude Shannon在《通信的数学理论》提出的。这也是信息论的奠基性文献。可观测性是指能够通过检查系统或应用的指标(Metrics)、日志(Logs)、痕迹(Traces)来监控、测量和理解系统或应用的状态。
同理,对应到软件系统,这单个指标基本适用,但不够直接到让我们基于它们直接设计落地方案。我的实践经验是,软件系统中,“输出”、“日志”、“性能”,是系统状态最重要的指标。它们分别对应了
- 输出(下游观测):当前系统生产给I/O设备的字节
- 日志(自身观测):应用程序运行中的,向磁盘写入的,记录进程运行过程的数据
- 性能(平台观测):操作系统角度观察的进程运行时的硬件资源占用情况
从上面可以看出,所有软件系统的观测,本质都是人观测I/O设备的数据。(在云时代,CPU的温度的硬件信息,不是软件工程师观测的重点)
在不同的系统中,观测的指标、重点都会有差别。但是观测的目的都一样,就是在系统不满足人需求的时候,可以快速发现主要原因。
2、软件系统的可观测链路搭建
所有的软件系统,观测动作最终都是人。而人不能无休地盯着系统,所以为了降低观测成本,需要系统在运行出现高风险时,能主动通知到人。
那么什么是风险,哪些是高风险,在高风险中,哪些优先级更高。不同的业务,会有不同的评判标准。我的经验是,在实际生产中,观测系统时。我的实践建议是,要问的三个关键问题:
- 下游使用有异常吗
- 软件的运行有异常吗
- 软件的资源使用有异常吗
而一个好的可观测系统,就是能够快速发现这三个问题,并主动通知给人。问题通知不是本章的重点,这块内容,我在《分布式系统可用性保证方法和实践》中有讲。下面讲一下,如何构建能快速回答该问题的系统。
2.1、下游使用异常吗
这是可观测软件系统中,最重要的问题。但奇怪的是,这个问题,却是实际生产中,最容易被人忽略的问题。我们在开发过程中,经常能听到以开发者以“我的系统没问题啊”,来回绝下游的报错,或许大部分情况下,系统没问题,但是如果是系统的问题,而开发者没有观测到,那会给下游带来巨大的困扰,毕竟复杂的系统,对于下游,几乎是一个黑盒。
我的经验是,把“我的系统没问题啊”,分为两种情况回答:
- 有多个下游:观察其他和该下游使用数据和方式一样的下游,看其他下游是否有问题
- 只有一个下游:拿出有问题Case,尝试复现
其中,拿出有问题的Case尝试复现,是十分普遍的方式。如果这个频率很高,我们也要考虑如果搭建链路,提高Case跟进的效率。
而缺乏对下游指标的观察,是大部分软件系统存在的问题。我的实践建议是:统一数据使用指标,如延迟,解析失败率等,然后下游需要遵循该指标提供监控,将类似的下游应用监控放到一个可视化网页/客户端中,可以观察各个下游业务的指标曲线。这时候问题就变得简单了,如果大部分下游的某个指标都有相同的问题,那大概率是我们的软件系统的问题。而只有一个下游指标有问题,那大概率是下游的问题,而不用每次出问题,就使用低效的“找个会议室联调下”的方法。
2.2、软件的运行有异常吗
是否能高效地关注到软件运行是否异常,主要取决于开发人员对业务的理解程度。以商品系统为例,用户的订单请求量,每个订单的请求延迟,每个订单的处理时长,每个订单的毛利润、净利润等,同样是商品系统,卖衣服可能更关注退单率,需要数据分析退单原因。卖零食可能更关心复购率,需要分析复购的用户画像。人的精力是有限的,设计好业务最相关的指标,对提升人效十分重要。不同业务系统的指标,没有好坏地对比。但是关注两个指标有助于大家快速提升观测系统。
- 异常的召回率 = 主动报出异常的个数 / 总的异常个数
- 异常的准确率 = 主动报出的需要人关注异常个数 / 系统主动报出的异常个数
召回率越高,系统能越早地发现问题。准确率越高,检测系统需要的成本越低。
2.3、软件的资源使用有异常吗
linux软件的资源使用情况,是由操作系统的输出的。 是否能高效地关注到软件资源使用是否异常,主要取决于开发人员对计算机系统的理解程度。看似需要对底层有很深的理解,但是由于这块需要十分通用且重要,所有方案十分成熟,所以大部分情况下,是借鉴别的软件,关注了哪些资源使用指标。而方案本身关注的,就是最容易导致软件出现问题的资源。
一个可以作为基础指标的方案是:
- CPU使用率、load1、load5、load15
- 内存使用率
- 网络入口流量、出口流量、网络重传率、网络链接个数
- 磁盘使用率、磁盘读写次数