作者简介:周伟 百度高级研发工程师
负责百度智能运维(Noah)监控报警系统、通告平台;在精准报警、精准通告、报警收敛、公/私有云监控等方向具有广泛的实践经验。
监控报警是故障发现的重要一环,也是百度在AIOps的最早切入方向之一,目前百度AIOps在监控报警方面已经有两个场景取得突出效果:智能异常检测和智能报警合并。
如何支撑AIOps算法在监控报警系统的快速落地并产生业务价值,这对监控报警架构提出了很大的挑战!在上篇《AIOps对监控报警架构的挑战》文章中,我们介绍了监控报警系统在故障处理流程中的位置(故障发现和故障通告),并且分析了AIOps对监控报警架构的三个挑战。在本篇,我们将详细介绍应对这三个挑战的方案:
下面我们来详细看下这三个方案的实现细节。
在上篇《AIOps对监控报警架构的挑战》文章中,我们提到异常判断在落地AIOps智能异常检测算法时,遇到的最大挑战是算法迭代周期长达一个月,费时费力,算法的迭代成本非常高。
为了能快速落地AIOps算法,并能产生好的效果,提高报警准确率,我们希望算法的迭代周期从月降低到天级别,为了达到这个目标,需要异常判断系统满足这些需求:
基于这些需求,我们研发了策略运行平台。策略运行平台共分为三个环境:
上图是策略运行平台的架构图,我们以新建一个报警策略的场景来依次介绍下每个模块的功能:
为了负载平衡和Failover,任务分配模块需要将报警任务在任务运行模块中的不同实例间移动。当一个报警任务从实例A移动到实例B上后,实例B会向数据转发模块订阅任务需要的数据,而实例A则相应取消数据订阅。这样,数据订阅模块就能够将数据转发到正确的实例上,从而保证任务的正常运行。
如果算法脚本在运行过程中存在内部状态,任务在实例B上启动后,可以在初始化的时候向数据cache请求近期的数据以重建内部状态。根据我们的实践经验,大部分任务只需要最近1到2个小时的数据就能够重建内部状态了。
通过策略运行平台,我们已经将算法迭代周期从月减少到天级别。另外,我们还将框架开放给业务运维工程师使用,业务运维工程师具有丰富的业务运维经验,由他们自己来开发异常检测算法,可以将他们的专家经验固化到报警系统中,提高报警的准确性。
为什么报警事件需要用状态机描述呢?为了回答这个问题,我们首先介绍下什么是报警事件。
我们先来看一个简单的故障场景,上图中的时序数据展示了某服务的平均响应时间(latency),假设监控策略是如果latency大于800则报警:
我们再来看一个更复杂的场景。在实际运维过程中,我们会分省份和运营商维度采集服务的平均响应时间(latency),即多维度数据。如果我们分别针对不同省份和运营商都单独配置一个监控策略,很明显,这会导致报警配置的管理成本很高,实际上运维工程师希望配置类似latency{isp=*,province=*} > 80的报警策略,就可以同时对所有省份和运营商的latency指标进行分别判断,这就是所谓的多维度异常判断配置。
上图展示了一个多维度判断配置的例子,很明显,在T2-T3期间,广东电信和北京移动的latency指标同时发生异常。如果策略在故障期间只产生一个报警事件,那么我们根据事件无法区分是哪个省份和运营商的数据异常了,所以一个策略需要针对每个数据维度分别产生一个报警事件(特征四)。
上面通过两个业务场景介绍了报警事件的业务模型,以及报警事件的四个特征,让大家对报警事件有一个直观的认识,下面我们来看下基于状态机的事件管理引擎。
我们分报警认领和报警升级两个场景来介绍基于状态机的事件管理引擎。
我们结合状态机来看下报警认领场景中,报警事件的生命周期是如何演化的:
我们可以看到,报警事件的状态变迁过程其实就是一个状态机的运行过程,每个状态都有对应的进入条件和动作,所以我们将报警事件抽象成状态机来描述它。
我们再来看一个报警升级的场景,假设对应的报警升级配置如下所示:
其中第1级配置的含义是:报警接收人为运小二,报警发送渠道为短信,如果超过1分钟没有进行报警认领,或者认领了但是超过2分钟故障没有恢复,则报警事件会升级到第二级。其他层级的配置含义以此类推。
这个报警升级配置对应的状态机如下图所示。
我们通过一个真实的报警认领场景来了解状态机的变迁过程:
经过上面的案例分析,我们看到,在报警升级场景下,报警事件的状态变迁过程将变得更加复杂,而且不同事件状态之间变迁的触发条件和执行动作也可能会各不相同。基于状态机的报警事件模型不仅足够抽象,表达能力强,可以囊括繁杂多样的事件管理需求;而且可扩展性强,通过状态机描述文件定义状态机行为,可以快速添加“数据断流”、“报警失效”等新状态,来满足无数据检测和报警失效检测等更多复杂的事件管理需求。
在上篇《AIOps对监控报警架构的挑战》文章中,我们通过三个场景给大家呈现报警风暴的真面目,其中提到了可以对大量报警消息进行有效的组织,然后再发送,从而将运维工程师从报警风暴中解救出来,这就是所谓的报警合并。
报警合并的基本思路是将相关联的报警消息组成到一起,作为一条信息发送给运维工程师,这样运维工程师可以根据这种相关性来辅助故障定位。
那如何来描述这种相关性呢?基于百度的运维场景,我们挖掘出以下三类相关性:
下图展示了服务A下多个实例同时故障,如果对每个实例的故障,都给运维工程师发送一条消息,那么就很容易产生报警风暴。我们通过将报警缓存一段时间(可以设置最大延迟时间,从而保证报警时效性),然后将缓存内所有属于服务A的报警合并到一起后发送,这样运维工程师只会收到一条报警,而且在报警信息中还会告知运维人员,服务A下有大量实例异常,这样运维人员可以根据这个提示有针对性去排查故障。
关于报警合并的更多细节,可以参考我们之前的文章《我在百度对抗报警风暴(一)》、《我在百度对抗报警风暴(二)》。
本文我们首先回顾了AIOps对监控报警架构的挑战,然后从工程角度聊了聊AIOps落地难的应对之策。通过这两篇文章给大家系统性地介绍了百度Noah监控报警系统的前世今生,希望能给大家带来一些收获。如果大家对智能运维感兴趣,欢迎留言继续交流。
如果你喜欢本文,请分享到朋友圈,想要获得更多信息,请关注我们!
如果你有任何问题欢迎留言咨询~
如果想试用我们的企业级运维平台NoahEE,请联系邮箱:noah_bd@baidu.com
联系客服