基线预警是数据库运维监控中最重要的手段之一。通过基线发现系统中某些指标的不合理波动，进而进行预警，是数据库运维监控中最重要的手段。是一种常用的方式，也是目前大多数企业采用的主要监控方案。虽然大家都在使用基线预警，但是大家关注的基线指标和阈值却有很大的差异。因为虽然大家使用的是同一类型的数据库，但是大家的系统却大相径庭。预警用什么指标，设置什么阈值，是非常个体化的。事实上，一个真正能够发挥作用的基线预警系统，蕴含着大量的运维经验。以每秒阅读时间这个指标为例，可以看出其取值范围波动较大，没有明显的聚集特征。我们应该如何为这些指标设定基线？确实很头疼。再来看看另一个数据库共享缓存区的命中率。它的点的集中度还是比较集中的，但是还是有分散的，而且数值相差很大。这些值应该被提醒吗？告警对我们运维的意义是什么？我真的不知道。而如果我们运维了成百上千个类似的数据库系统，我们就无法为这些数据库系统设定一个合理的基线门槛。如果不进行个性化设置，那么基线告警就会不准确，运维告警工作就会陷入进退两难的境地。有的朋友可能会说，为什么不用动态基线或者智能基线呢。动态基线确实可以避免上述问题，但是否一定有意义呢？我们看上面有严重的IOLATCNCY基线警告。IO延迟波动比较严重，但是这是什么意思呢？要发短信警告吗？运维人员收到短信是否应该处理？是否要对这个告警进行闭环管理？我们还不明白，运维告警的意义一方面是发现系统中的隐患，另一方面是在系统严重故障发生之前提前预警。看来这个被标记为“critical”的基线告警对我们的运维帮助不大。从上面的例子中，我们已经看到了基线告警的局限性。基于简单的单一指标异常的基线告警不能指示某类故障的发生。从而大大降低基线告警对运维的影响。简单升级基线告警，通过规则引擎构建故障模型，会有更好的效果。比如刚才动态基线产生的IO延迟基线异常，如果再叠加一些其他的条件，就可以构建更有针对性的告警。例如IO延迟基线异常，操作系统产生大量IO告警，或者发生多路链路切换等。这样的报警更有针对性，大大提高了报警的价值。从另一个角度来看，IO延迟基线异常，IO吞吐量也有很大提升，某条关键SQL的执行时间也变长了。这种报警也更有价值。也值得做闭环管理。用故障模型代替基线告警还有一个好处就是告警更有方向性，所以当告警发生时，问题的原因更容易诊断，因为单个指标异常的可能原因太复杂了，而且大多数情况使它无法分析。故障模型叠加了很多其他因素，所以故障的方向性更强，更容易分析问题。这也是为什么D-SMART的基线告警不推送到告警站，而代之以故障模型告警的主要原因。
