AIOps对监控报警架构的挑战

做者简介：周伟    百度高级研发工程师

负责百度智能运维（Noah）监控报警系统、通告平台；在精准报警、精准通告、报警收敛、公/私有云监控等方向具备普遍的实践经验。

干货概览

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

如何支撑 AIOps 算法在监控报警系统的快速落地并产生业务价值，这对监控报警架构提出了很大的挑战！本文首先介绍百度Noah监控报警的功能和业务模型，而后重点分析百度监控报警系统在落地 AIOps 过程当中遇到的挑战。

百度Noah监控报警系统

首先咱们介绍下百度的标准故障处理流程，如上图所示，主要分为如下7个过程：

1. 故障发生：好比当内网机房核心交换机发生故障时，会形成内网的网络故障，从而致使产品线的流量损失。

2. 故障发现：监控系统实时检测到产品线的流量异常。

3. 故障通告：监控系统会经过短信或电话等渠道通知业务运维人员，产品线流量有异常。

4. 故障止损：业务运维人员会执行故障预案，或者借助故障自愈平台智能地执行故障止损操做，以达到快速止损的目的，常见的操做是将流量从故障机房切到非故障机房。

5. 故障定位：运维人员和研发人员一块儿定位故障根因。

6. 故障恢复：当定位到问题后，运维人员开始执行修复操做，直到线上的全部服务（包括未接流量的模块）都完全恢复正常。

7. 故障总结：运维人员会对故障处理流程进行复盘总结，好的方面继续保持，很差的方面排期改正。

在整个故障处理流程中，监控系统主要负责故障发现到故障定位的环节；报警系统做为监控系统的子系统，主要负责故障发现和故障通告。

百度Noah报警系统最先服务于百度内部的监控平台，提供从机器、实例到上层业务等全方位、立体化的监控报警能力，已经覆盖百度的全部产品线。同时，系统面临很大的挑战，每秒须要处理千万级个数据点，线上的监控配置已经达到百万级别，天天会产生千万个报警事件，在这么大的量级下，还需保证秒级的报警时效性。

百度Noah报警系统不只为百度内部用户服务，咱们还同时为公有云和私有云服务提供监控报警能力。咱们将内部强大的监控产品和运维理念输出到业界，打造了NoahEE产品（详见《百度云企业级运维平台——NoahEE》介绍 ），帮助客户一块儿提高运维效率和线上稳定性。另外，咱们还依托报警系统孵化出了百度AIOps智能运维产品，包括智能异常检测、故障定位、报警合并等高级功能，已经落地金融、交通、互联网等行业，受到客户一致好评。

业务模型

监控报警系统的核心使命是精准报警，那报警系统是如何进行故障发现和故障通告呢？咱们经过一个场景来了解下。

假设上图中的曲线是某产品线的流量指标（简称PV），其中每一个点表明一个PV数据点，假设但愿当PV值小于100时，异常判断结果为异常，并通告给业务运维人员。

监控报警系统会周期性地对最近一个数据点（Data）进行判断，若是PV小于100则判断结果为异常，不然判断结果为正常。当首次异常的时候（即判断结果从正常转为异常），会产生一个报警事件（Event）；当异常恢复时，则将报警事件结束掉。在报警事件持续期间，会根据报警规则产生一个或多个报警消息（Message），并将报警消息渲染成容易理解的文本，经过下游发送渠道（短信、电话等）送达给运维工程师。经过这么一个流程，监控报警系统就达到了故障发现和故障通告的目的。

相应地，咱们将监控报警系统拆分红如下三个子系统：

• 异常判断系统：主要功能是根据异常判断配置周期性地对数据进行判断，并将产生的判断结果（正常或异常）发送给下游。异常判断系统不只须要提供基于传统四则运算的异常判断，还须要提供基于AIOps算法的异常判断。

• 事件管理系统：主要负责报警事件的管理工做，并基于报警事件提供防抖动过滤、报警认领、逐级通告、报警静默等功能。

• 通告发送系统：主要负责报警合并、渲染和发送等功能。另外为了防止下游发送网关的带宽被某些业务的突发报警流量淹没而致使其它业务的报警消息得不到及时发送，还须要提供配额和流控功能，从而保证每一个业务公平地使用发送网关资源。

将监控报警系统拆分红三个子系统后，有如下两个好处：

• 系统功能边界清晰，具有可扩展的报警架构能力

每一个子系统能够根据自身的功能特色采用不一样的技术栈和部署架构，由不一样的研发工程师负责研发和维护。好比异常判断系统更偏向计算逻辑，能够采用Golang或C++这类更加注重执行效率的技术栈；而事件管理和报警发送系统更偏向于业务逻辑，能够采用Java或PHP等更注重研发效率的技术栈。

每一个子系统也能够独立进行功能和架构升级。好比异常判断系统须要大量的CPU资源，比较适合采用集群架构，这样方便横向扩展，增长系统吞吐能力；而通告发送系统的流量相对小些，初期能够采用主备架构，不只架构简单可靠，并且研发和维护成本小。假设随着业务的发展，业务须要更大的报警发送能力，通告发送系统只需保证对外接口不变，独立将自身架构升级为集群架构，就可获取更大的报警发送能力。

• 报警功能组件化，具有灵活的商业化交付能力

每一个子系统都是一个独立的功能组件，能够独立部署、升级，这样就具有灵活支持商业化交付能力。好比咱们能够只将通告发送系统单独交付给商业化客户，客户经过直接调用通告发送的接口就能够获取报警合并、渲染、发送等能力。

咱们遇到了哪些挑战？

经过上面的业务模型介绍，你们已经对监控报警系统有了全局的认识，那下面来详细分析落地AIOps遇到的问题。

1. 落地AIOps算法周期长，迭代成本高

咱们继续来看PV指标，经过对历史PV数据的观察，咱们发现不一样时间段的PV大小是上下波动的，好比在早上八九点是流量高峰期，在凌晨两三点是流量低峰期，另外工做日和周末的流量大小也是不一样的。这意味着，咱们不可能设置统一的阈值来检测PV流量的变化状况，那么怎么办呢？

百度策略人员研发了基于鲁棒回归的无监督突升突降检测算法，这个算法不须要设置PV阈值，便可检测流量的变化。下面展现的这个公式是其中的一步，其中变量y就是真实的PV值，f(x)表明利用某种算法预测到的PV值。若是对算法细节感兴趣，可参考文章：《咱们不同！告诉你百度是如何作智能流量异常检测的》。

这类异常检测算法相对于传统的四则运算，有如下不一样：

• 对不一样类型指标在不一样的场景下，算法f(x)是不相同的，特别是在初期探索阶段，咱们须要快速迭代算法，以验证哪一种算法效果最优。

• 算法f(x)会依赖根据历史数据训练到的模型，然而业务数据的特征复杂，不断变化，这意味着咱们须要按期更新策略模型，以保证算法的效果。

• 算法f(x)对CPU资源的需求差别很大，有的算法计算量很是小，可能单个CPU核就能够运行数千个此类任务，而有的算法会引入RNN等深度学习算法，计算复杂度特别高，每每就须要独占某个CPU核。

最初咱们落地这类AIOps算法时，总体的流程如上图所示：

1. 策略工程师用Python或Matlab编写算法脚本，并在线下进行Case回溯，保证算法的普适性。

2. 研发工程师将算法脚本改写成线上代码（C++或Java），以便在线上运行。

3. 测试工程师对改写后的算法代码进行测试回归。

4. 运维工程师对模块（包括算法代码和策略模型）进行发布上线。

上面的研发流程暴露出不少的问题。一方面，对咱们的研发工程师要求比较苛刻，既须要看得懂策略算法，又要熟知工程研发；另外一方面，算法的迭代周期比较长，常常以月为单位，可能算法刚上线，数据特征就发生了变化，致使算法失效；最后，即便算法程序迭代稳定了，可是参数模型还须要按期更新，因为参数模型和算法程序没有分离，致使后期参数模型的更新须要不断上线，提升了维护成本。

2. 报警管理需求繁杂多样，疲于应付

咱们再来看下报警管理的挑战。报警管理须要处理的需求比较多，咱们以一个典型的运维场景来串一下这些需求：

• 凌晨一点，网络运维工程师对网络进行调整，致使网络产生了短期的抖动，这类抖动的持续时间一般都在1到2分钟左右。网络抖动致使大量的业务监控指标发生相应的抖动，从而触发报警。此时业务运维工程师就但愿系统可以提供防抖动过滤功能，避免指标在短期抖动时触发报警。

• 凌晨三点，因为系统日志清理机制有问题，致使集群内60%机器的磁盘占用率超过安全线，触发报警。可是报警电话未能唤醒值班工程师，最终致使大规模系统故障。所以值班工程师但愿系统提供报警重复提醒功能，当值班工程师没有及时响应报警时，经过屡次重复呼叫来避免报警遗漏。

• 可是，当值班工程师被及时唤醒并开始处理故障后，系统持续的重复提醒会对值班工程师造成很大的干扰。所以工程师们就但愿引入报警认领功能，告知报警系统故障已经有人在处理，重复提醒能够中止了。

• 凌晨4点半，因为值班工程师是新入职的，对系统不够熟悉，日志清理的操做还未完成，致使故障持续。此时，就但愿系统可以提供报警升级功能，在故障长时间未解除的时候能够通知资深的二线值班工程师介入处理。

• 凌晨4点50，二线值班工程师完成日志清理，故障恢复。这时，二线工程师发现日志清理操做实际上是一套标准的止损操做，彻底能够在发生报警时自动执行。所以但愿系统可以提供报警回调功能，未来相似的问题就无需人工介入处理了。

• 除此以外，值班工程师可能还有断流检测、报警静默等等各类需求。

可见报警管理的需求复杂多样，若是咱们不能抽象出一个可扩展的报警管理模型，咱们将变得愈来愈被动。

3. 报警风暴淹没核心报警，一筹莫展

看完报警管理，咱们再来看下报警风暴的挑战。

为了不遗漏故障，运维工程师经常会在监控系统中定制大量的监控指标和报警规则，从而创建起从网络到机器、从实例到模块、再到上层业务的立体化监控。立体化的监控虽然极大提升了故障发现的能力，可是很容易致使一个故障触发大量报警，形成报警风暴。

为了让你们认识报警风暴的真面目，咱们来看三个典型的场景：

1. 机器故障：机器发生故障时，监控机器健康度的报警规则将会产生报警；而后监控机器上实例运行状态的报警规则也会产生报警；最后这些实例的上游应用模块也会受到影响，相关的报警规则也会开始报警。这样一来，一个机器的故障就可能会产生几十条的报警消息。

2. 应用模块故障：首先这个应用模块中的全部实例都会发出报警，紧接着上游应用模块也会产生报警。当应用模块中包含的实例比较多时，这类故障经常会产生数百条的报警消息。

3. 机房故障：会同时形成网络、机器、域名、应用模块、业务等多层次、多方面的异常报警，产生的报警消息能够多达数万条。

咱们能够看到，这三种典型故障对值班工程师都很是的不友好。他们的手机会被短信和电话轰炸，与此同时大量的报警消息却并不能帮助他们迅速寻找根因和制订止损方案。对大量报警消息先进行有效地组织，而后再发送，就成为值班工程师的一大需求。

总  结

本文首先介绍了百度Noah监控报警系统功能和业务模型，而后结合案例场景分析了咱们在落地AIOps时遇到的问题，让你们对监控报警系统的现状有一个直观的认识。咱们将在下篇文章中讲解如何来解决这些挑战，敬请期待。

舒适提示

若是你喜欢本文，请分享到朋友圈，想要得到更多信息，请关注咱们！

若是你有任何问题欢迎留言咨询~

若是想试用咱们的企业级运维平台NoahEE，请联系邮箱：noah_bd@baidu.com