当前位置: 首页 > 科技观察

说说运维告警系统的持续优化

时间:2023-03-21 23:27:03 科技观察

运维告警是运维自动化系统最基本的功能。早期的运维监控系统只是报告系统是否还活着。那个年代的数据库运维非常简单。大部分故障是业务部门报警的,运维部门才知道,哦,数据库有问题。当时的领导总是希望运维部能比业务部早几分钟知道系统有问题。这样当业务领导打电话问问题的时候,他们可以说我们已经在恢复了。随着运维能力的提升,仅仅监控数据库是否存活已经不能满足IT部门运维的要求。“防患于未然”成为IT部门对运维监控最基本的要求。然而,要做到这一点并不容易,因为我们需要强大的监控和预警能力,才能及时发现系统中的隐患。因此,我们收集了更多指标并建立了基线。通过基线,我们可以对某个指标的异常进行报警。但是运维告警要实现单一的基线告警并不容易。虽然目前主流的开源监控平台大多基于基线告警,但是基线告警的能力还是太弱,容易产生大量无意义的告警。因此,相对更准确的组合规则告警取代了简单的基线告警。通过一套业务规则和几个指标之间的组合关系,更容易描述一个特定的故障场景。稍微复杂一点的规则引擎,可以通过正则表达式实现更精准的告警。近年来,在D-SMART上,这种我们称之为“运维体验告警”的模式发挥了重大作用,完全取代了基线告警。通过这种定时告警的组合,不仅可以收敛告警数量,还可以收敛告警问题的故障原因,为问题分析和溯源提供专业的诊断工具。这种基于规则的复合场景告警可以大大减少告警数量,对运维告警能力的提升起到很大的作用。我们还可以将报警信息推送到企业微信,让报警更有用。企业微信推送是一个很好的功能,可以把聊天群和告警推送紧密结合起来。遗憾的是,最近微信推送接口已经全面改版。企业推送平台必须托管在腾讯云的专用区域,增加了构建这个接口的复杂度,也可能在准备商业收费。以上是某企业微信消息机器人发送的告警信息。细心的朋友可能会看到这个闹钟好像有点不一样。上面的CPU占用率比较高的告警,显然只有在高于90%的时候才出现。在这条告警信息中,当前CPU占用率只有29.2%。其实我们要警告的不是指标,而是数据库的异常。十几年前,服务器资源经常不足的时候,大部分系统都在高负载下运行,CPU占用率经常会长时间超过90%甚至100%。一旦发生,需要DBA去处理。.但是当前系统的CPU资源往往是充足的,平时系统CPU使用率可能只有10%左右,发生异常时可能达不到90%。因此,我们设置的90%CPU警报阈值可能过高。我们甚至要针对不同系统的不同时间段或不同业务特征的时段设置不同的告警阈值,以实现更准确的告警。基于以上原因,对于CPU等资源占用过高的告警不能采用传统的方式。我们需要发现系统中的异常,所以我们需要检测异常,而不是特定的阈值。于是就有了这种基于“异常检测”的预警。通过上面的告警,我们大致知道这个系统的CPU占用率出现了异常,而且告警发生时的CPU占用率并不算太高,不到30%。如果我手头有更紧急的事情,我们可以等一下再处理这个异常。幸运的是,几分钟后我们又收到了一条告警信息,业务关注的关键SQL的平均逻辑读突然增加了。这大概是说这条SQL的执行计划发生了变化或者访问的表的数据发生了变化,而这个告警和上面的CPU使用率突然高的告警有关,很可能是这条SQL语句的执行成本Going高是CPU使用率峰值的主要原因。告警收敛是目前很多AIOPS公司正在做的事情。事实上,以上两个告警很可能是相关的。最好能把这两个告警合并。不过,以我们现在的技术水平,想要将两者直接融合还是不可能的。我们通过运维知识图谱实现了部分场景的自动合并。但由于计算量过大的问题,运维Dimension报警。为什么是这样?按理说,如果SQL语句的执行成本增加,导致逻辑读增加,进而导致CPU使用率增加,那么逻辑读的增加应该先发生,然后才是CPU使用率的增加。在实际监控中准确捕捉到如此细微的变化并不容易。这种情况下,普通的监控是很难做到的,只有trace可以做到。因为监控是周期性的采样,即使监控采样周期缩短到30秒,也有可能采集不到这样的顺序变化。CPU使用率每2分钟定期采样一次,而关键SQL跟踪是每5分钟一个任务,因此关键SQL跟踪发现问题具有滞后性。另外,还有一些告警场景,不是每次抓到异常都告警,而是需要满足一定时间内连续发生或者M次中至少有N次发生的规则,所以顺序和关联组合变得更加复杂的。同时,由于数据库系统是一个非常复杂的系统,以我们目前的技术能力,不可能在监控阶段就把它融合清楚。因此,我们选择同时发出多个告警,然后让DBA使用工具进行诊断发现。错误的合并很可能会误导后续的问题诊断,所以我们选择让DBA和专家看到更多的细节,而不是帮助他们做出错误的判断。因为在关键SQL上有告警,我们不能像之前的告警那样暂时搁置。所以你可以通过诊断工具做一些分析。确实,在报警期间,这条SQL的执行成本发生了变化。监控的目的是发现异常。过去在技术条件不具备的情况下,我们只能简单地将异常定义为某个阈值。久而久之,我们误以为监控就是监控的门槛。事实上,近年来监控技术发展迅速。从简单的指标监控到日志监控、态势监控,技术日趋成熟。因此,我们也应该尝试让运维告警从发现异常、自动分析异常开始,逐步走向自动化处理。现在的技术可能离自动化处理还有很远的距离,但是我们在减少告警数量和合并告警场景方面还有很大的提升空间。减少告警数量的第一个方法是优化恢复告警的处理策略。如果发生告警后,过一段时间系统恢复正常,或者风险消失,应该如何处理?还是要一个个死去,要求闭环管理,还是可以暂时不管?每个企业采用的不同管理模式可能会有不同的处置方式,但随着需要运维管理的系统数量不断扩大,即使只是对核心系统的每条告警信息进行闭环管理也是一件成本比较高的事情。如果这样的告警我们处理起来比较容易,如果连恢复的告警都得一一闭环分析,那工作量就大了。但是,对恢复的告警置之不理并不是一种合理的态度。如果这些问题确实是由一些深层次的隐患引发的,如果不加以分析,就会留下一些地雷,随时可能引爆。这让我们进退两难。如果不做闭环管理,可能会有隐患。如果做闭环管理,成本是承受不起的。解决这个问题最好的方法就是检查。巡检是近年来最受诟病的运维业务。如果你不做检查,你将对问题负责。如果检查后没有发现任何问题,您将浪费时间并承担责任。在这种无奈中,一个非常重要的运维工具被边缘化了。有过异常,但很快就痊愈的问题,其实在检查的时候可以统一分析。在巡检时,可以统一分析数据库在一定时间内的整体情况,对一定时间内的多种异常情况进行整体分析,从而发现系统的诸多隐患。形成检验工作没有多大价值的观点的主要原因是检验质量。如果巡检由于工作量太大而无法分析某段时间内的几个问题,那么巡检工作就有了新的价值。只是这个分析必须是自动化的,不能手动完成。基于这样的思路,我们在最近几个版本中对检验报告的优化做了很多工作,力求检验报告实用化。在最近的一系列修订中,我们发现了大量之前报告的问题。发现问题最好的方法就是让我们的专家通过阅读检测报告帮助远程用户分析问题。经过多次这样的迭代,报告的质量也有了很大的提升。这些更新将在本月底发布的V2.2中与大家见面。运维告警做起来不难,但是做好很难。我们希望把专家多年来积累的经验提炼出来,融入到这项工作中,在用户这边不断实践,不断提升这种能力。如果您对这项工作感兴趣,我们也可以交流,我们愿意继续与您分享我们在实践中的发现。