聊聊AIOps落地监控报警的应对之策

做者简介：周伟 百度高级研发工程师
负责百度智能运维（Noah）监控报警系统、通告平台；在精准报警、精准通告、报警收敛、公/私有云监控等方向具备普遍的实践经验。

干货概览

监控报警是故障发现的重要一环，也是百度在AIOps的最先切入方向之一，目前百度AIOps在监控报警方面已经有两个场景取得突出效果：智能异常检测和智能报警合并。

如何支撑AIOps算法在监控报警系统的快速落地并产生业务价值，这对监控报警架构提出了很大的挑战！在上篇《AIOps对监控报警架构的挑战》文章中，咱们介绍了监控报警系统在故障处理流程中的位置（故障发现和故障通告），而且分析了AIOps对监控报警架构的三个挑战。在本篇，咱们将详细介绍应对这三个挑战的方案：

• 为了应对挑战一，咱们研发了策略运行平台，让AIOps算法迭代找到飞通常的感受。
• 为了应对挑战二，咱们提出了基于状态机的事件管理引擎，让事件管理so easy。
• 为了应对挑战三，咱们设计了灵活的报警合并方案，让值班工程师完全跟报警风暴say bye bye。

下面咱们来详细看下这三个方案的实现细节。

策略运行平台，让算法迭代飞起来

在上篇《AIOps对监控报警架构的挑战》文章中，咱们提到异常判断在落地AIOps智能异常检测算法时，遇到的最大挑战是算法迭代周期长达一个月，费时费力，算法的迭代成本很是高。

为了能快速落地AIOps算法，并能产生好的效果，提升报警准确率，咱们但愿算法的迭代周期从月下降到天级别，为了达到这个目标，须要异常判断系统知足这些需求：

• 减小算法工程实现成本，弥合线下算法脚本和线上运行代码的鸿沟，从而能快速验证算法脚本的真实效果。
• 快速评估算法的稳定性、性能和资源消耗，尽早发现问题，不将问题带到线上，保证线上算法运行环境的稳定性。
• 分离算法代码和算法模型，支持算法模型的独立更新，加快算法模型的迭代速度。

基于这些需求，咱们研发了策略运行平台。策略运行平台共分为三个环境：

• 离线环境：离线环境提供了策略开发框架，策略人员基于策略框架的标准Lib接口开发算法。同时策略开发框架还支持算法的离线回溯、时序数据可视化等功能。
• 在线环境：在线环境提供了一个稳定可靠的算法运行环境。在线环境会为每一个任务启动一个子进程，在子进程中启动策略运行时环境，运行环境会提供跟策略开发框架一致的Lib接口，这样就能够将离线开发的算法脚本直接放到线上运行。
• 近线环境：近线环境和在线环境实际上是同一套架构，只是目的不一样。近线环境会引入线上的小流量数据提早进行算法验证，保证线上和线下的运行效果一致；另外，近线环境还会评估算法脚本的资源消耗和稳定性，若是评估结果不符合预期，那么算法脚本就会在近线环境被拦截住，从而保证线上环境的高可靠。

架构介绍

上图是策略运行平台的架构图，咱们以新建一个报警策略的场景来依次介绍下每一个模块的功能：

1. 上层业务系统调用API接口，向业务模块发起新建策略的请求，业务模块会将报警配置、算法脚本和算法参数模型存储起来。
2. 任务分配模块会实时感知到新建立的报警策略，并将报警策略转化为任务，而后分配给任务运行模块。
3. 任务运行模块周期性汇报心跳给任务分配模块，经过心跳拉取分配给本身的任务列表。任务运行模块根据任务列表为每一个任务启动一个策略运行时环境，运行时环境负责启动算法脚本，并周期性地驱动算法脚本执行异常判断逻辑。另外一方面，任务运行模块根据报警策略配置向数据转发模块订阅所需的数据，将接收到的数据转发给运行时环境，并将算法脚本返回的异常判断结果发送给下游的事件管理系统。
4. 数据转发模块根据订阅配置到数据源订阅数据，将接收到的数据转发给任务运行模块。同时，数据转发模块还会将全部接收到的数据存储到数据cache中，容许算法脚本在运行过程当中方便地拉取近期的数据。
5. 数据适配模块能够适配不一样的上游数据源，支持推和拉两种获取数据模式。策略运行平台容许多个针对不一样上游数据源的数据适配模块同时存在，从而支持平台中的报警策略使用来自于不一样数据源的数据。

为了负载平衡和Failover，任务分配模块须要将报警任务在任务运行模块中的不一样实例间移动。当一个报警任务从实例A移动到实例B上后，实例B会向数据转发模块订阅任务须要的数据，而实例A则相应取消数据订阅。这样，数据订阅模块就可以将数据转发到正确的实例上，从而保证任务的正常运行。

若是算法脚本在运行过程当中存在内部状态，任务在实例B上启动后，能够在初始化的时候向数据cache请求近期的数据以重建内部状态。根据咱们的实践经验，大部分任务只须要最近1到2个小时的数据就可以重建内部状态了。

经过策略运行平台，咱们已经将算法迭代周期从月减小到天级别。另外，咱们还将框架开放给业务运维工程师使用，业务运维工程师具备丰富的业务运维经验，由他们本身来开发异常检测算法，能够将他们的专家经验固化到报警系统中，提升报警的准确性。

状态机引擎，让事件管理更轻松

为何报警事件须要用状态机描述呢？为了回答这个问题，咱们首先介绍下什么是报警事件。

什么是报警事件？

咱们先来看一个简单的故障场景，上图中的时序数据展现了某服务的平均响应时间（latency），假设监控策略是若是latency大于800则报警：

1. 很明显，在T1-T2时间段latency指标处于异常状态，在这期间有7个异常点，从运维工程师看来，这7个异常点应该归属为一个报警事件，因此报警事件是具备持续性（特征一）。
2. 异常发生后，报警系统会在故障期间重复通告Oncall工程师，故障恢复后也须要发送恢复通知，因此一个报警事件会产生多个报警消息（特征二）。
3. 另外，为了保证Oncall工程师介入处理故障期间免受打扰，咱们还须要提供报警认领功能。若是报警认领的对象是报警消息（好比短信）。一方面，一个报警事件会产生多条报警消息，这意味着同一我的对同一个故障须要认领屡次；另外一方面，假设故障已经恢复，可是报警消息尚未被认领，会继续提醒Oncall工程师认领，这也不符合Oncall工程师的预期。因此报警认领的对象须要为报警事件（特征三）。

咱们再来看一个更复杂的场景。在实际运维过程当中，咱们会分省份和运营商维度采集服务的平均响应时间（latency），即多维度数据。若是咱们分别针对不一样省份和运营商都单独配置一个监控策略，很明显，这会致使报警配置的管理成本很高，实际上运维工程师但愿配置相似latency{isp=*,province=*} > 80的报警策略，就能够同时对全部省份和运营商的latency指标进行分别判断，这就是所谓的多维度异常判断配置。

上图展现了一个多维度判断配置的例子，很明显，在T2-T3期间，广东电信和北京移动的latency指标同时发生异常。若是策略在故障期间只产生一个报警事件，那么咱们根据事件没法区分是哪一个省份和运营商的数据异常了，因此一个策略须要针对每一个数据维度分别产生一个报警事件（特征四）。

上面经过两个业务场景介绍了报警事件的业务模型，以及报警事件的四个特征，让你们对报警事件有一个直观的认识，下面咱们来看下基于状态机的事件管理引擎。

为何须要状态机？

咱们分报警认领和报警升级两个场景来介绍基于状态机的事件管理引擎。

1. 报警认领场景

咱们结合状态机来看下报警认领场景中，报警事件的生命周期是如何演化的：

• T1时刻：latency指标异常，监控系统会产生一个异常状态的报警事件，并发送异常通知给Oncall工程师。
• T2时刻：Oncall工程师没有响应报警，监控系统重复发送报警给Oncall工程师。
• T3时刻：Oncall工程师响应报警，完成认领报警，表示已经在跟进中。同时，监控系统会将认领操做广播给全部的Oncall工程师，表示已经有人在跟进报警了。
• T4时刻：Oncall工程师修复故障后，该报警事件变为正常状态，监控系统会发送故障恢复通知。

咱们能够看到，报警事件的状态变迁过程其实就是一个状态机的运行过程，每一个状态都有对应的进入条件和动做，因此咱们将报警事件抽象成状态机来描述它。

2. 报警升级场景

咱们再来看一个报警升级的场景，假设对应的报警升级配置以下所示：

其中第1级配置的含义是：报警接收人为运小二，报警发送渠道为短信，若是超过1分钟没有进行报警认领，或者认领了可是超过2分钟故障没有恢复，则报警事件会升级到第二级。其余层级的配置含义以此类推。

这个报警升级配置对应的状态机以下图所示。

咱们经过一个真实的报警认领场景来了解状态机的变迁过程：

• 03:14 – 线上服务发生故障，监控系统发送短信报警给第一级接收人：运小二。
• 03:15 – 因为运小二超过1分钟没有认领报警事件，则事件状态升级到第二级，并发送短信和电话给第二级接收人：运小伟。运小伟收到报警后，当即认领故障，监控系统同时会给运小二和运小伟发送认领信息。
• 03:17 – 因为运小伟不太熟悉业务，过了2分钟，故障尚未恢复，则报警事件升级到第三级，并发送短信和电话给三线值班人：运小博，运小博认领了故障后，和运小伟一块儿定位故障。
• 03:20 – 通过两人的一番努力，线上故障恢复了，则报警事件状态变成正常，并发送恢复正常通知。

通过上面的案例分析，咱们看到，在报警升级场景下，报警事件的状态变迁过程将变得更加复杂，并且不一样事件状态之间变迁的触发条件和执行动做也可能会各不相同。基于状态机的报警事件模型不只足够抽象，表达能力强，能够囊括繁杂多样的事件管理需求；并且可扩展性强，经过状态机描述文件定义状态机行为，能够快速添加“数据断流”、“报警失效”等新状态，来知足无数据检测和报警失效检测等更多复杂的事件管理需求。

报警合并，让报警风暴成为过去

在上篇《AIOps对监控报警架构的挑战》文章中，咱们经过三个场景给你们呈现报警风暴的真面目，其中提到了能够对大量报警消息进行有效的组织，而后再发送，从而将运维工程师从报警风暴中解救出来，这就是所谓的报警合并。

报警合并的基本思路是将相关联的报警消息组成到一块儿，做为一条信息发送给运维工程师，这样运维工程师能够根据这种相关性来辅助故障定位。

那如何来描述这种相关性呢？基于百度的运维场景，咱们挖掘出如下三类相关性：

1. 报警消息具备相同的维度属性，好比具备相同的策略名，或者相同的部署属性（好比产品线、模块、集群、实例、机器等属性）。
2. 报警消息所属的模块具备关联关系，好比A模块调用B模块，若是B出现异常，通常A也会有相关异常，而咱们能够经过历史的异常事件来挖掘这类关联性。
3. 当发生机房故障时，位于同一个机房内部所产生的报警消息不必一一发送了，能够有效组织成一条消息发送给运维工程师。

下图展现了服务A下多个实例同时故障，若是对每一个实例的故障，都给运维工程师发送一条消息，那么就很容易产生报警风暴。咱们经过将报警缓存一段时间（能够设置最大延迟时间，从而保证报警时效性），而后将缓存内全部属于服务A的报警合并到一块儿后发送，这样运维工程师只会收到一条报警，并且在报警信息中还会告知运维人员，服务A下有大量实例异常，这样运维人员能够根据这个提示有针对性去排查故障。

关于报警合并的更多细节，能够参考咱们以前的文章《我在百度对抗报警风暴（一）》、《我在百度对抗报警风暴（二）》。

总  结

本文咱们首先回顾了AIOps对监控报警架构的挑战，而后从工程角度聊了聊AIOps落地难的应对之策。经过这两篇文章给你们系统性地介绍了百度Noah监控报警系统的前世此生，但愿能给你们带来一些收获。若是你们对智能运维感兴趣，欢迎留言继续交流。

舒适提示

若是你喜欢本文，请分享到朋友圈，想要得到更多信息，请关注咱们！
若是你有任何问题欢迎留言咨询~
若是想试用咱们的企业级运维平台NoahEE，请联系邮箱：noah_bd@baidu.com