使用算法检测异常 - 问题描述

背景

任何一个产生环境的IT系统如果要长久下去，必须对其进行监控告警。常见的实现分为三个部分

1. 采集目标系统的指标，并上报到中央服务器
2. 对指标按时间窗口进行统计，并存储成为曲线
3. 对曲线进行异常检测，在必要的时候告警通知运维人员

在过去，对于第1、2两点我们已经积累非常多的文章和工具来谈论如何来实施一个“监控系统”。但是对于如何有效检测异常却非常缺少行业经验的积累。如果要对有效进行量化的话主要是两个指标：

1. 误警率：在所有产生的告警中，有多少代表了真正的故障
2. 敏感度：在所有真正的故障中，有多少产生了告警

一般来说，误警率可以放宽一些。虽然可能会产生狼来了的结果，但是稍微多一两条告警并不会产生什么实质的危害。需要卡控得比较严格的是漏警的情况。一旦监控系统漏警了，往往意味着一起责任事故和不小的损失。

曲线分类

首先，我不是一个理论工作者，对于自回归，方差等术语没有特别偏好，也没有通篇使用数学符号表达含义的表达能力。从经验观测的角度，我所知的曲线大概分为下面三类（该分类绝对不是完整分类）：

1. 成功率曲线（success rate）：最常见的成功率曲线比如网络测量里的丢包率，还有HTTP接口里200到400之间返回码的占比。
2. 延时曲线（latency）：最常见的延时曲线比如网络测量里的网络延迟（比如ping值），还有HTTP调用从请求发出到请求收到之间的耗时。
3. 调用量曲线（arrival rate，queue length）：最常见的调用量曲线比如网络测量里的收发包量，收发字节数，还有HTTP请求量。

而所需要做的监控也一般分为两类：

1. 可用性监控（availability）：只需要回答挂了还是没挂两个问题，挂了就打电话，发短信，发微信通知运维人员，否则shut up。
2. 性能监控（latency ~ user experience）：一般不需要触发立即的运维介入，而是用于事后回答过去一段时间的用户体验是变好了还是变坏了。不需要运维介入是小的性能下降，一般运维没有办法，必须要开发发新版本来解决。而大的性能下降很快就会演变成可用性监控的范畴，所以无需在性能监控里做回答。

性能监控主要关注并发处理的请求数，以及与延时的关系。而可用性监控如果可能的话，首选成功率。如果我们可以知道最近一段时间内500的HTTP返回显著上升了，基本上可以断定系统出了可用性的问题了。如果对URL做一个分类，然后某一个分类里500显著上升那么这个推断就更加精确了。这种异常检测几乎也无需太复杂的算法了，甚至一个绝对的阈值就可以了。

特别注意的是成功率的曲线不一定非要在一个调用的地方有一个错误码之类的东西，它可以是来自同一个流程上两个环节的数据。比如一个成功的业务过