基线告警是目前大部分数据库监控软件的最重要的功能之一，可以说，基线告警是运维人员的眼睛和耳朵，不过搞运维的人都为这个眼镜耳朵伤透了脑筋，甚至很多人都被铺天盖地的无效告警伤害过。
基线告警虽然实现起来很简单，也一定是有用的，不过每个系统的运行特性都不同，因此基线到底设置成多少呢是个令人头痛的事情。IO延时的告警阈值设置为50毫秒还是20毫秒呢？如果设置为20毫秒，那么经常出告警，但是系统也没啥问题。如果设置为50毫秒，有时候并发量高得时候，30多毫秒系统就出大问题了，甚至有时候IO延时50毫秒了还没问题，但是有时候才30多毫秒，系统就挂了。
另外一种情况是，我们可能运维了数十个甚至数百个大大小小的数据库，数据量差异很大，运行负载也各不相同。如果只是设计几种基线模板，适用于这么多系统，那么肯定会遇到不太合适的情况。如果能够根据每个系统的运行状态，为每个系统设置一套基线，情况会好很多，但是工作量是极大的。
另外一方面，数据库系统的基线并不是一成不变的，随着系统负载的变化，业务增长，设备的老化，基线每年都在变，总不成每年都根据系统的情况调整一次基线？那么DBA也没时间干别的事情了。
即使我们做了很多工作，基线告警依然不够准确，每条告警信息都去处置，肯定忙不过来，很多时候我们只能忽略绝大多数告警信息。那么问题又来了，在黄油定律的主导下，很可能被我们忽略的某个告警，最终真的出事了。
正是因为这个问题，在设计D-SMART的告警功能的时候，基线并不是用来报警的，系统告警台是不推送基线告警的，仅仅推送运维经验告警，而运维经验告警是基于一组规则的故障模型触发的。
虽然不需要通过基线异常来产生系统告警，不过基线告警还是反映指标是否正常的最省事的方法，在进行诊断分析时我们还是需要判断某个指标是否异常。为了避免基线阈值设置的不合理问题，指标是否异常是通过异常检测算法来判断的，并不依赖于基线模板。
虽然如此，我们在系统中还是设置了基线预警模板，并根据这个模板，自动记录基线异常的告警信息（仅仅记录，并不推送），基线产生的告警主要用于日检和月度巡检时发现系统“可能”存在的问题。
有一种更加灵活的基线，那就是动态基线。最早的动态基线的实现是为了解决每天白天和夜间不同的业务负载时某些指标的合力波动范围的问题的。或者解决工作日与非工作日，月底业务高峰期与平时业务高峰期的差异性告警问题。以前我们管理的系统比较少的时候，还可以精工细作，随着信息系统规模的不断扩大，这种精益化运维的模式极难持续。如何解决如今IT系统数量爆炸式增长时加量不加价，实现减员增效，对于大多数IT运维部门都是一个头疼的问题。如果这一切能够变成自动的，那么就可以解决一个大问题了。
上图是我们实验室的一个基线告警的截图，告警的阈值很多都是有零有整的，这些阈值并不是配置出来的，而是动态计算出来的。在实现动态基线的时候，我刚开始的设想是不设置基线模板，而是通过异常检测算法自动计算异常，发现异常就告警。不过研发部门认为这样做计算量太大，会导致Monitor任务变得不稳定。因此做了一个变通，那就是将异常检测算法改造后动态生成某个指标的基线阈值。这样处理后，Monitor在分析刚刚采集回来的数据的时候，就可以按照传统的基线模板的模式去处理了。
在配置基线告警的时候，我们引入了一个虚拟模板-“智能基线告警模板”，这个模板不需要预先配置，而是系统自动生成的。生成这个模板的规则在图数据库中以图谱的方式存储，每天固定的时间里，后台任务会自动计算这个模板所需要的阈值，然后将计算结果存储到Redis中，供Monitor做基线评估时使用。
因此当系统刚刚上线的时候，这个模板还是一个虚拟的，没有真实数据的模板，等系统跑上十天八天，数据就比较精准了，此时这个智能模板就可以发挥作用了。目前智能基线模板的功能还是BETA阶段，使用起来还不够方便。比如刚刚接入系统时还不能直接使用该模板，还需要使用常规模板，系统运行10天以后，模板数据比较准确了，才能切换。这样使用起来也不够方便，如果我们有100多套数据库，那么配置起来还是挺费劲的。
目前传统模板提供了一个对象应用功能，可以实现一键批量绑定，而智能模板是一个虚拟模板，目前在模板管理中是看不见的，因此无法实现一键绑定，后续我们将在V2.2中提供一个这样的功能。这样系统刚刚接入时可以使用传统基线模板，半个月后，再手工设置为智能基线模板。甚至今后还可以提供更为方便的模式，在设置基线模板的时候提供一个选型，选择参数，10天后自动切换为智能基线模板。
而在动态基线的自适应能力方面，也仍然有着极大的提升空间，针对不同的行业用户的不同特点，其基线计算是不同的，比如券商的核心交易系统，只有在开市期间的负载才是有意义的，你如果把其他时段的数据加入进来计算，肯定会影响计算结果的准确性。因此在系统中加入“系统特征”这个参数十分重要。“系统特征”可以微调算法，让算法更加准确。
运维自动化系统，需要带给DBA的是准确高效的报警，便捷的操作。想要做好这一点真的不易，因为大部分的开发人员都是脱离运维第一线很长时间或者甚至没有做过一天真正的运维工作。因此开发人员可能无法感知到运维人员的真实需求。做好一个运维自动化工具的项目还是比较容易的，因为客户会不断根据自己的运维习惯来提出修改意见，我们总是能把系统修改好；而要做一个好用的运维自动化产品就不易了，系统功能，使用习惯，面临的差异化的系统都让这项工作变得复杂很多。因此我们坚定的开启了社区版的发布，希望通过社区的力量，帮我们把产品打磨的更好。
