AIOps对监控报警架构的挑战
作者简介
周伟 百度高级研发工程师
担任百度智能运维团队负责人（Noah），主要负责监控与告警系统以及发布通知的平台建设工作；在精准报警、精准通告、报警收敛以及公/私有云监控等领域积累了丰富的实践经验。
干货概览
在故障排查过程中，监控与报警系统扮演着不可或缺的角色。这也是为什么百度在其AI运维（AIOps）领域占据重要地位的原因之一。目前，在监控与报警系统的应用中，百度已在以下两大领域取得了显著成效：一是通过智能化的异常检测技术提升预警效率；二是将异常检测与报警功能实现了高度融合。
支持 AIOps 算法在监控报警系统上的迅速推进实施及其带来的实际效益；本文针对该架构面临巨大的挑战进行了深入探讨。
百度Noah监控报警系统
下面我们将阐述Google的标准故障排查程序，并参考如图所示的内容进行说明。该流程主要包含以下七个步骤：
问题出现：例如，在内网机房的核心交换机出现问题时。会导致网络中断，并进而影响到整个产品线的数据传输效率
-
故障发现 ：监控系统实时检测到产品线的流量异常。
-
故障通告：监控系统将通过短信、电话或其他通讯手段向业务运维团队发送告警信息，并报告产品线流量出现异常情况。
-
故障止损 ：运维团队会按照既定方案进行应对；在具备条件时可依托智能化平台辅助实现；主要操作包括将网络流量转移至非受损区域；此策略旨在迅速完成切换过程以保障服务稳定运行
-
故障定位 ：运维人员和研发人员一起定位故障根因。
-
故障恢复 ：在定位到问题之后，运维团队启动修复流程，在确保不造成进一步影响的前提下逐步解决系统故障直至线上所有服务（包括未处理流量的部分）均恢复正常状态。
运维团队会对故障排查与处理工作进行深入分析，并针对优点继续保留并优化缺点列入计划改进
在整个处理故障流程中, 监控机制主要承担从故障 detection 到定位的全过程；而报警装置作为这一机制的重要组成部分, 则专门承担故障 detection 和告警通知的任务
百度Noah预警系统最初服务于百度内部监控平台，并提供从机器设备、实例运行到上层业务应用等全面多层次的监控预警功能，在目前服务百度所有业务线。然而该系统面临着严峻的挑战，在每秒需处理千万量级的数据点基础上，线上监控配置已经达到百万量级规模，并每天会产生千万级别的报警事件，在如此庞大的数据量下仍需确保秒时的响应速度。
百度Noah报警系统不仅服务于内部用户，在公有云与私有云领域也提供了监控与报警功能。我们把内部强大的监控产品与运维理念分享给行业界内，并推出NoahEE产品（详见《百度云企业级运维平台——NoahEE》）。通过这一平台助力客户提升运维效能与系统稳定性。另外，在依托报警系统的前提下衍生出百度AIOps智能运维产品 ，集成了智能异常检测、故障定位及多警报融合等功能，并已成功应用于金融、交通及互联网等行业领域，并获得了客户的高度评价。
业务模型
监控报警系统的首要任务是实现精确识别异常事件。那么该系统采用什么流程来进行异常事件检测与警报发出呢？我们可以通过模拟演示的方式直观理解这一过程。
基于上图所示的图形, 该产品线的流量指标被定义为PV. 每一个数据点都对应一个PV数值. 预期当PV数值低于100时, 异常判断结果将被标记为异常状态, 并向运维团队发出警报通知.
监控报警系统会定期对当前的数据点（Data）进行评估。若PV值低于100，则判定结果为异常状态；反之则判定结果为正常状态。首次出现异常情况时（即从正常状态转变为异常状态），系统将触发并生成一个对应的警报事件（Event）。当警报状态恢复正常后，则会终止该警报事件的处理流程。在警报事件持续运行期间，默认情况下会按照相关规则产生零个或多个警报信息（Message），并将其转换为易于理解的文字描述内容并通过短信、电话等多种形式发送给运维工程师。整个流程下来实现了故障检测与故障通知的目标
相应地，我们将监控报警系统拆分成以下三个子系统：
该系统的主要作用在于依据预先设置的规则对数据进行定时分析，并将得出的结果（正常状态或异常状态）传递给下一层。该系统不仅要支持基于基本算术运算的传统型异常检测方法，还需结合AI操作平台（AIOps）实现更为智能的异常识别。
- 事件管理系统 ：主要承担对报警事件进行管理的任务，并根据报警事件提供防抖动过滤功能、实现报警认领、建立逐级通知机制以及配置静默响应模式等功能。
通告发布与发送系统
将监控报警系统拆分成三个子系统后，有以下两个好处：
- 系统功能边界清晰，具备可扩展的报警架构能力
每个子系统可根据其功能特性选择不同的技术架构及开发框架，并由专门的开发人员分别负责设计与运维。例如异常检测模块更适合计算密集型任务，则可优先选用Go语言或C++等性能优化能力强的技术框架；反之事件处理与报警发布模块更适合业务流程相关的事务处理，则可考虑使用Java语言或PHP等适合团队协作与快速开发的技术框架
每个子系统均具备独立升级的功能架构。例如异常处理模块因涉及大量计算资源而较为适宜采用集群式架构设计，在这种情况下横向扩展能力将得到显著提升。而数据流传输模块由于其流量相对较小，在初期阶段可采用主从架构设计方案。这种架构设计既保证了系统的简单性与可靠性又降低了研发及维护成本。当业务规模进一步扩大并需求提升至更高的报警处理强度时，则可以通过保持对外接口不变的方式独立将其自身架构升级为集群式结构从而实现更大的吞吐量水平
- 报警功能组件化，具备灵活的商业化交付能力
每个子系统都构成独立的功能模块，并且各自能够分别部署和更新,从而实现了灵活支持商业化交付的能力.例如我们可以将通告发送系统独立提供给商业化客户,并让他们通过接口访问即可实现报警合并.渲染以及发送功能.
我们遇到了哪些挑战？
基于上述业务模型的介绍, 我们对监控报警系统已经有了全面的理解. 接下来深入探讨实施AIOps过程中可能遇到的问题.
1
落地AIOps算法周期长，迭代成本高
进一步观察PV指标的表现。通过分析历史PV数据的趋势，我们发现不同时间段的PV数值呈现波动特征。例如，在凌晨三四点钟时流量处于低谷期，在早上八九点则是高峰期。另外，在工作日与休息日之间的PV数值表现也存在差异。这表明我们需要根据不同的时段特征来设定相应的检测标准。那么该怎么办呢？
百度策略人员开发了基于鲁棒回归的无监督异常流量检测算法 ，该算法无需设定PV阈值即可实现流量变化监测功能。下文将展示该算法的具体步骤推导过程：其中变量y代表真实的PV值（即真实访问点数值），f(x)表示通过特定预测模型得出的PV预测值（即预测访问点数值）。如需深入理解算法细节，请参考文章：《我们不一样！》
这类异常检测算法相对于传统的四则运算，有以下不同：
- 不同类型的指标在不同的情况下表现出也不尽相同，在探索阶段尤其需要注意的是，在初期探索阶段需要迅速实现并验证各种候选算法。
算法f(x)会基于历史数据训练得到的模型进行运行；但由于业务场景的特征复杂且不断变化的影响因素较多,因此我们必须采取相应的措施来定期更新策略模型,这有助于提升算法的效果
该算法在CPU资源利用方面存在显著差异：一方面能够处理数量众多的一类任务（如几千个），另一方面则采用了深度学习技术如RNN等方法来提升性能；其中一些算法由于计算复杂度极高而需要独自占用一个CPU核心。
最初我们落地这类AIOps算法时，整体的流程如上图所示：
策略工程师基于Python或Matlab平台开发算法脚本，并对实际案例进行回溯分析以确保算法在不同场景下的适用性。
-
研发工程师将算法脚本改写成线上代码（C++或Java），以便在线上运行。
-
测试工程师对改写后的算法代码进行测试回归。
-
运维工程师对模块（包括算法代码和策略模型）进行发布上线。
研发过程中暴露出了诸多问题。首先，在对我们的研发工程师提出较高水平要求的同时,他们不仅需要具备深入理解策略算法的能力,还需熟悉工程开发的基础知识;其次,算法的迭代周期较长,通常以月为单位进行更新,这可能导致在算法正式投入运行时,数据特征已经发生变化从而影响算法效果;最后,即便算法与程序达到了稳定状态,参数模型仍需持续进行优化更新,由于参数模型与算法程序未能实现完全分离,因此在实际应用中往往需要频繁地将优化后的参数重新部署至系统中,从而增加了维护成本。
2
报警管理需求繁杂多样，疲于应付
我们来深入分析报警管理的难点。报警管理涉及的任务繁多，请问您能具体说明这些任务：
午夜时分，在执行必要的网络调整工作后出现了短暂的波动现象。此次网络调整操作引发了短暂的波动现象（即所谓的"网络抖动"），其持续时间通常维持在1至2分钟的时间长度内。这种波动会引起大量业务监控指标随之短暂波动（即所谓的"业务监控指标抖动"），从而引发报警机制的触发（即所谓的"触发报警"）。在这种情况下,业务运维团队希望能够实现对此类短暂波动的有效过滤处理功能（即所谓的"防抖动过滤功能"）,以避免因短时间内出现波动而造成不必要的报警情况发生。
午夜时分，在自动日志清理程序出现运行异常的情况下，“因系统自动日志清理程序运行异常”使得集群中约60%的服务器磁盘空间已达到警戒水平，“然而当值机工程师未接通紧急电话时”。基于此需求，“值机工程师建议应增加‘紧急呼叫重复提醒’这一功能模块”。
然而，在值班工程师被及时唤醒并着手处理故障之后，系统的持续重复提醒会对值班工程师的工作效率造成显著影响。因此工程技术人员希望引入报警认领功能 以便让系统知道故障已经有人在处理，并取消继续发出的重复警报
午夜两点左右，由于值班工程师是新入职的，对系统不够熟悉的原因导致日志清理操作尚未完成，使得故障状态持续未被解除。此时希望能够提升告警等级，在故障长时间未解除的情况下建议由资深二线值班工程师介入处理。
-
凌晨四点半时,二线值班工程师完成了日常运维记录的整理与故障排查工作. 此时发现, "日志清理"其实是一套规范的标准程序, 在触发报警时会立即执行. 因此建议系统内置报警回控功能模块(报警回控功能), 以后类似情况将无需人工干预处理.
- 除此之外，值班工程师可能还有断流检测、报警静默等等各种需求。
面临的报警管理需求错综复杂。如果我们在能力上不不具备构建一个可扩展的报警管理系统的能力，则将会处于越来越被动的状态。
3
报警风暴淹没核心报警，束手无策
看完报警管理，我们再来看下报警风暴的挑战。
为防止漏网之鱼，在日常运维工作中运维工程师习惯性地在监控系统中构建丰富的监控指标体系与告警规则集合，并通过自动化手段实现对关键节点的持续监测与预警响应。这种全面的监测架构在提升异常事件探测能力方面发挥了显著作用，在保障系统稳定运行的同时也能有效降低潜在风险敞口。然而这种架构容易导致单一故障事件引发大量不必要的告警信息，在实际应用中可能导致资源过度消耗并影响正常业务运转效率。
为了让大家认识报警风暴的真面目，我们来看三个典型的场景：
当机器故障发生时，在线监控系统将执行以下操作：首先启动用于检测和报告设备健康状态的关键指标监控；随后系统将自动触发针对具体运行状态的不同类型警报；此外这些关键业务服务上的异常情况还可能影响到相关业务模块甚至其上层服务导致多个级别的警报信息被及时触发从而在单一设备出现故障可能导致几十条甚至上百条不同的警报信息被发送出去
该应用模块中的所有实例均会触发报警信号，并伴随其上游应用模块同步释放 corresponding 的警报信息。当该应用模块包含大量实例时，则会导致数百条的警报信息被同时触发
机房故障：将导致网络中断、硬件损坏以及相关域名服务失效等问题，并引发并发送各类异常报警信息（如系统崩溃或数据丢失），这些信息可能总数达到数十 thousands条。
从我们的观察来看，在日常工作中值班工程师普遍感到这三种典型故障十分令人不快。他们常常会因为频繁收到短信和电话而感到十分不便；与此同时大量报警消息却未能有效帮助值班工程师快速定位问题并制定止损策略。为了更好地应对这些情况我们需要为值班工程师提供更加高效的信息处理机制以减少工作压力并提高工作效率。
总 结
本文主要阐述了百度Noah监控报警系统的功能与架构。接着通过实际案例分析发现，在推进AI运维（AIOps）过程中出现了诸多问题。这些发现有助于读者更好地理解该系统的运行机制。期待读者关注后续文章的发布内容。
温馨提示
如果你喜欢本文，请分享到朋友圈，想要获得更多信息，请关注我们！
如果你有任何问题欢迎留言咨询~
如果想体验我们的企业级运维平台NoahEE，请通过邮箱联系：noah_bd@baidu.com
RECOMMEND
推荐阅读
《掌握黄金指标异常检测的方法：只需3分钟》
[
《前端技术实践——网页加载优化》
《前端技术实践——网页加载优化》
[
[《微服务之监控初探》](http://mp.weixin.qq.com/s?__biz=MzUyMzA3MTYxNA�&chksm=f9c37e5 geDBIqgZvKoQGwPFWFjYqgWzsVXQrTvhSfiuJkCnXQhSsxEjYHtuEzwNTEZuMQ#wechat_redirect)
[
↓↓↓ 点击"阅读原文" 【了解更多精彩内容】