告警能力中台设计与实践（三）——告警通知

一、告警消息与告警通知

1、告警消息

正如笔者在最开始所写的那样，第三方服务通过调用能力中台的OpenAPI实现告警发起，并且每一次的告警请求都会创建、归档为一条告警消息（AlarmMsg）。

这样的消息是无状态的，并且对应的消息会外键关联到对应的告警原子事件（AlarmEvent）。

2、告警通知

当告警请求送达并处理后，如果满足告警实际发送条件（例如第一次或不在收敛周期内），此时中台会根据对应的告警策略执行告警通知动作，并根据通知类型的不同，生成

这样的通知同样是无状态的，并且会外键关联到对应的告警消息（AlarmMsg）。

3、基本关联关系

• 一次告警请求会生成一条AlarmMsg，其外键关联到AlarmEvent，但未必会生成AlarmRecord；
• 如果告警发送动作执行，可能会因为策略存在多个告警发送方法，生成多条AlarmRecord；
• AlarmRecord外键关联到AlarmMsg中；
  

二、告警通知方法

1、发送IM消息

（1）基本逻辑
对于企业而言，会使用工作IM软件来进行工作内容的沟通。这类IM软件大部分都会提供OpenAPI，以实现类似AI聊天机器人等功能。

因此，平台通过调用此类OpenAPI，实现了告警信息及时推送到相应的IM群组中。

（2）群组分层分级
对于服务的告警而言，本身就是有等级的，不同的等级划分关注度自然也是不同，这点在告警IM消息的发送上也是一样。

一般来说，对于特别紧急、生死攸关的问题，都会直接拉起Warroom群，这类告警肯定需要第一时间响应。
而很多提示、轻微的告警如果也发送到这样的Warroom群，肯定会引起不必要的紧张。

基于上述需求，笔者按照告警的阶段、等级，提供了灵活的群组配置方法：

• 根据环境阶段，笔者分成了ALPHA、BETA、GAMMA、PROD；
• 根据严重等级，笔者分成了提示、轻微、严重、致命；

综上，笔者一共提供了十六个配置的选择，服务可批量配置、也可以单个自主调节群号。

2、提工单

（1）基本逻辑
工单也是企业对于问题处理的必要手段，可以规范的进行提交、接受、处理和闭环。

该部分总体逻辑比较简单直接：

• 调用工单平台提供的OpenAPI生成对应工单；
  • 工单的责任人笔者直接使用工单平台OnCall；
• 定义定时任务、自动同步工单平台的对应工单状态；

3、打电话 / 发短信

（1）基本逻辑
打电话与发短信本质上都是通过电话号码实现的消息通知。通知内容会进行一定的自然语言处理，方便接收者能够快随了解问题所在。

具体打电话/发短息的方法也很简单，同样是使用了公司层级的电话通知服务所提供的OpenAPI。

（2）OnCall机制
对于应该通知给谁，这一点很重要，毕竟人也不可能是连轴转的，OnCall也是人，需要轮换。

因此，笔者提供了OnCall的配置机制，除了保底的SRE作为OnCall外，还会提供对应的班次、周期等，提供批量配置、导入导出等手段，方便快速配置电话短信接收人。

三、总体告警相关问题

1、告警请求高并发与性能问题

随着第三方告警请求接入数量越来越多，平台处理请求、发起告警的压力也会越来越多大，性能风险也越来越高。
针对这个问题，笔者主要提出了以下几个解决办法：

• 确保告警接口访问可控
  • 告警OpenAPI仅支持通过网关授权的方式调用；
  • 不接受其他一切形式的调用请求；
• 限流
  • 针对每个授权的APPID进行分钟、小时、天级限流；
  • 针对接口本身进行分钟、小时、天级限流；
  • 系统底层通过组件的方式监控基础指标、提供限流能力；
• 三方调用原则约束
  • 公告三方服务避免过度频繁调用接口致使限流，导致重要告警未能发送出后果自负；
• 异步执行
  • 所有告警请求均通过异步任务的方式分配到CeleryWorker执行，避免同步堆积；
• 提升服务性能与监控水平
  • 提升整体集群性能与吞吐量；
    • 提高集群CPU与内存；
    • 提高RDS（数据库）参数；
    • 增加告警相关的Celery队列Worker数量；
  • 积极监控自身服务各项指标，利用运维平台自身告警能力进行监控；

2、高并发下的数据一致性问题

在上面的问题中，虽然笔者解决了高请求量性能问题，但异步任务带来的高并发又可能会带来数据的一致性问题。

例如极短时间内接受到两条相同告警，由于集群与异步带来的函数执行问题，最后极端情况下可能会生成两颗几乎一模一样的事件树。
针对这个问题，笔者的解决方法是：

• 笔者使用Redis集群实现了分布式锁能力，对于有唯一性、可能存在一致性问题的部分提前加锁；

3、批量服务异常造成的Warroom消息轰炸问题

对于整个部门而言，会有专属的Warroom群组，生产环境的致命告警均会发送到该群中，方便各服务、SRE快速响应、定位问题。

一般情况下群组的消息数量是比较少的，但是当较大规模批量故障产生时，Warroom群会被海量的消息淹没。
针对这个问题，笔者提出两个措施：

• 针对Warroom发送的消息有数量限制，同一个Region下一段时间内（15分钟）只能发送5条消息；
  • 超过5条后，Warroom群组通知操作会被取消；
• 每10分钟会根据当前仍未恢复的生产致命告警事件，进行Warroom通报；
  • 一方面避免可能的致命告警消息遗漏；
  • 另一方面也让相关人员了解目前故障的处理进展；

由于本身这类致命告警会有其他通知手段（电话、短信、提单、服务群组），因此这样的收敛也不会让服务漏通知，仅仅为了提升公共Warroom群组的体验。

4、告警策略匹配问题

当一条告警请求来到中台时，会首先检查参数合法性：

• 如果参数不合法，中台会直接拒绝请求，在返回值中告知不合法详情；
• 如果参数合法，笔者会尝试匹配告警策略：
  • 如果匹配到，就直接使用该策略；
    • 本身策略的创建定义阶段就会有唯一性限制，因此也不会存在匹配多条策略的情况；
  • 如果没有匹配到，就直接使用兜底策略；