在上一次的直播中，我们介绍了监控体系：可观测指标管理体系建设落地及插件功能设计和生态打造。本次主要和大家分享可观测领域内，告警事件管理系统的设计思路与落地实践。

扫码查看直播回放

（关注公众号获取 PTT 免费下载链接）

企业告警管理面临的挑战

在数字化转型过程中，很多企业已经建设了多套的监控系统，覆盖服务器、网络、存储、日志等等。但有了监控却并不能高枕无忧，在我们服务的多个企业中，监控系统检测并触发告警后，在告警事件管理过程中，各人员角色普遍存在一些亟待解决的痛点问题。

如下表是比较典型的中各角色的痛点和期望：

通过广泛地调研收集客户的告警管理现状和诉求，我们归纳总结了在企业在达成高效的告警管理的目标时，所面临的通用问题：

告警散落不标准。各类告警散落在相互隔离的多个监控系统中，没有统一的内容格式规范，信息不全面，可读性很低，无法直观进行告警判断；

告警噪音多。各类监控系统设置的固定阈值标准不一，或者同一故障引发不同系统同时告警，造成大量的误报、漏报和重复告警；

没有全局视图。出现告警后，无法直观了解应用系统和对象模型的告警整体情况和关联影响范围；

缺乏工具联动。告警处理人工干预过多，自动处理少，告警流转效率低；过程缺少追踪，处理经验难沉淀。

基于这些挑战诉求，我们去设计打造了优秀的告警管理系统，落地企业管理实践中，切实解决问题。

产品设计：贯穿告警事件全生命周期管理

告警管理系统，应以事件为中心，从将各监控系统的告警集中接入开始，通过插件清洗和告警丰富完成接入告警的标准化、再通过去重、防抖、关联聚合、屏蔽等多种降噪方式分析、处理四个层面进行建设，外部联动 CMDB 进行告警信息的丰富；联动工单系统，实现告警驱动工单推进事件管理；联动自动化工具，实现告警自愈处理降低业务损失。

实现从告警产生-接入-丰富-降噪-自动处理（分派+转工单/自愈）全生命周期闭环管理，快速对故障进行有效处置，保障业务稳定运行。

建设落地实践

明确了以事件为中心进行告警的全生命周期管理这一思路后，我们将具体落地实施分为了规划设计、告警接入和标准化、告警压缩降噪、告警通知和处理、告警管理运营改进，一共 5 个步骤。以最终实现“快速响应和解决故障，提升无故障间隔时间，减少故障发生率和业务影响范围”这一告警管理的根本目标。

1、规划设计

规划设计以“事件”和“数据”双核驱动，规划设计告警管理体系；整合现有监控工具，统一告警策略标准和统一告警接入。

一般来说，大约有如下几点需要考虑：

● 告警全量汇聚：归总企业所用的各类监控系统，制定统一结构、高可读性的告警信息格式，让各系统中内容格式各异的告警全量集中，解放运维人员追踪维护多个系统的麻烦，统一通过一个告警管理系统来查看和管理告警事件。

● 告警压缩降噪：梳理各运维工程师常见的“无效告警”如重复告警、维护期告警、相同负责人的关联告警、抖动指标告警（毛刺告警）等，对应制定合理的告警降噪策略，帮助运维人员在有限的时间范围内快速、精准地筛选出所有的，真正需要关注或人工处理的告警。

● 精准有序分派：通过收敛策略、分派规则，将降噪后的有效告警事件，通过各类通知渠道，精准通知给指定运维人员，通过重复通知或升级通知保障通知不遗漏、并记录每个用户的 MTTA、MTTR，进行人员考核，持续运营改进。

● 告警驱动工单：与工单系统集成，按需实现告警自动/手动转工单，如关键业务、致命监控告警等处理过程复杂、或恢复操作风险较高的告警全开单。

● 告警自愈处理：联动自动化运维系统，通过自动化处理设置，实现告警触发自愈任务执行，迅速处理故障，降低业务影响。主要用于有固定恢复操作、且恢复操作风险低的告警，如清理磁盘空间、服务异常自动重启等。

（告警管理效果蓝图）

2、告警接入和标准化

由于不同监控系统的告警，内容格式、告警等级、唯一性标识等各有特色，不利于后续设置统一的降噪策略和分析处理。所以在将多套监控系统的告警进行统一接入时，可以基于告警信息标准化的要求和场景消费，通过插件开发、多层级的清洗和丰富，统一接入各监控系统告警数据，并得到标准化格式的告警信息，为后续统一管理、数据消费打好基础。

插件式告警接入

嘉为鲸眼告警中心，在持续积累对常见监控系统开箱即用对接能力的同时，开放了以 python 脚本形式的开发独立插件的能力，用户可以在不影响线上系统稳定的情况下，便捷的对接更多的第三方告警源（即监控系统），企业运维人员可逐步转型运维开发，只需具备简单的脚本开发基础，即可具备持续拓展能力，以应对未来的业务发展引入新的监控系统后的对接需求。

常规接入格式示例：

告警结构标准定义：告警信息、对象信息、其他扩展信息

• 告警信息：告警内置的字段，包括告警事件 ID、告警等级、告警时间等；

• 对象信息：用于标识告警对象本身，包括告警对象、业务信息等；

• 其他信息：告警扩展的一些字段，支撑一些特殊场景的数据消费。

告警等级定义：致命、警告、提醒

• 致命：一般代表服务已经异常，需要马上进行处理；

• 警告：一般代表如果不进行及时处理，服务即将异常；

• 提醒：一般代表一些潜在问题，需要开始关注或提前采取行动，避免异常产生。

告警事件 ID 的定义：去重字段，用于识别是否同一告警事件

• 部分告警源可提供原生的告警事件 ID；

• 部分告警源采用告警源 ID+原始告警 ID 拼接组合方式；

• 部分告警源采用告警对象+告警指标+告警级别组合方式，自动加密生成唯一的告警事件 ID。

(企业告警标准化格式参考示例)

告警信息丰富

汇聚不同监控系统的告警后，运维人员通常会发现不同监控系统、不同类型的告警信息差别很大。有些告警信息比较简陋，只有诸如：ip 地址、某指标过高等信息。

而告警丰富功能，可以通过界面化配置，通过和 CMDB（配置管理数据库）的关联，高效消费用户维护在 CMDB 中的实例配置信息，关联关系等；还可以对告警信息完成轻量化的二次清洗，免除频繁修改插件文件的工作量，便捷地实现告警事件内容、格式的统一。

告警丰富在提升告警可读性的同时，能够提供告警治理的抓手，便于完成后续更灵活的告警筛选和更简便的策略配置，有效提升分析和处理故障的效率。

以下是告警丰富功能的落地实践分享：

CMDB 丰富

通过联动 CMDB 配置数据，可视化更新和扩展告警字段，比如某些监控系统在告警对象中只有 IP 地址，没有主机名，可以通过 CMDB 丰富把主机名等告警对应的主体，各项配置信息（实例的属性信息）自动添加到告警中，让用户一目了然的看到所有需要的信息。

下图为典型示例，当主机发生告警时，将主机的各项配置信息显示在告警内。

当然，配置告警字段和 CMDB 实例属性信息的映射规则，生效的前提是告警可以找到唯一的实例。对于没有和 CMDB 关联的第三方监控系统，可以通过配置 CMDB 关联规则来实现：例如根据告警字段和 CMDB 则能够根据告警内容中正则提取的 IP 地址和 CMDB 中的内网 IP 属性值进行比对，以准确找到唯一对应的实例，从而实现后续的字段信息丰富。

实际效果如下所示：

(丰富前的告警事件)

(丰富后的告警事件)

常规丰富

通过字符替换、字符提取、字段调整等方式，以页面配置的方式，对告警信息进行标准化清洗，同时运维人员可以自定义上述方案的生效规则和应用范围，从而快速实现对需要处理的部分告警信息的丰富。

字符替换：当相同事务在不同系统间名称不同时，如有些系统是中文：主机、数据库，有些是英文：host、DB、database；还有些是名称不规范，如 mysql、MYSQL 等。可以通过字符替换功能，对每个告警源的告警配置翻译替换规则，便于运维人员理解。

字符提取：有些系统的告警将指标当前的具体值写入一个独立的拓展字段内，而另一些系统的告警，只能从告警内容字段中找到指标具体值，如 zabbix 的告警，告警内容的尾部 the value is 之后就是监控指标的当前值。

通过字符提取功能，灵活运用正则表达式，将指标的当前值从告警内容中拆分出来，进一步实现指标规范，让所有系统的告警，都将指标具体值单独显示为一个字段。

字段调整：对于一些监控系统定义了很多拓展字段，而用户使用过程中，想要将这些字段合并为一个，更便于去查看，也可以通过字段的调整功能实现。

例如某系统的告警，将主机所在位置，分城市、机房、机柜三个字段显示，通过字段调整，将三个字段合并为机器位置这一个字段。

3、告警压缩降噪

随着业务发展，IT 架构的复杂化，运维工作难度攀升，一大亟待解决的问题是：告警噪音过多。

一线团队可能每天都会收到几千封告警通知风暴，但精力范围内可处理的数量却远远不及。疲于应对的同时，无法从汪洋大海一般的告警中甄别出真正重要的内容，不能及时发现故障前兆，而当致命故障发生时，处理难度会更大，也对业务服务和终端用户造成更大范围的影响。

我们需要通过合理高效的告警降噪方式，帮助运维人员在有限的时间范围内快速、智能地筛选、定位出真正需要关注或人工处理的告警，以点带面，大幅降低故障影响范围，更好的感知到当前需要处理的告警全貌，维护业务的稳定。

嘉为鲸眼告警中心，提供时间屏蔽、自动去重、关联聚合、防抖机制、依赖屏蔽 5 种告警压缩降噪能力：

时间屏蔽

在系统变更、跑批等维护期间，因系统、设备的异常态而必然引发的告警，可以通过告警屏蔽，实现对指定时间窗口内可预知的无效告警进行收敛——不会分派通知，也不出现在需要处理的活动告警列表中。

自动去重

当一条告警还处于处理中未结束的状态（下文中称此类告警为“活动告警”），后续接入的重复告警，会被内置自动去重方案，自动收敛掉。此处的重复告警的定义，取决于在接入告警环节告警事件的唯一性方案。相同告警事件 ID 的告警，被视为重复告警。

收敛同时累加活动告警的“告警计数”，并将被收敛的告警和对应的活动告警进行关联。

(在活动告警详情查看关联的被抑制告警)

关联聚合

将某个时间窗口内，指定的一个或多个告警字段完全相同的多条告警聚合，让这些相同维度或者相同负责人的告警，只分派通知一次，减少对运维人员的打扰，又可以便捷的查看所有聚合的告警。

例如配置将主机产生的告警，在设定的 10 分钟时间窗口内，有着相同的“告警指标、CMDB 业务、主要维护人”的多条告警收敛为一条。

这也可以视为一种更灵活的去重策略，能有效解决内置自动去重策略所未涉及的一些场景，如：来自同一个监控系统的不同类型/不同负责人告警，告警事件唯一性方案有区别，需要灵活的设定；用户希望超过一定时间段后，再此生成一条新的活动告警，而非全部抑制等。

告警防抖

某些监控系统不具备防抖检测机制，经常出现一些指标值突升突降，引发很多迅速恢复的告警，这使得运维人员收到大量告警后来不及查看又恢复了。

在实际的业务场景中，虽然这些指标设定的阈值是合理的，超过阈值需要告警，但用户希望仅当指标值连续几个检测周期，持续高于阈值再发出告警通知。

那么对于这些抖动类指标（如 CPU 使用率、网卡流量、内存使用率、磁盘 IO 等）产生的告警，可以设定一些防抖的规则。如 5 分钟内产生 3 次告警，第 3 次才会成为有效告警进行分派通知，未达标的偶发告警即被抑制。

依赖告警收敛

对于有依赖关系影响而导致的关联告警事件，如组件安装/运行于主机、各设备通过交换机连通网络、主机磁盘挂载了存储提供的存储盘、虚拟机运行于宿主机或宿主机集群上等，通过配置依赖关联规则，按照告警之间的依赖关系，将依赖告警进行收敛。

根据目前的落地实践，通过以上五种降噪方案的配置，企业一般能够有效收敛 60%~80%的告警量。

4、告警通知和处理

产生有效告警后，就需要尽快分派给负责的运维人员进行处理。我们通过集成多种通知渠道，实现随时随地响应和处理告警；通过集成 ITSM 事件管理流程、自动化运维系统，实现告警转工单、告警自愈。

告警通知

多渠道适配：需要适配多种通知渠道，方便运维人员随时响应，除了常规的邮件、短信、电话等，还需要包括企微、钉钉等现在常用即时通讯工具。

移动端集成：集成移动端，提升运维服务响应速度，随时随地查看和处理告警。

告警分派：与 CMDB 的配置负责人联动，动态分派，通过较少的配置即可实现告警责任到人。

告警升级：重要告警未相应处理时，重复通知和分派升级到上级经理。

告警处理

联动 ITSM，实现告警转工单

对于关键业务、致命监控告警需要二线专家介入的复杂告警处理，可以通过工单系统流转给对应的专家小组进行处理，并留下完整的处理记录。当告警无法匹配分派给到对应的专家小组时，会流转到服务台进行手动分派给对应人员处理。

（告警关联 ITSM 实现自动派单）

（告警事件管理流程）

联动自动化运维，实现告警自愈

对于常见的告警，有固化处理流程的场景，可配置告警自愈策略，比如进程端口异常、僵尸进程数过多等。通过配置规则、时间段的方式，在非工作时间（尤其凌晨），针对部分场景实现故障自愈，无须人工干预。

示例：

2020-08-27 00:12:37 10.10.10.xx xx 服务器进程端口 down，触发故障自愈

2022-11-14 00:00:02 10.10.10.xx xx 系统僵尸进程数超过阈值，触发故障自愈

告警分析辅助问题定位

告警详情：从基础信息、拓扑分析、关联告警、指标信息、流转记录五个层面，全面完整的展示一条告警，供用户分析。

关联分析：与蓝鲸 CMDB 联动，支持从告警视角、对象视角、业务视角查看关联关系，快速定位问题和影响范围。

故障现场：与自动化运维联动，根据规则自动抓取故障现场的关键信息，比如服务器性能快照、堆栈信息、dump 信息等，协助开发和运维人员事后快速定位故障根本原因。

5、告警管理与改进运营

常见的告警管理问题、原因分析和对应策略如下图：

经过系统的数据沉淀，我们可以统计告警分布情况、告警处理的 MTTA 和 MTTR、告警转工单数、告警关单率等运营度量指标，进行告警运营分析，持续优化告警策略和管理流程。

告警治理是一个持续治理和优化的过程，应对架构调整或者运行事件暴露出的问题项，需要不断优化配置监控项和告警策略，提高告警的及时性、有效性，减少误告漏告，实现告警全生命周期的统一闭环管理，释放人力提升效率，更好地保障业务稳定性！

（告警治理过程）

查看直播回放或免费下载 PPT，关注公众号：嘉为蓝鲸。