指标异常检测是基于对指标历史的分析，而传统的指标异常检测是基于基线的。通过专家的经验或根据某个系统通常的运行情况，设定一个限制范围，然后分析指标的高值、低值、平均值等，找出是否有违规现象基线，如果是，则生成基线警报。这种简单的基线告警算法仍然是大多数运维自动化系统中的主要方法。在实际运维工作中，这种基线告警方式效果并不好。主要有两个原因。首先是基线设置都是个性化的，需要有经验的专家根据系统的个体特点进行设置。更有效，否则基线报警的准确性不够。而且，随着系统的不断变化，基线也需要动态调整，否则基线告警的准确性会进一步降低。但是，如果手动进行这种动态调整，工作量就太大了。二是体系中的各项指标也存在一定的扭曲，部分指标单边上升，没有上下限。此类指标的处理也需要一定的个性化方法。正是由于这个原因，如果指标异常分析基于基线，就会存在实际效果不佳的问题。如果我们对企业中的数百个系统使用几个预先构建的基线模板，分析效果是非常有限的。使用动态自动基线的方法是目前比较先进的方法。其基本方法是在经过一段时间的数据积累后，根据过去某段时间某指标的变化特征，自动抽象出某指标的变化特征，形成具有时间连续性的三维基线特征.然后根据这个特征判断指标是否异常。这种基于复合算法的指标异常分析方法避免了通过简单的上下阈值设置指标基线的死板教条问题，在实际应用中更加有效。但是，该算法消耗的计算实例较多。为了控制计算量，会设置一个参数，通过调整精度来减少计算实例的要求。这类似于人脸识别的准确率和误识别率。如果参数设置严格，对算力要求高，误判少，但可能漏掉一些异常。设置越宽松，对算力要求越低，误判就会多，漏掉的异常就会少。因此，这种异常检测最大的问题是准确率和告警次数之间的平衡。不管怎样，这个算法总会遗漏一些问题。另一种情况是，如果新添加了一个指标，或者之前没有历史数据，算法就不行了。这时候就需要一些其他的方法来辅助了。去年底遇到的一个案例给了我一些启发。在一些存在等待事件的数据库系统中（如Oracle、PostgreSQL、大梦、Oceanbase、PolarDB等），使用等待事件分析结合索引异常检测会取得更好的效果。好结果。去年年底，一个客户的系统突然变慢了。通过D-SMART，发现这段时间警报频繁出现。12点以后，这个闹钟一直出现。一般来说，这个报价最常见的情况是三种情况，一种是有rmanbackupjob，一种是有大量的DIRECTPATH操作，包括SQLloader，expdp，三是一些SQL没写好，导致Lotsofdirectpathread。这三种情况最终会导致存储IO性能问题，从而影响数据库的整体性能。与用户沟通后，用户认为现在不是周末，归档日志备份最多中午几分钟就可以完成，不可能有能持续几十分钟的备份工作。他们立即登录系统，查看当前正在执行的备份作业，发现当前系统中没有rman备份进程。但是，他们通过智能诊断工具分析，发现当时确实存在较大的RMAN流量。于是查看了系统中rman备份历史数据的相关视图，发现了一个刚刚终止的不完整备份。与管理系统备份的人员沟通后确认，因为这是一套新的升级，存储和服务器都更换了，数据库的版本也升级了。因此，刚刚配置了备份任务，配置了错误的备份开始时间。第一次备份时间应该是从这个星期日开始的，却在今天中午触发了。他们发现后也立即终止了备份工作。这件事情当时就简单结束了，但是从上面的诊断分析我们发现有很多指标缺乏足够的历史数据，导致我们的异常检测无法进行。所以在当时智能诊断的分析结果中，IO延迟的问题排在第一位，智能诊断工具也根据其他一些线索发现备份任务可能存在问题。但是，如果你看结果，IO延迟可能是主要原因。其实是备份作业导致了IO问题，这是导致问题的主要原因。去年这个案例发生的时候，我们基于等待事件的智能诊断工具还没有开发出来，但是用户的历史数据已经送到我们实验室了。今天早上想写点什么的时候，就翻到了这个案例。于是我重新使用等待事件智能分析工具进行了分析。虽然使用了历史采样数据进行分析，但是等待事件的分析很好的还原了当时系统的场景，更准确的发现了当时系统存在的问题。这种诊断比上面的诊断准确得多。如果是人工分析，有经验的高手根据自己的经验举一反三，很容易切中要害。然而，智能分析主要依赖于有缺陷的数据和算法，因此很难像人类专家那样进行综合分析。在以往的运维事件中，我们也发现，这种三明治算法往往可以通过不同维度的多个通道进行分析，然后对结果进行汇总，从而取得更好的效果。在使用指标异常检测进行智能诊断分析时，将结果与同一时间段的等待事件分析相结合，可以获得更好的分析性能。后续我们将开展这方面的研究和验证工作。后面会和大家分享实践的成果！
