3分钟了解黄金指标异常检测

王博    百度高级架构师

从事有关AIOps智能运维领域的工作，通过算法解决IT运维领域的痛点问题。重点关注异常检测、故障诊断方向的相关工作。

故障管理是运维工程师消耗时间最多的环节，因此成为了AIOps算法首要解决的场景之一。

在故障预防阶段，我们在文章《被变更逼疯的我，是如何成功自救的？》中提到过百度分级发布智能检查算法。算法将在每一级变更的实例与未变更实例，以及历史变更情况进行对比，如果发现指标变化有明显异常，即判定本次变更可能存在风险，变更将被拦截并提交人工进行进一步审查。

在故障发现阶段我们利用业务监控系统对重要的业务指标进行异常检测。当指标存在突变或者与历史行为不一致时，系统就会触发报警给运维工程师。我们在文章《我们不一样！告诉你百度是如何做智能流量异常检测的》中详细介绍了在流量指标上的故障发现方法。

在故障止损环节，我们在《单机房故障自愈》系列文章中详细讲述了百度单机房故障自愈的场景和算法。通过抽象、规范处理流程，我们将止损过程划分为统一的感知、决策、执行三个阶段。感知阶段监控分机房的KPI指标，在发现异常后触发止损流程。决策阶段根据各个机房的负载情况，在保证负载水位动态均衡的基础上分步将故障机房的流量调度到其他健康机房。执行阶段则根据决策阶段产出的调度计划利用流量调度平台API执行流量调度。

在故障诊断环节，《创造程序的“白衣天使”》系列文章提出了指标排查技术。该技术在故障时刻对故障产品线或者子系统下所有机器指标进行异常检测，给每一台机器打上一个异常标签，然后根据异常标签的情况对机器进行聚类分组，最后对分组进行排序，推荐异常程度最高的3到5个机器分组作为故障根源所在的位置。

讲到这里，我们可以发现故障管理的各个环节都依赖于对时序指标数据的分析，而异常检测算法是时序指标数据的关键分析技术之一，因此我们今天来聊一聊时序指标异常检测技术。

不同的监控场景采集的时序指标不一样，业务含义差异也很大，这些指标背后应该是一个异常检测算法吗？用户经常在听了异常检测的案例之后坚持认为自己的监控场景可能和其他人的不同，需要专门定制算法，真的是这样吗？下图是我们在业务领域、数据库领域、网络领域以及工业领域见过的一些指标。这些指标中的绝大多数都可以用几种标准的算法来检测异常。

对业务运维团队来说，主要关注的是业务指标的波动变化。像百度等互联网公司，可能更多关注产品的访问流量、订单数量、QPS、响应时间或者KPI成功率指标的波动。对于金融行业的客户，可能关注当前系统的交易量、交易成功率、交易响应率和交易延迟等指标的波动变化。如果这些业务指标出现了波动，系统可能发生了故障。例如，交易总量如果发生突然下跌，可能是当前系统的接入出现了一定问题。

对数据库管理员来说，主要关注的是SQL平均读行数、SQL语句的平均执行时间、锁等待时间和锁超时时间。这些指标反映数据库当前的健康状态，比如SQL语句的执行时间明显上升，可能是数据库的性能存在问题。

对网络运维团队来说，他们看到的关键指标又是另外一番样子。网络团队关注更多的是网络流量、网络延迟、TCP连接数、TCP发送和接受包数量、TCP连接失败数等。这些指标能够反映物理机器或者设备在网络层面的状态。例如，当网络流量突升超出网络容量极限的时候，网络延迟、TCP连接失败数等指标都会有显著的上升或下降。

除了我们常见的IT运维领域，工业生产的环节也关注了多种不同的指标，以确保生产安全和产品质量。比如轮胎企业，可能关心下线的轮胎尺寸，某个产品生产线的良品率、次品率、平均的生产下线时长，某个生产环节的温度等。比如，当某个关键环节的温度过低或者过高时，可能会导致生产出的轮胎硬度不符合质量要求。

表面上，前面提到的多个场景中定义的关键指标有很大不同，但其实这些指标背后是有相似之处的。谷歌出版的《Site Reliability Engineering: How Google Runs Production Systems》提出IT运维场景四类黄金指标，流量类、错误（成功）率类、响应时间类和容量类。我们发现很多指标都可以归入这四类，因此我们开发的算法工具包针对不同类型的黄金指标提供了专门的异常检测算法，提高了异常检测的效果和效率。

流量类指标代表流入系统的请求数量，请求数量的突升突降常常代表运维系统的外部接入部分可能存在故障。比如，访问流量就是外部进入百度业务系统的访问请求数，订单数是外部进入电商系统的订单数量，交易量是外部进入银行或者证券系统的交易数量，TCP发送包数是外部进入网络设备的包数量。这类指标可以应用泊松分布进行异常检测，感兴趣的读者可以阅读《我们不一样！告诉你百度是如何做智能流量异常检测的》这篇文章了解算法详情。

错误（成功）率类代表了流出系统成功或者失败的比例，错误率突升或者成功率突降代表系统自身的处理逻辑可能存在问题。例如百度的KPI就是请求的成功比例，交易成功率或者交易失败率是交易成功或者失败占总体交易量的比例，良品、次品率代表了生产线下线产品质量合格或者不合格的比例，这类指标的异常检测利用了二项式分布，具体方法在《还记得概率课本中的二项分布吗？在我们的网络判障中发挥了大作用！》这篇文章中有详细的介绍。

响应时间类代表流过系统处理请求的平均消耗时长，当消耗时间变大时代表系统的处理性能有所下降。比如响应时间就是请求从开始到返回在百度业务系统中所消耗的时间，交易延迟代表在银行或者证券交易系统中所耗费的平均交易时间，数据库中的SQL语句执行时间代表从开始执行SQL到SQL完成执行所需要的时间，网络延迟代表数据包从发出到被接收端接收到在网络系统中所消耗的延迟时间，生产时长代表从原料到产品下线的所需时长。

容量指标代表了系统当前能够处理的请求数量情况，容量指标突变代表系统可能存在容量退化的风险。例如CPU、网络使用率等指标，当这些指标飙高打满，系统可能有较大的容量风险。

这样，我们就把看似千差万别的指标归入了四个类别。在过去发布的文章里，我们介绍过流量类和错误（成功）率类的异常检测算法，分别利用经典的泊松分布、二项式分布概率模型进行建模，然后计算当前取值发生的概率，概率很小时就认为指标发生了异常。这种把指标的异常程度转换到概率维度进行衡量的方法，同样适用于响应时间类和容量指标类上，我们将在后续的文章中介绍这两类指标的异常检测算法。

故障管理是运维的重要场景之一，也是AIOps算法首先落地的场景。之前，我们发布的多篇文章分别在不同的侧面介绍了百度在故障管理环节的AIOps实践，这些实践都依赖了一个关键技术——时序指标异常检测技术。本篇文章重点对百度黄金指标异常检测技术进行了综述性的介绍，我们将各行各业的指标分类到了四大类黄金指标上，并针对每个类型提供了专门的方法进行异常检测。后续我们将继续发布我们在AIOps智能运维领域的新场景、新技术，大家敬请关注！

《前端加载优化实战》

《微服务之监控初探》

《站点监控 | 外科医生的实战》