本文主要讲解作为运维人员，为什么需要构建统一的告警平台以及如何构建一套符合企业场景的告警平台，并结合作者的实践给出一些建议。

01为什么需要

消息推送

随着企业的发展，推送各种告警和消息变得不可或缺。这些包括来自基础监控系统（如Zabbix和Prometheus等）的告警信息，来自日志监控（如ELK）的告警，来自APM的监控告警，以及来自各个业务的告警需求等等。为了避免重复工作，平台需要提供告警接收人的配置管理功能，并支持多种推送渠道。

如果每个平台都去实现一套告警发送逻辑，对于企业来说是存在不必要的重复工作，比如企业微信、钉钉、邮件、短信、电话等这些通用的推送方式。

收敛

这个功能是告警平台中最重要和核心的部分。在企业日常运营中，通常会接收到各种各样的告警。有时候，由于主机故障或网络故障，可能会出现大量的告警，这就是所谓的告警风暴。如果没有降噪收敛功能，重要的告警可能会被淹没，无法及时发现和处理，从而导致更严重的后果。此外，频繁出现的无效告警容易让用户感到疲劳，导致忽略真正重要的告警。因此，告警收敛这个功能对于告警非常关键。

响应与处理

告警事件进入到平台一般都需要进行处理、这个处理包括对事件发生后的及时确认、告警自愈、告警知识库等。

通过告警事件的确认可以认定处理人员的响应速度、告警事件恢复时确认MTTR，评估告警事件的影响；

告警自愈功能实现对特定的某些告警事件启动自动恢复调度功能，这通常是调用工单系统或者自动化系统或者简单脚本进行；

告警形成知识库则可以用于后期的告警的处理的参考，有助于提升告警处理的速度和能力。

反馈

通过告警平台的建立，可以很明确处理人对各个事件的MTTA(平均故障诊断时间)、MTTR(平均故障恢复时间),通过这个可以反过来推动运维人员响应、处理故障的及时性，进而减少因故障带来的业务损失。

02 如何构建

构建一个告警平台，首先我们讲解整个告警平台的的流程，整个平台的大致流程为：接入-处理-指派-形成知识库。

告警接入

平台需要提供一个接入的功能，这个可以对各种需要对送到平台的告警源在平台上进行注册，提供标准的API接口，这样任何告警平台都可以非常方便的接入到平台中。为了更加方便的让其他人能够快速接入，应当给出一些常用的接入示例，如公司常用的开发语言接入的代码，这样方便业务接入；其次对公司内部一些常用的发送消息的平台做出明确的接入说明，比如zabbix、Prometheus等各种平台。

告警处理

这部分主要有告警事件数据清洗、告警处理规则、告警自愈几个模块。

1.数据清洗

在各个平台将数据发送到告警平台之前，数据的格式参数可能存在不统一的情况，或者包含一些已经无效的告警。因此，在告警进入告警平台的第一时间，应对这些数据进行清洗。例如，我们可以通过与CMDB进行关联来清洗告警数据，这样可以统一不同的标签，并且剔除一些无效的告警。

2.告警处理规则

一般告警处理主要包含静默、抑制、聚合规则，我们根据自己的使用场景增加了暂停、最大告警次数和最小时间间隔的策略。

静默是指在特定条件下临时关闭或禁止某个告警的通知，以避免对操作人员造成干扰。例如，在系统维护期间，可以选择将某些告警静默，以免干扰正在进行的维护工作。告警暂停是静默的一种特殊情况，用户在故障发生时立即处理，避免发送消息，并临时暂停告警的发送。

抑制是指在某些情况下，当一个告警触发时，系统会自动抑制或取消其他相关告警的触发，以避免产生大量重复的告警。例如，当一个服务器宕机时，系统可以自动抑制与该服务器相关的其他告警，以避免洪水般的告警通知。

告警聚合是将多个相关的告警合并为一个更高级别的告警，以帮助操作人员更好地理解和处理告警。例如，当多个服务器同时出现高负载时，系统可以将这些告警聚合为一个高负载告警，以便操作人员能够更好地识别和解决问题。聚合通常基于时间和字段两个维度进行定义。

最大告警次数限制了告警的发送次数，避免同一个告警无休止地发送。

最小时间间隔定义了告警的最大频率，避免告警风暴的发生。

3.告警自愈

这主要是指当发生告警时，系统能够自动采取一系列的措施来解决或修复问题，而无需人工干预的能力。为了提高系统的可靠性和稳定性，减少对操作人员的依赖和干预。

一般有脚本执行、生成工单、自动化等方式来进行自愈。

当然告警自愈也需要谨慎使用，因为自动化操作可能会带来意外的影响。因此，在实施告警自愈功能时，需要仔细考虑和测试各种情况，并确保系统能够正确地识别和处理各种故障和异常情况。

我们一般选择与ITSM或工单系统结合使用，可以更好地管理和跟踪问题，这样可以在自愈流程中选择是否加入人工确认的过程，从而提高告警自愈的可靠性和安全性。

指派

指派主要分两部分，一个是告警接收人的处理、另一个是告警渠道的集成。

1.接收人

告警接收人的处理我们分了两个方面：告警定制、告警升级。告警定制里面主要是定义告警的模板，告警的接收人、拒收人等。告警升级则是在告警未得到及时处理时升级到相关负责人等，将原本的低级别告警提升为更高级别的告警。

2.告警渠道

平台应该集成常用的通知方式，如微信、钉钉、飞书、短信、语音、邮件等等。对于更通用的平台，可以考虑加入webhook方式，以便接入像企业微信群这样的渠道，通知方式更加灵活多样。

知识库

告警知识库通常包含告警记录、处理方法、解决方法和经验教训等内容。通过建立和维护运维告警知识库，运维团队可以更快速、准确地响应和处理告警事件，提高故障处理效率，减少系统故障对业务的影响。然而，并不是说一定要在告警平台建立知识库。例如，我们公司选择在ITSM中建立告警知识库，通过告警自愈、生成事件工单与ITSM对接来完成。因此，建立知识库的位置可以根据公司的具体场景进行选择。

03总结

本文讲述了为什么我们需要建立告警平台以及如何建立它，还介绍了我们在实际中的一些实践经验。如果您认为整个建立过程比较繁琐，可以逐步实现。例如，可以先建立一个纯告警推送的平台，然后逐步添加告警规则处理、自愈功能、事件工单和知识库等步骤，以完善平台功能。