本文介绍ARMS告警管理如何应对大规模系统的告警配置。
背景知识
在告警管理中有一个非常重要的指标Mean Time To Contain（MTTC），MTTC描述了从检测到故障事件到控制和解决该事件所需的平均时间。它是一个关键指标，因为它衡量了一个组织对事件的响应能力和效率。较短的MTTC意味着组织能够快速识别并控制故障事件，减少潜在的损失和影响。
如下图所示，告警处理的飞轮中想要更短的故障时间就需要更短的故障发现时间和更快的响应速度，并且在每一次的告警处理过程中不断地对组织的处理机制进行复盘改进，从而提高告警的处理效率，缩短组织的MTTC。
大规模系统告警管理的痛点
复杂系统中，告警规则的配置会非常多且繁琐。如何保证告警规则的覆盖率，高效地配置告警规则？
在复杂的组织架构中，如何快速将告警发送到正确的处理人？
如何确保告警在需要人处理时，接手的时效性？
如何应对告警规则配置效率和精确指派的矛盾？
大规模系统通常在配置告警规则时告警规则的覆盖率和配置效率往往难以兼得。一个典型的告警规则通常包含如下字段：
字段名称 | 字段含义 |
告警名称 | 用于区分不同的告警规则，描述告警类型。 |
告警等级 | 用于指示告警的严重程度，通常包括严重、一般、轻微等多个等级。 |
告警对象 | 指明出现问题的组件或设备，例如服务器、数据库等。 |
监控指标 | 指示监控的具体指标，例如CPU使用率、内存使用率、网络流量等。 |
阈值 | 用于设定触发告警的阈值，例如CPU使用率超过80%、内存使用率超过90%，超过这个阈值就会触发告警。 |
告警方式 | 指示告警的通知方式，例如邮件、短信、微信等。 |
告警描述 | 用于描述告警的详细信息，例如问题发生的时间、持续时间、影响范围等。 |
告警处理方式 | 指示出现告警时的处理方式和责任人，例如由谁负责处理、处理时间要求等。 |
在配置这样一个告警时需要指定该告警的通知方式，通知人等信息。而在大规模系统下往往需要多个人和团队来处理各个系统中产生的不同告警。如下图所示是一个典型的垂直业务系统应该配置的告警信息，在这个垂直系统中不同层次的组件所产生的告警它的处理方式和处理人会完全不同。
当业务由多个垂直业务组成，并且部署在全球多个区域时，带来的告警规则配置复杂度= 垂直业务 * 依赖组件 * 部署区域 * 运维团队/人员 。 而由于人员的不稳定性还需要对这一份告警的配置进行动态调整，这对于告警规则的维护将是巨大的困难。
ARMS告警管理如何应对大规模系统的告警？
解耦告警配置与通知配置
与传统告警不同，ARMS告警将告警规则分成告警配置和通知配置。通过配置解耦，在配置告警规则时不再需要关心告警通知给谁，从而降低了告警配置的复杂度。
字段名称 | 字段含义 | |
告警配置（告警规则） | 告警名称 | 用于区分不同的告警规则，描述告警类型。 |
告警等级 | 用于指示告警的严重程度，通常包括严重、一般、轻微等多个等级。 | |
告警对象 | 指明出现问题的组件或设备，例如服务器、数据库等。 | |
监控指标 | 指示监控的具体指标，例如CPU使用率、内存使用率、网络流量等。 | |
阈值 | 用于设定触发告警的阈值，例如CPU使用率超过80%、内存使用率超过90%，超过这个阈值就会触发告警。 | |
通知配置（通知策略） | 告警方式 | 指示告警的通知方式，例如邮件、短信、微信等。 |
告警描述 | 用于描述告警的详细信息，例如问题发生的时间、持续时间、影响范围等。 | |
告警处理方式 | 指示出现告警时的处理方式和责任人，例如由谁负责处理、处理时间要求等。 |
在ARMS告警管理中，告警触发后会将告警事件发送到告警中心。通知规则（通知策略）会根据其中的事件匹配规则，在告警中心进行订阅。订阅到匹配的规则后再通过通知策略中的配置进行通知。提高了告警配置的灵活度。
标签+低代码模式告警富化
在告警解耦过程中最重要的实现方式是灵活的事件匹配规则。如订阅“业务=业务一&组件=组件一&等级=P1&指标=性能指标”这样一组条件，就需要每个告警事件上都包含业务、组件、等级、指标这几个标签。
在ARMS中采用半结构化的数据来描述一个告警事件，一个告警事件中所有的标签都可以用来配置通知策略的事件匹配规则（订阅规则）。
半结构化的告警事件数据结构
[
{
"labels": {
"alertname": "<requiredAlertName>",
"labelname": "<labelvalue>",
...
},
"annotations": {
"alertname": "<labelvalue>",
},
"startsAt": "<rfc3339>",
"endsAt": "<rfc3339>",
"generatorURL": "<generator_url>",
},
...
]labels（标签）：告警元数据，一组标签唯一标识一个事件，所有标签均相同的事件为同一个事件，重复上报会进行合并，例如“alertname: 告警名称 ”。
annotations（注释）：注释是告警事件的附加描述，注释不属于元数据。例如“message: 告警内容”。不同时间点发生的同一个事件，它们的标签是相同的，但是注释可以是不同的。比如告警内容的注释可能不同，例如“主机CPU使用率持续三分钟大于75%，当前值82%”。
startsAt（告警开始时间）：告警事件开始时间。
endsAt（告警结束时间）：告警事件结束时间。
generatorUrl（事件URL地址）：告警事件URL地址。
ARMS自身产生的告警规则可以通过自定义标签来给告警事件中添加各种业务所需的标签。针对于其他告警源产生的告警，则可以通过低代码模式的事件处理流来对告警事件进行标签富化，从而满足依靠标签进行订阅告警的灵活配置需求。