AIOps对监控报警架构的挑战
作者简介
周伟 百度高级研发工程师
负责百度智能运维（Noah）监控报警系统、通告平台；在精准报警、精准通告、报警收敛、公/私有云监控等方向具有广泛的实践经验。
干货概览
监控报警是故障发现的重要一环，也是百度在AIOps的最早切入方向之一，目前百度 AIOps 在监控报警方面已经有两个场景取得突出效果：智能异常检测和智能报警合并。
如何支撑 AIOps 算法在监控报警系统的快速落地并产生业务价值，这对监控报警架构提出了很大的挑战！本文首先介绍百度Noah监控报警的功能和业务模型，然后重点分析百度监控报警系统在落地 AIOps 过程中遇到的挑战。
百度Noah监控报警系统
首先我们介绍下百度的标准故障处理流程，如上图所示，主要分为以下7个过程：
故障发生：比如当内网机房核心交换机发生故障时，会造成内网的网络故障，从而导致产品线的流量损失。
故障发现：监控系统实时检测到产品线的流量异常。
故障止损：业务运维人员会执行故障预案，或者借助故障自愈平台智能地执行故障止损操作，以达到快速止损的目的，常见的操作是将流量从故障机房切到非故障机房。
故障定位：运维人员和研发人员一起定位故障根因。
故障恢复：当定位到问题后，运维人员开始执行修复操作，直到线上的所有服务（包括未接流量的模块）都彻底恢复正常。
故障总结：运维人员会对故障处理流程进行复盘总结，好的方面继续保持，不好的方面排期改正。
在整个故障处理流程中，监控系统主要负责故障发现到故障定位的环节；报警系统作为监控系统的子系统，主要负责故障发现和故障通告。
百度Noah报警系统最早服务于百度内部的监控平台，提供从机器、实例到上层业务等全方位、立体化的监控报警能力，已经覆盖百度的所有产品线。同时，系统面临很大的挑战，每秒需要处理千万级个数据点，线上的监控配置已经达到百万级别，每天会产生千万个报警事件，在这么大的量级下，还需保证秒级的报警时效性。
百度Noah报警系统不仅为百度内部用户服务，我们还同时为公有云和私有云服务提供监控报警能力。我们将内部强大的监控产品和运维理念输出到业界，打造了NoahEE产品（详见介绍 ），帮助客户一起提升运维效率和线上稳定性。另外，我们还依托报警系统孵化出了百度AIOps智能运维产品，包括智能异常检测、故障定位、报警合并等高级功能，已经落地金融、交通、互联网等行业，受到客户一致好评。
业务模型
监控报警系统的核心使命是精准报警，那报警系统是如何进行故障发现和故障通告呢？我们通过一个场景来了解下。
假设上图中的曲线是某产品线的流量指标（简称PV），其中每个点代表一个PV数据点，假设希望当PV值小于100时，异常判断结果为异常，并通告给业务运维人员。
相应地，我们将监控报警系统拆分成以下三个子系统：
异常判断系统：主要功能是根据异常判断配置周期性地对数据进行判断，并将产生的判断结果（正常或异常）发送给下游。异常判断系统不仅需要提供基于传统四则运算的异常判断，还需要提供基于AIOps算法的异常判断。
事件管理系统：主要负责报警事件的管理工作，并基于报警事件提供防抖动过滤、报警认领、逐级通告、报警静默等功能。
通告发送系统：主要负责报警合并、渲染和发送等功能。另外为了防止下游发送网关的带宽被某些业务的突发报警流量淹没而导致其它业务的报警消息得不到及时发送，还需要提供配额和流控功能，从而保证每个业务公平地使用发送网关资源。
将监控报警系统拆分成三个子系统后，有以下两个好处：
系统功能边界清晰，具备可扩展的报警架构能力
每个子系统可以根据自身的功能特点采用不同的技术栈和部署架构，由不同的研发工程师负责研发和维护。比如异常判断系统更偏向计算逻辑，可以采用Golang或C++这类更加注重执行效率的技术栈；而事件管理和报警发送系统更偏向于业务逻辑，可以采用Java或PHP等更注重研发效率的技术栈。
每个子系统也可以独立进行功能和架构升级。比如异常判断系统需要大量的CPU资源，比较适合采用集群架构，这样方便横向扩展，增加系统吞吐能力；而通告发送系统的流量相对小些，初期可以采用主备架构，不仅架构简单可靠，而且研发和维护成本小。假设随着业务的发展，业务需要更大的报警发送能力，通告发送系统只需保证对外接口不变，独立将自身架构升级为集群架构，就可获取更大的报警发送能力。
报警功能组件化，具备灵活的商业化交付能力
每个子系统都是一个独立的功能组件，可以独立部署、升级，这样就具备灵活支持商业化交付能力。比如我们可以只将通告发送系统单独交付给商业化客户，客户通过直接调用通告发送的接口就可以获取报警合并、渲染、发送等能力。
我们遇到了哪些挑战？
通过上面的业务模型介绍，大家已经对监控报警系统有了全局的认识，那下面来详细分析落地AIOps遇到的问题。
我们继续来看PV指标，通过对历史PV数据的观察，我们发现不同时间段的PV大小是上下波动的，比如在早上八九点是流量高峰期，在凌晨两三点是流量低峰期，另外工作日和周末的流量大小也是不同的。这意味着，我们不可能设置统一的阈值来检测PV流量的变化情况，那么怎么办呢？
百度策略人员研发了基于鲁棒回归的无监督突升突降检测算法，这个算法不需要设置PV阈值，即可检测流量的变化。下面展示的这个公式是其中的一步，其中变量y就是真实的PV值，f(x)代表利用某种算法预测到的PV值。如果对算法细节感兴趣，可参考文章：。
这类异常检测算法相对于传统的四则运算，有以下不同：
对不同类型指标在不同的场景下，算法f(x)是不相同的，特别是在初期探索阶段，我们需要快速迭代算法，以验证哪种算法效果最优。
算法f(x)会依赖根据历史数据训练到的模型，然而业务数据的特征复杂，不断变化，这意味着我们需要定期更新策略模型，以保证算法的效果。
算法f(x)对CPU资源的需求差异很大，有的算法计算量非常小，可能单个CPU核就可以运行数千个此类任务，而有的算法会引入RNN等深度学习算法，计算复杂度特别高，往往就需要独占某个CPU核。
最初我们落地这类AIOps算法时，整体的流程如上图所示：
策略工程师用Python或Matlab编写算法脚本，并在线下进行Case回溯，保证算法的普适性。
研发工程师将算法脚本改写成线上代码（C++或Java），以便在线上运行。
测试工程师对改写后的算法代码进行测试回归。
运维工程师对模块（包括算法代码和策略模型）进行发布上线。
上面的研发流程暴露出很多的问题。一方面，对我们的研发工程师要求比较苛刻，既需要看得懂策略算法，又要熟知工程研发；另一方面，算法的迭代周期比较长，经常以月为单位，可能算法刚上线，数据特征就发生了变化，导致算法失效；最后，即使算法程序迭代稳定了，但是参数模型还需要定期更新，由于参数模型和算法程序没有分离，导致后期参数模型的更新需要不断上线，提高了维护成本。
我们再来看下报警管理的挑战。报警管理需要处理的需求比较多，我们以一个典型的运维场景来串一下这些需求：
凌晨一点，网络运维工程师对网络进行调整，导致网络产生了短时间的抖动，这类抖动的持续时间通常都在1到2分钟左右。网络抖动导致大量的业务监控指标发生相应的抖动，从而触发报警。此时业务运维工程师就希望系统能够提供防抖动过滤功能，避免指标在短时间抖动时触发报警。
但是，当值班工程师被及时唤醒并开始处理故障后，系统持续的重复提醒会对值班工程师形成很大的干扰。因此工程师们就希望引入报警认领功能，告知报警系统故障已经有人在处理，重复提醒可以停止了。
凌晨4点半，由于值班工程师是新入职的，对系统不够熟悉，日志清理的操作还未完成，导致故障持续。此时，就希望系统能够提供报警升级功能，在故障长时间未解除的时候可以通知资深的二线值班工程师介入处理。
凌晨4点50，二线值班工程师完成日志清理，故障恢复。这时，二线工程师发现日志清理操作其实是一套标准的止损操作，完全可以在发生报警时自动执行。因此希望系统能够提供报警回调功能，将来类似的问题就无需人工介入处理了。
除此之外，值班工程师可能还有断流检测、报警静默等等各种需求。
可见报警管理的需求复杂多样，如果我们不能抽象出一个可扩展的报警管理模型，我们将变得越来越被动。
看完报警管理，我们再来看下报警风暴的挑战。
为了避免遗漏故障，运维工程师常常会在监控系统中定制大量的监控指标和报警规则，从而建立起从网络到机器、从实例到模块、再到上层业务的立体化监控。立体化的监控虽然极大提高了故障发现的能力，但是很容易导致一个故障触发大量报警，造成报警风暴。
为了让大家认识报警风暴的真面目，我们来看三个典型的场景：
机器故障：机器发生故障时，监控机器健康度的报警规则将会产生报警；然后监控机器上实例运行状态的报警规则也会产生报警；最后这些实例的上游应用模块也会受到影响，相关的报警规则也会开始报警。这样一来，一个机器的故障就可能会产生几十条的报警消息。
应用模块故障：首先这个应用模块中的所有实例都会发出报警，紧接着上游应用模块也会产生报警。当应用模块中包含的实例比较多时，这类故障常常会产生数百条的报警消息。
机房故障：会同时造成网络、机器、域名、应用模块、业务等多层次、多方面的异常报警，产生的报警消息可以多达数万条。
本文首先介绍了百度Noah监控报警系统功能和业务模型，然后结合案例场景分析了我们在落地AIOps时遇到的问题，让大家对监控报警系统的现状有一个直观的认识。我们将在下篇文章中讲解如何来解决这些挑战，敬请期待。
温馨提示
如果你有任何问题欢迎留言咨询~
如果想试用我们的，请联系邮箱：[email protected]
↓↓↓ 点击"阅读原文" 【了解更多精彩内容】