grafana监控报警模板 监控告警_大数据

百度云Noah监控平台,承载着百度内外各类业务和服务的监控需求,它有着近十年的历史,现在已经承载了超过十亿量级的监控指标,并提供了机器监控、进程监控、日志监控、远程监控、自定义监控等多种监控方式。此外,它还具备集群级别的灵活配置和管理能力,并支持复杂的异常判断,提供多种途径的通告手段。

grafana监控报警模板 监控告警_人工智能_02

图1  Noah监控系统示意图

在系统架构层面,Noah监控主要包括数据采集、聚合计算、数据存储、异常检测、报警通告和可视化呈现六个主要部分,我们一般将异常检测和报警通告的组合称为报警通路。报警通路除负责异常判断、报警发送外,还支持报警回调和联动故障自愈机器人等功能。报警通路目前承载了千万级实例异常判断和报警,每天会自动执行上千次故障自愈任务。

本篇文章会分异常判断和报警发送两个部分来重点介绍报警通路的功能。

grafana监控报警模板 监控告警_百度_03

异常判断

grafana监控报警模板 监控告警_grafana监控报警模板_04

     判断规则      

异常判断是报警通路的核心能力,其支持的判断规则决定了监控报警能力的强大与否,Noah监控报警通路支持以下三类判断规则:

  • 内置的判断规则:该部分支持四则运算 、逻辑运算以及各种内置函数。例如:metric_a< 99.99% &&metric_b< 99.99% 、 abs(metric_c) > 100 等。
  • 自定义的判断规则:运维人员可先用系统支持的编程语言对异常判断规则进行编程,然后将代码提交到报警系统,报警系统负责执行该自定义程序,并产生报警。该部分适用于比较复杂的异常判断场景,比如复杂的同环比报警、多维度数据分析等场景。
  • 智能异常检测:对于通用判断规则和用户自定义都很难解决的复杂需求,Noah的智能运维策略团队,针对一些典型的监控场景,设计了几类智能异常检测算法,通过将算法融入报警通路,实现了无需配置规则的智能异常检测能力。

     异常判断流程      

grafana监控报警模板 监控告警_grafana监控报警模板_05

图2  异常判断流程

报警通路在接收到上游发送过来的监控数据后,首先找到跟数据相关联的报警配置,然后根据配置的判断规则进行异常判断,如满足判断规则,则产生报警;为了防止频繁的抖动报警,报警通路还支持各类过滤(防抖动)策略。例如,M个周期中有N个周期的数据被检测为异常才会产生一个报警。另外,报警通路还会将产生的报警事件存储到运维知识库,供业务、平台或用户来查询和使用。

     异常判断案例      

grafana监控报警模板 监控告警_人工智能_06

图3  异常判断案例

图3是一个异常判断的实际案例,为判断某业务在某机房的可用性指标是否达标,报警通路会对该指标的每个数据点逐一进行异常判断,如果连续3次都小于99.99%,则产生异常警报;反过来,只有连续3次都大于或等于99.99%,该次故障才会被判定为结束。

      异常的自动化处理方案      

异常判断产生的异常,如果只是用于报警发送,显然无法满足运维的完全自动化诉求,所以我们还支持了三种典型的自动化处理方案:

  1. 脚本回调功能:报警通路支持在异常实例或机器上执行某个脚本的能力。比如当检测到某个实例异常时,可以执行此实例上的脚本(如:重启实例),进而可以在无需人工参与的情况下自动修复异常的实例。
  2. HTTP回调功能:为了支持集群级别的故障处理能力,报警通路还支持HTTP回调功能。报警通路会将报警POST给指定的URL,接收端即可处理集群下的所有报警,以此来决定是否触发某个复杂的故障处理动作。
  3. 联动故障自愈机器人:产生的报警还可以联动故障自愈机器人,执行相关自愈动作。百度云Noah产品的故障自愈机器人基于感知、决策、执行三个阶段来实现,报警通路产生的报警恰恰可以作为故障自愈机器人感知环节的一部分输入,让故障自愈机器人通过综合分析监控报警、指标数据、运维事件等,产生最佳自愈决策方案并执行。相关介绍详见之前的公众号文章《智能运维 | 为何说自动化运维三大要素是标准化、工程化和智能化?》

grafana监控报警模板 监控告警_运维_07

报警通告

grafana监控报警模板 监控告警_grafana监控报警模板_04

grafana监控报警模板 监控告警_grafana监控报警模板_09

图4  报警发送流程图

由于异常判断产生的原始报警量很大且不易于阅读和理解,如果想通告给运维工程师,还需要经过一些处理环节。为了解决这个问题,我们会让异常判断所产生的原始报警,经历报警过滤、报警合并、报警渲染三个环节。

  • 报警过滤,会将运维工程师不希望收到的冗余警报过滤掉;
  • 报警合并,会将相关联的警报合并到一块发送;
  • 报警渲染,则是将结构化的警报数据渲染成文本和可视化信息,供运维工程师和研发工程师查看。

      报警过滤       

用户由于一些特殊原因(比如服务上下线等),希望在一些典型场景下,不再收到某些报警,针对这类需求,我们提供了三种深层次的报警过滤功能:

  1. 报警屏蔽过滤:运维工程师不希望接收预期内(比如模块上线期间)的报警,希望可以临时过滤掉相关报警。
  2. 报警依赖过滤:运维工程师希望只收到产生故障的根因报警(即精准报警),这样利于快速定位线上问题。比如某台机器出现故障(因)时,那么这台机器上所有实例的报警(果)应该过滤掉,只需给运维工程师发送机器故障的报警。
  3. 最大报警次数过滤:如果一个服务持续异常,运维工程师不希望持续收到同一故障的报警,可以限制最大报警次数。

      报警合并       

即使有上述报警过滤措施,但在较大规模故障发生时,仍然还可能产生大量的报警,造成报警风暴。因此,我们需要对同源的报警进行合并发送,一条信息中一般会包含多个相关联的警报。

        报警渲染         

合并后的报警,会按照默认格式渲染成短信、邮件、语音等,发送给运维工程师。此外,运维工程师也可以通过配置报警渲染模板,来自定义报警样式。

grafana监控报警模板 监控告警_grafana监控报警模板_10

总结

grafana监控报警模板 监控告警_grafana监控报警模板_04

本篇文章主要介绍了百度云Noah监控平台的报警系统,在报警规则、异常判断、报警自动化处理、报警过滤等方面做了详细解读。关于报警通路的实现细节和系统架构,会在后续的文章中介绍,敬请期待。欢迎感兴趣的同行一起交流和共建。

作者简介

运小伟    百度云高级研发工程师

负责百度云Noah监控平台报警系统的设计和研发,在大规模分布式系统、运维监控、精准报警等方面具有广泛的实践经验。

grafana监控报警模板 监控告警_人工智能_12