CMS 2.0 飞书精简告警配置与排障记录
1. 文档目的
本文记录一组 HTTPS 站点拨测告警从“飞书默认卡片”改为“自定义精简卡片”的排障过程、最终配置、灰度方法和回滚步骤。
文中账号、Workspace、规则 ID、机器人标识、业务名称和路径均已脱敏，不能直接用于生产环境；实际操作时必须替换为控制台中的真实值。
2. 需求与范围
- 监控对象：多个地域和运营商线路的 HTTPS 拨测规则，共 9 条。
- 原通知方式：告警规则使用
DIRECT_NOTIFY（控制台“极简模式”），直接向飞书机器人发送通知。 - 原有问题：飞书可以收到告警，但只能使用系统默认卡片，存在字段冗余和大量空白。
- 目标：所有线路使用统一的精简飞书模板，并支持首次告警和恢复通知；除非业务明确需要，默认不启用重复通知。
- 灰度要求：配置过程中保留原直连作为兜底；精简链路验证成功后，再逐步收敛默认卡片。
3. 两种通知模式的区别
3.1 DIRECT_NOTIFY
链路：
告警规则 -> 飞书机器人 -> 系统默认卡片
特点：
- 配置简单，规则直接向机器人发送；
- 可靠性容易验证；
- 通常使用系统默认卡片，难以定制卡片内容；
- 不经过通知策略的事件过滤、路由、模板和恢复策略。
3.2 NOTIFY_POLICY
链路：
告警事件 -> 事件订阅 -> 通知策略 -> 路由规则 -> 自定义模板 -> 飞书机器人
特点：
- 支持自定义通知模板；
- 支持按规则 ID、标签、等级等条件订阅；
- 支持合并降噪、通知时段、重复通知和恢复通知；
- 任一订阅条件或路由配置错误，都可能导致通知历史中没有发送记录。
3.3 精简卡片方案的额外代价
自定义精简卡片依赖通知策略，并不只是把直连卡片“换一个模板”。事件进入通知策略后，会经过合并降噪和生命周期管理，并在“问题管理”中生成问题记录。
主要影响如下：
- 告警触发后会在“告警中心 -> 问题管理”中生成问题，状态可能显示为待认领、处理中、已解决或已恢复；
- 问题等级继承告警事件等级，例如源事件为
CRITICAL时，控制台可能显示为 P1 紧急； - 在飞书卡片中执行“认领问题”“关闭问题”“解决问题”等操作时，需要先绑定云监控联系人手机号，并使用短信验证码验证身份；
- 手机号验证属于问题生命周期操作的身份校验，无法通过飞书通知模板关闭；
- 如果恢复事件没有进入同一个问题分组，或者持续有新的触发事件输入，问题可能长期保持未解决状态；
- 如果启用了重复通知，未恢复的问题会按配置间隔持续发送飞书卡片，例如每 15 分钟发送一次；
- 停用通知策略不会删除已经生成的问题记录，历史问题仍需根据实际状态解决、恢复或屏蔽；
- 模板中的“重复通知”生命周期开关只定义重复通知的显示内容，真正决定是否重复发送的是通知策略中的“重复通知”配置。
因此，精简卡片带来的不仅是通知内容定制，还会引入问题管理、身份验证、恢复闭环和重复通知配置等额外运维成本。
3.4 与直连模式的使用差异
| 对比项 | 直连模式（极简模式） | 通知策略精简卡片 |
|---|---|---|
| 飞书卡片 | 系统默认卡片 | 支持自定义精简模板 |
| 问题管理 | 通常不会生成通知策略问题 | 会将事件聚合为问题 |
| 手机号验证 | 不需要在飞书中关闭问题 | 认领、关闭或解决问题时需要身份验证 |
| 重复通知 | 由告警规则的通道沉默周期控制 | 由通知策略的重复通知配置控制 |
| 恢复闭环 | 直接依赖规则的恢复通知 | 依赖恢复事件、分组字段和问题生命周期 |
| 配置复杂度 | 低 | 较高 |
如果核心诉求只是“可靠收到飞书告警”，且可以接受系统默认卡片，优先使用直连模式。如果必须使用精简卡片，则应同时接受并维护问题管理链路。
4. 问题现象
初始现象如下：
- 规则使用
DIRECT_NOTIFY时，飞书能够正常收到默认卡片。 - 规则改为
NOTIFY_POLICY后，飞书收不到告警。 - 事件探索中可以查询到真实告警事件，说明拨测和告警判断正常。
- 通知历史为空，说明通知策略没有产生发送尝试。
- 9 条同类规则表现一致。
- 飞书机器人、模板和路由对象本身没有发生迁移。
5. 最终定位的配置问题
5.1 空订阅条件被复合表达式引用
通知策略中曾存在以下配置：
条件 1：字段为空、值为空
复合条件表达式：1
这不是“无过滤条件”，而是引用了一个不完整的条件，可能导致所有事件均无法匹配。
5.2 未订阅云监控事件
高级订阅设置曾配置为：
订阅云监控事件：否
拨测事件来自云监控基础监控，因此策略无法订阅目标事件。
5.3 删除全部条件后仍不会订阅
当前控制台会明确提示：
未添加订阅条件，将不订阅事件。
因此，不能仅删除空条件；必须增加一条有效的规则 ID 过滤条件。
5.4 合并降噪包含事件中不存在的字段
策略曾同时使用：
resource.entity.entity_id
labels._cms_rule_id
实际站点拨测事件可能没有 resource.entity.entity_id。为避免聚合异常，最终只保留：
labels._cms_rule_id
5.5 飞书对象名称与标识符容易混淆
控制台可能同时展示“名称”和“标识符”，例如：
名称：<飞书机器人显示名称>
标识符：<飞书机器人唯一标识>
类型：飞书
应以机器人标识符和实际 Webhook 配置为准，确认通知策略使用的是已在直连链路中验证成功的同一个机器人。
6. 最终采用的灰度架构
灰度期间保留两条独立链路：
链路 A：DIRECT_NOTIFY -> 默认飞书卡片（兜底）
链路 B：全局事件订阅 -> 精简通知策略 -> 精简飞书卡片
这样即使精简策略异常，原直连通知仍然有效。灰度期间同一次告警收到一张默认卡和一张精简卡属于预期行为。
7. 单线路灰度操作步骤
7.1 获取目标规则 ID
从告警规则详情或事件探索 JSON 中获取目标线路的完整规则 ID：
{
"labels": {
"_cms_rule_id": "<目标规则完整ID>"
}
}
不要使用界面中被截断的 ID；应复制完整值。
7.2 编辑通知策略的事件订阅
进入：
告警中心 -> 通知管理 -> 通知策略 -> 编辑目标精简策略 -> 事件订阅
配置：
字段：labels._cms_rule_id
运算符：等于
值：<目标规则完整ID>
复合条件表达式：1
如果字段下拉框提供“告警规则 ID”或 _cms_rule_id，优先直接选择；仅在没有预置字段时手工输入 labels._cms_rule_id。
7.3 配置高级订阅设置
订阅云监控事件：是
全球订阅：default-cms-<账号ID>-<地域>
关联告警规则：留空
自动根因分析：否
说明：
- 使用“全球订阅 + 规则 ID 条件”直接订阅事件中心中的目标事件；
- “关联告警规则”留空，用于绕开异常的规则策略引用链路；
- Workspace 只能选择目标规则所在范围，避免跨 Workspace 误订阅。
7.4 验证订阅条件
保存前点击：
查看24小时内符合条件的事件
预期：
- 能查询到目标线路的事件；
- 事件中的
_cms_rule_id与配置完全一致； - 不出现其他业务或线路事件。
若结果为零，优先检查：
- 规则 ID 是否完整；
- 字段应使用预置的
_cms_rule_id还是原始 JSON 路径labels._cms_rule_id； - “订阅云监控事件”是否为“是”；
- Workspace 是否正确。
8. 通知配置
8.1 合并降噪
只保留：
labels._cms_rule_id
这样每条规则拥有独立的告警与恢复生命周期，不会把不同线路错误合并。
8.2 路由规则
路由条件：不限
通知对象类型：飞书
通知对象：<已验证可用的飞书机器人>
生效时间：00:00-23:59
时区：GMT+08:00 或 Asia/Shanghai
生效星期：周一至周日
8.3 通知模板
通知渠道：飞书
通知模板：<精简飞书模板名称>
创建通知、重复通知和恢复通知分别开启；未启用升级策略时，升级通知可以关闭。
告警正文示例：
{{ range $index, $event := .events }}
{{ if lt $index 1 }}
**{{ $event.subject }}**
目标：`<健康检查路径>`
条件：连续失败 <N> 次｜每 <M> 分钟一次｜约 <T> 分钟
时间：{{ $event.time }}
{{ end }}
{{ end }}
恢复正文示例：
{{ range $index, $event := .events }}
{{ if lt $index 1 }}
**{{ $event.subject }}**
目标：`<健康检查路径>`
状态：线路已恢复
时间：{{ $event.time }}
{{ end }}
{{ end }}
为避免未确认变量导致标题为空，首次验证时可使用固定卡片标题：
告警｜<业务名称>HTTPS拨测
恢复｜<业务名称>HTTPS拨测
8.4 恢复和重复通知
恢复通知：发送恢复通知
自动恢复：告警不会自动恢复
重复通知：不需要重复通知
升级策略：无
“每 2 分钟一次”通常是拨测或数据检查频率，不等于飞书重复通知频率。两者应分别配置。
对于能够主动产生恢复事件的云监控拨测规则，建议依赖规则本身的恢复事件，不使用“经过 5～10 分钟后自动恢复”。定时自动恢复只有在指定时间内没有新的触发事件时才会生效；如果规则持续产生触发事件，自动恢复计时会不断重新计算。
如确有持续提醒需求，应明确评估接收频率后再启用重复通知。启用“每 15 分钟重复通知”意味着问题未恢复或未解决期间，飞书将持续收到卡片。
8.5 行动集成
本场景只需要自定义飞书通知内容，行动集成保持为空：
触发时行动集成：空
恢复时行动集成：空
9. 从1条线路扩展到9条线路
9.1 收集完整规则 ID
分别从告警规则详情或事件 JSON 中复制9条规则的完整 _cms_rule_id。建议使用以下核对表：
| 序号 | 线路 | 规则 ID |
|---|---|---|
| 1 | 地域A-运营商1 | <规则ID-1> |
| 2 | 地域A-运营商2 | <规则ID-2> |
| 3 | 地域A-运营商3 | <规则ID-3> |
| 4 | 地域B-运营商1 | <规则ID-4> |
| 5 | 地域B-运营商2 | <规则ID-5> |
| 6 | 地域B-运营商3 | <规则ID-6> |
| 7 | 地域C-运营商1 | <规则ID-7> |
| 8 | 地域C-运营商2 | <规则ID-8> |
| 9 | 地域C-运营商3 | <规则ID-9> |
9.2 使用一个 IN 条件
不需要创建9条通知策略，也不需要创建9个相等条件。将单线路条件改为：
字段：labels._cms_rule_id
运算符：IN
值：<规则ID-1>, <规则ID-2>, ... <规则ID-9>
复合条件表达式：1
控制台中应显示9个已选值。保存前再次点击“查看24小时内符合条件的事件”，确认查询结果只来自目标9条规则。
若控制台不支持一个 IN 条件添加多个值，备用配置为9个“等于”条件：
1 OR 2 OR 3 OR 4 OR 5 OR 6 OR 7 OR 8 OR 9
10. 验收步骤
10.1 告警触发验收
在可控窗口内制造目标线路失败，等待产生新的 OCCURRED 事件。
检查：
- 事件探索存在新的目标规则事件；
- 通知历史出现真实发送记录；
- 飞书收到精简卡片；
- 卡片标题、线路、目标、触发条件和时间正确；
- 灰度期间同时收到默认卡和精简卡属于预期。
10.2 恢复验收
恢复拨测目标，等待产生 RECOVERED 事件。
检查：
- 恢复事件保留相同的
_cms_rule_id； - 通知历史出现恢复发送记录；
- 飞书收到精简恢复卡；
- 状态和恢复时间正确。
- “问题管理”中的对应问题进入已恢复状态，不再产生重复通知。
如果飞书已收到恢复卡，但问题管理中的问题仍未恢复，应检查恢复事件是否与触发事件具有相同的 _cms_rule_id 和合并降噪字段，不应仅以拨测页面恢复正常作为通知闭环成功的依据。
10.3 逐线路验收
至少覆盖：
- 每个地域一条线路；
- 每个运营商一条线路；
- 一次告警触发；
- 一次真实恢复。
正在告警中的规则应先恢复，再修改通知模式，避免切换过程中漏掉恢复通知。
11. 从“双卡灰度”收敛为“仅精简卡”
在9条线路的精简触发和恢复通知均验证成功前，不要批量关闭直连。
建议按以下方式逐条迁移：
- 选择一条已恢复的线路作为灰度规则；
- 将规则从“极简模式”切换到“普通模式”；
- 选择同一条精简通知策略并保存；
- 重新执行一次触发和恢复测试；
- 预期每个状态只收到一张精简卡；
- 若未收到卡片或出现重复精简卡，立即切回极简模式；
- 单线路成功后，再逐条迁移其余规则。
最终目标：
9条规则：普通模式
通知策略：统一精简策略
事件过滤：9个规则ID
合并降噪：labels._cms_rule_id
飞书模板：统一精简模板
恢复通知：开启
重复通知：关闭
如果当前租户再次出现规则关联链路异常，应保留“全局订阅 + 规则 ID”作为精简通知入口，并暂缓批量关闭直连，直至完成完整的触发和恢复验证。
注意：切换到仅精简卡后，所有命中事件都会进入通知策略的问题管理链路。若团队不希望维护问题状态、不希望处理手机号验证，或无法接受 P1 问题留存在控制台，应停止收敛并继续使用直连默认卡片。
12. 回滚步骤
12.1 精简策略异常
关闭目标通知策略的启停开关即可。原 DIRECT_NOTIFY 未修改时，默认卡片仍会继续发送。
关闭策略后，还应检查“问题管理”中是否存在切换前生成的未解决问题。必要时逐条解决或屏蔽，并在“通知历史”中确认不再产生订阅通知。仅停用策略不会删除历史问题记录。
12.2 单条规则迁移异常
将该规则恢复为：
通知模式：极简模式
通知对象：原飞书机器人
然后重新触发测试，确认默认卡恢复。
12.3 误订阅其他事件
立即禁用通知策略，检查：
IN列表是否包含错误规则 ID；- 是否误用了告警名称等宽泛条件；
- Workspace 是否选择过多；
- 复合条件表达式是否正确。
13. 排障决策表
| 现象 | 优先检查 |
|---|---|
| “查看24小时事件”为零 | 规则ID、字段路径、订阅云监控事件、Workspace |
| 能看到事件，但通知历史为空 | 策略启用状态、路由、规则关联或后端策略链路 |
| 通知历史失败 | 打开失败详情，检查机器人、模板语法和渠道配置 |
| 通知历史成功，飞书未收到 | 机器人Webhook、签名、群权限、机器人是否被移除 |
| 默认模板成功，自定义模板失败 | Go Template变量、中文/英文模板、预览结果 |
| 收到默认卡和精简卡 | 灰度期正常，说明直连与策略链路同时生效 |
| 收到两张精简卡 | 检查全局订阅和规则关联是否形成重复入口 |
| 恢复卡缺失 | RECOVERED事件、恢复通知开关、规则ID是否保持一致 |
| 每15分钟持续收到“云监控通知策略报警” | 检查重复通知配置、升级策略以及存量未解决问题 |
| 已停用策略仍收到问题卡片 | 在通知历史中核对实际策略，处理存量问题，并排查其他订阅策略 |
| 飞书关闭问题要求验证码 | 属于问题管理身份校验；绑定已验证手机号，或回退直连模式 |
| 线路已恢复但问题仍待认领 | 检查恢复事件和分组字段，必要时人工解决问题 |
14. 结论
本次问题不是飞书机器人或拨测规则失效，而是通知策略的事件订阅配置未能命中云监控拨测事件。修正有效条件、启用云监控事件订阅、限定 Workspace，并通过 _cms_rule_id 精确过滤后，原直连默认卡与精简策略卡能够同时送达，证明自定义模板链路有效。
是否长期采用精简卡片，需要在“通知内容可定制”和“问题生命周期管理成本”之间权衡：
- 若团队需要自定义精简卡片，并能够维护问题状态、手机号验证和恢复闭环，可采用“一条共享通知策略 + 一个
IN条件包含9个规则 ID + 按规则 ID 合并降噪”的方式统一管理； - 若团队只需要可靠收到告警，不需要认领、关闭和问题管理能力，建议保留
DIRECT_NOTIFY。直连模式使用系统默认卡片，但不会引入通知策略的问题管理和手机号验证流程。
无论选择哪种方式，都应避免同时长期启用直连和精简策略，否则同一事件会产生默认卡与精简卡两条通知。
15. 官方文档参考
- 通知策略：https://help.aliyun.com/zh/cms/cloudmonitor-2-0/cms-2-0-notification-policy
- 问题管理：https://help.aliyun.com/zh/cms/cloudmonitor-2-0/cms-2-0-issue-management-1
- 通知模板：https://help.aliyun.com/zh/cms/cloudmonitor-2-0/cms-2-0-notification-template
- 告警群内处理告警与手机号验证：https://help.aliyun.com/zh/arms/alarm-operation-center/handle-alerts-in-group-chats