聊聊指标异常检测与等待事件分析的相互补充作用

指标异常检测是基于对指标历史的分析的，传统的指标异常检测是基于基线的。通过专家的经验或者根据某个系统平时的运行状况，设定一个极限范围，然后对指标的高值、低值，均值等进行分析，发现其是否有违背基线的现象发生，如果存在则产生基线告警。这种简单的基线告警算法目前还是大多数运维自动化系统中的主要方法。

在运维实践工作中，这种基线告警方法的效果并不好，主要有两个原因，第一个是基线的设置都是个性化的，需要有经验的专家针对系统的个性化特点去设置才更有效，否则基线告警的准确性就不够。而且随着系统不断地变化，基线也需要动态进行调整，否则基线告警的准确性会进一步降低。

而这种动态调整，如果是手工进行的，那么工作量就太大了。另外一个就是系统中的各种指标也是存在一些畸变的，还有些指标是单边增长，并无上下限的，针对这样的指标的处理也需要有一定的个性化方法。

正是基于这个原因，指标异常分析如果基于基线，就会存在实践效果不佳的问题。如果我们对企业中的上百套系统使用几种预置的基线模板，那么分析效果就十分有限。采用动态自动基线的方法是目前较为先进的方法。

其基本方法是根据某个指标在过去的某段时间里的变化特点，经过一段时间的数据积累之后，自动抽象出其变化特点，形成一个立体化的带有时间延续性的基线特征。然后根据这个特征来判断指标是否异常。

这种基于复合算法的指标异常分析方法避免了通过简单的上下阈值设置的指标基线那种呆板与教条化的问题，在实际应用中更为有效。不过这种算法更为消耗算例，为了控制计算量，会设定一个参数，通过调整精度来降低算例需求。这和人脸识别的准确性与误识别率类似，参数设置的严格了，算力要求高，误判少，但是也可能会漏掉一些异常，设置的宽松一点，算力要求低，误判就多了，遗漏的异常就会少一些。

因此这种异常检测最大的问题就是准确率和告警数量之间的平衡。不管怎么样，这种算法总是会遗漏一些问题的。另外一种情况是，如果某个指标是新加入的，或者以前并无历史数据，那么算法是无法发挥作用的。这种时候，需要一些其他的方法来进行辅助。

去年年底遇到的一个案例给了我一些启示，在具有等待事件的某些数据库系统(比如Oracle、PostgreSQL、达梦、Oceanbase、PolarDB等)中，利用等待事件分析结合指标异常检测，会取得更好的效果。

去年年底时候，一个客户的系统突然比较慢，通过D-SMART发现这段时间有一个告警的出现比较频繁。

12点多之后一直出现这个报警。而这个报价一般情况下最常见的就是三种情况，一种是存在rman备份作业，一种是存在大量的DIRECT PATH操作，包括SQL LOADER，expdp，第三种是有些SQL写的不好，产生了大量的direct path read 。这三种情况最终都引起了存储的IO性能问题，从而影响了数据库的总体性能。

和用户沟通后，用户认为当天不是周末，中午时间顶多有几分钟就能完成的归档日志备份，不可能有能够持续几十分钟的备份作业存在。他们马上登录到系统中，查看了当前正在执行的备份作业，也没有发现当前系统中存在rman备份的进程。

不过他们通过智能诊断工具分析了一下，发现了当时确实存在较大的RMAN流量。于是查了系统中的rman备份历史数据的相关视图，发现了一个刚刚被终止不久的未完成备份。与管理系统备份的人员沟通后确认因为这是一套新升级，更换了存储和服务器，升级了数据库的版本。因此备份任务刚刚配置，并且备份启动时间被配置错了，第一次备份时间应该是本周日开始，没想到今天中午就触发了。他们发现后也立即终止了备份任务。

这件事当时就很简单的结束了，不过从上面的诊断分析中，我们发现有很多指标因为缺乏足够的历史数据，从而导致我们的异常检测无法进行。

因此当时的智能诊断的分析结果中，IO延时的问题被排在第一位，而智能诊断工具根据一些其他的蛛丝马迹，也发现了其中可能存在备份任务的问题。不过如果看这个结果，IO延时可能是主因，而实际上备份作业引发了IO问题，是问题的主因。

去年这个案例发生的时候，我们的基于等待事件的智能诊断工具还没有开发完成，不过用户的历史数据已经送到我们实验室了。今天早上我在想写点什么的时候，翻出了这个案例。于是我利用等待事件智能分析工具重新分析了一下。虽然使用了历史抽样数据来进行分析，不过等待事件分析还是很好的还原了当时系统的现场，更为准确的发现了当时系统存在的问题。这个诊断结论比上面的那个要准确多了。

如果是人工分析，有经验的专家可以根据自己的经验举一反三，很容易切中要点。不过智能分析主要依赖于存在缺陷的数据和算法，因此很难做到人类专家那样的综合分析。在以往的运维事件中，我们也发现了，通过不同维度的多种渠道去做分析，然后汇总其结果，这种三明治算法往往能够获得较好的效果。

在利用指标异常检测做智能化诊断分析的时候，配合以同一时间段的等待事件分析，综合其结果，那么可能会获得更好的分析性能。我们随后会开展这方面的研究与验证工作。后续我再给大家分享实践结果吧！