Argus（Noah 监控 3.0）是百度内部最大的监控平台，提供了机器监控、进程监控、日志监控、远程监控、自定义监控等多种监控方式。它还支持集群级别的监控配置和管理，并支持复杂的异常判断，提供多种途径的报警手段。
从系统架构层面，Argus 主要包括采集、汇聚计算、数据存储、报警通路和可视化五个主要部分。报警通路除负责异常判断、报警发送外，还支持报警回调和联动故障自愈机器人等功能。报警通路目前承载了千万级实例异常判断和报警，每天会自动执行数百次故障自愈任务。本篇文章会重点分异常判断和报警发送两部分来介绍报警通路的功能。
异常判断
判断规则
异常判断是报警通路的核心部分，其支持的判断规则决定了监控报警能力的强大与否，Argus 报警通路支持以下两类判断规则：
-
内置的判断规则：该部分支持四则运算 、逻辑运算以及各种内置函数。例如：metric_a < 99.99% && metric_b < 99.99% 、 abs(metric_c) > 100 等 。
-
自定义的判断规则：运维人员可先用脚本编写异常判断规则，然后将脚本提交到报警通路，报警通路负责执行脚本并产生报警。该部分适用于比较复杂的异常判断场景，比如复杂的同环比报警、多维度数据分析等场景。
判断流程
报警通路在接收到上游发送过来的数据后，首先找到跟数据相关联的报警配置，然后根据配置的判断规则进行异常判断，如满足判断规则，则产生报警；为了防止频繁的抖动报警，报警通路还支持防抖动过滤策略，例如，M 个周期中有 N 个周期的数据被检测为异常才会产生一个报警。另外，报警通路还会将产生的报警事件存储到运维知识库，供业务平台或用户来查询和使用。
异常判断例子
图 3 是一个异常判断的例子，为判断某业务在某机房的可用性指标是否达标，报警通路会对该指标的每个数据点逐一进行异常判断，如果连续 3 次都小于 99.99%，则产生异常警报；反过来，只有连续 3 次都大于或等于 99.99%，该次故障才会被判定为结束。
异常的自动化处理方案
异常判断产生的异常除了用于报警发送，还有下面三种自动化处理方案：
1. 脚本回调功能：报警通路支持在异常实例或机器上执行某个脚本的能力。比如当检测到某个实例异常时，可以执行此实例上的脚本（如：重启实例），就可以在无需人工参与的情况下自动修复异常的实例。
2.HTTP 回调功能：为了支持集群级别的故障处理能力，报警通路还支持 HTTP 回调功能。报警通路会将报警 POST 给指定的 URL，接收端即可处理集群下的所有报警，以此来决定是否触发某个复杂的故障处理动作。
3. 联动故障自愈机器人：产生的报警还可以联动故障自愈机器人，执行相关自愈动作。故障自愈机器人是一款面向感知、决策、执行的故障自愈机器人，相关介绍，详见之前的公众号文章《AIOps 时代，你准备好了吗？》。
报警发送
异常判断产生的警报，如果想到达运维工程师，还需要经过报警过滤、报警合并、报警渲染三个环节。报警过滤会将运维工程师不希望收到的冗余警报过滤掉。报警合并会将相关联的警报合并到一块发送。报警渲染就是将结构化的警报数据渲染成文本信息，供运维工程师查看。
报警过滤
用户希望在以下三个场景过滤掉报警，针对这三种需求，我们提供了相应的功能：
1. 报警屏蔽过滤：运维工程师不希望接收预期内（比如模块上线期间）的报警，希望可以临时过滤掉相关报警。
2. 报警依赖过滤：运维工程师希望只收到产生故障的根因报警（即精准报警），这样利于快速定位线上问题。比如某台机器出现故障（因）时，那么这台机器上所有实例的报警（果）应该过滤掉，只需给运维工程师发送机器故障的报警。
3. 最大报警次数过滤：如果一个服务持续异常，运维工程师不希望持续收到同一故障的报警，可以限制最大报警次数。
报警合并
即使有上述报警过滤措施，但在较大规模故障发生时，仍然还可能产生大量的报警，造成报警风暴。因此，我们需要对同源的报警进行合并发送，一条信息中一般会包含多个相关联的警报。报警合并的细节详见本公众号之前的文章《我在百度对抗报警风暴（一）》。
报警渲染
合并后的报警，会按照默认格式渲染成短信、邮件、语音等，发送给运维工程师。此外，运维工程师也可以通过配置报警渲染模板，来自定义报警样式。
总结
本篇文章主要介绍了百度监控平台报警通路子系统的核心功能，在报警规则、异常判断、警报自动化处理、报警过滤等方面做了详细介绍。关于报警通路的实现细节和系统架构，会在后续的文章中介绍，敬请期待。
作者介绍：
运小伟，百度高级研发工程师，负责百度监控平台报警子系统的设计和研发，在大规模分布式系统、运维监控、精准报警等方面具有广泛的实践经验。
本文转载自公众号 AIOps 智能运维（ID：AI_Ops）。
原文链接：
评论