使用 cloud-alert-rule-inspector 巡檢 1131 個雲資源，發現 129 個告警覆蓋缺口

2026-11-01 16

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 双11前夜，我用免费Skill「云告警扫盲」自动巡检账号：3分钟识别129个未配告警的裸奔资源（如CDN、Nacos全零覆盖），支持阿里/腾讯/华为云，全程只读、不碰密钥。告别“以为配了”的幻觉，让故障在爆发前被看见。

双11 前夜，我给云账号做了一次"告警扫盲"

一、双11 正在打，你的告警配置扛得住吗

双11 期间流量曲线是平时的好几倍，故障的暴露速度也是好几倍。

平时一台 RDS 连接数打满，可能只是几个慢查询；大促当天同样的连接数打满，是订单写不进去、支付回调超时、客服电话被打爆。这种时候业务方不会问"数据库为什么挂了"，只会问"为什么没人知道它快挂了"。

所以大促保障的核心不是"能不能扩容"，而是出事之前你有没有收到那条报警。而报警能不能发出来，取决于一件特别朴素的事：这个资源上到底有没有挂告警规则。

我每年大促前都会问自己三个问题：

1. 我这个账号里所有该监控的资源，都在监控范围内吗？
2. 每个资源上的告警规则，是"能发出来"的，还是"配了个寂寞"的？
3. 上面两件事，我是查过，还是觉得应该没问题？

今年我把第三个问题变成了自动化的答案--把找出漏配置告警规则的资源这件事做成了skill。（你不用会写脚本，不用学习任何技术，只需要和你的AI说一句：帮我的账号做一次告警规则巡检！skill完全免费）

二、云资源告警的两个真实痛点

痛点 1：云平台没有现成的"体检报告"

打开云监控控制台，你能看到告警规则列表、能看到资源列表。但没有一个原生功能会告诉你"哪些资源一条告警规则都没有"。

更要命的是这个缺口是双向不可见的：

• 从资源视角看，你看到的是"这台 RDS 正常运行"，看不出它没被监控；
• 从规则视角看，你看到的是"我有 200 条告警规则"，看不出还有 800 个资源在裸奔。

两个列表都在，就是没人帮你做这次 join。

痛点 2：人工排查耗时耗力

那就手工查。流程大概是：

1. 逐个产品进控制台，导出资源清单（ECS、RDS、Redis、SLB、NAT、CDN、消息队列……）拿到对应的实例ID；
2. 再进云监控-告警规则，逐条看规则绑定了哪个资源；
3. 两张表做匹配，找出差集；
4. 换个地域，回到第 1 步。

一个中等规模账号，16 类产品 × 2 个地域，纯手工是半天到一天的工作量，而且不可重复——下个月资源变了，你得重来一遍。

人工排查还有个隐性成本：做这种机械匹配的时候，人是会偷懒的。查到第 300 个资源时，你开始"这个应该配了吧"，然后就跳过了。漏检往往发生在最枯燥的那一段。

三、解法：给云账号做一次告警"扫盲"

思路很直接：把"资源"和"告警规则"这两张表做 join，按资源统计有效告警规则数，再把低于阈值的资源挑出来。

逻辑不复杂，复杂的是工程实现：要覆盖多厂商、多产品、多地域，每个产品的资源发现 API 还不一样，规则和资源的关联方式也各不相同。

这次我用的是 cloud-alert-rule-inspector 这个 Skill。它做的事情就是：

枚举配置范围内的云资源（按产品、按地域）
        ↓
拉取该账号全部告警规则（CMS / 云监控）
        ↓
按资源统计有效规则数（Namespace + 实例 ID 匹配）
        ↓
挑出规则数 < 阈值的资源（默认 < 3）
        ↓
输出 JSON / CSV / Markdown 报告 + 汇总 Excel

核心能力：

这里有个设计细节值得说：它不做模糊推断。规则里明确写了 Allocation ID/NAT 网关 ID 就只关联那个资源；明确是 _ALL 才按产品维度扩展；空资源数组不会被当成"覆盖全部"。宁可少算，也不错算——在告警覆盖这件事上，虚高的数字比难看的数字危险得多。

四、上手教程

以下命令以 Windows PowerShell 为主，macOS 把 py -3.12 换成 python3.12，不用你管，ai会帮你做
完整跑完一次巡检，从零到出报告大约 10 分钟（含装依赖）。

4.1 环境准备

三个硬性前提，先对齐再动手：

4.2 安装SKILL（以workbuddy为例）

在workbuddy 【技能】搜索：【公有云资源告警项巡检】或者【Cloud Alert Rule Inspector】，如图：

或者使用以下提示词发送给你的AI让它帮你安装：

请根据 https://skillhub.cn/install/skillhub.md，安装 @indiv-momo/slug01sz。安装完可以在对话框输入 /公有云 唤起skill

4.3 配置：凭证怎么填

这一节最重要，请按顺序看。

原则：不要用主账号，不要把密钥发到聊天窗口，建议配置环境变量的方法配置aksk，密钥就不会暴露到大模型的上下文中，离开本机造成泄露风险。

巡检只需要只读权限的子账号 AK/SK。建议单独建一个专供巡检的 RAM 子账号，你要是省事可以直接授权：ReadOnlyAccess，当然如果你更专业，可以让AI帮你输出最小权限脚本。

当你成功拿到aksk，那么这个是你唯一需要做的，其他的事情可以交给AI了，初次使用这个skill，AI会给出一些配置步骤但是这些都可以让AI帮你完成，让它帮你完成0-2的工作，workbuddy内聊天截图：

之后会弹出一个本地web服务，Skill 自带一个本地配置服务，只监听 127.0.0.1。你在浏览器里填 AK/SK，密钥直接写入本机用户环境变量，全程不经过任何聊天窗口或外部网络。

在页面上依次完成：

1. 选云平台（阿里云 / 腾讯云中国站 / 腾讯云国际站 / 华为云）
2. 确认账号名称（默认 阿里云-account01，可改成 生产账号 这类可读的名字）
3. 填 AK 与 SK
4. 勾选资源所在地域——这一步最容易漏，会直接影响结果
5. 点「保存到本机环境变量」
6. 多账号就重复以上步骤
7. 最后点「生成变量名清单」→「复制清单」

生成的清单只含变量名，不含任何密钥值，长这样：

[cari-credentials v1] 以下只有环境变量名，不含密钥值
config: C:\Users\Administrator\.cloud-alert-rule-inspector\config.yaml
- 阿里云-account01 (aliyun; regions=cn-hangzhou,cn-shenzhen): CARI_ALIYUN_ACCOUNT01_ACCESS_KEY_ID, CARI_ALIYUN_ACCOUNT01_ACCESS_KEY_SECRET

实际会生成一个congfig.yaml文件在skill目录，当然你也可以复制config.example.yaml文件自己手动配置环境变量和配置文件也行。

关于地域：只用勾选的地域会被巡检。选漏了不会报错，只会让报告"看起来干干净净"——这是这类工具最危险的失败模式，务必对着控制台核一遍。

4.4 使用：三步跑起来

把上一步的环境变量信息复制给AI即可

[OK  ] 配置文件：...\.cloud-alert-rule-inspector\config.yaml
[OK  ] CARI_ALIYUN_ACCOUNT01_ACCESS_KEY_ID：已保存，运行时由本脚本注入
[OK  ] CARI_ALIYUN_ACCOUNT01_ACCESS_KEY_SECRET：已保存，运行时由本脚本注入
[OK  ] 项目与虚拟环境：...\.cloud-alert-rule-inspector\app
[INFO] 就绪，可以运行

四项全 OK 就可以直接跳到运行，不用重复配置。

首次启动会创建虚拟环境和导入 SDK 需要3-5min，实测：2 个地域、1131 个资源，耗时 1 分 41 秒。

[INFO] 开始巡检（输出由巡检程序产生，不含凭证）
2026-10-31 20:39:28 INFO 账号"阿里云-account01"巡检完成
2026-10-31 20:39:34 INFO 批次汇总报告已生成：...\reports\告警巡检汇总报告-20261031203934.xlsx
2026-10-31 20:39:34 INFO 批量巡检完成：账号数=1，报告数=3

退出码：0 成功 / 1 运行失败 / 2 配置或参数错误，巡检完workbuddy界面。

4.5 拿到结果：报告长什么样

~\.cloud-alert-rule-inspector\reports\
├── 告警巡检汇总报告-<时间>.xlsx                    ← 多账号汇总，先看这个
├── <账号>-监控告警巡检报告-<时间>.md               ← 单账号明细，表格全文
├── <账号>-监控告警巡检报告-<时间>.csv              ← 导入 Excel / BI
└── <账号>-监控告警巡检报告-<时间>.json             ← 原始结构，体积大，一般不用打开

4.6 解读数据：重点看哪几行

第一层：表中Severity 是什么口径，如图你可以筛选出 Severity 为HIGH和MEDIUM 交给你的运维针对性补齐这些高风险的资源。

• HIGH = 规则数 0，也就是完全没监控。裸奔。
• MEDIUM = 规则数 1–2，有监控但不够，通常只覆盖了 CPU 或连接数一两个指标。

这个分级很关键：HIGH 不是"重要"，是"没有"。

第二层：产品汇总表，找"整体性缺失"

真实案例（数据已脱敏）：

这张表最值得琢磨的是结构，不是数字：

• nacos 25/25、cdn 10/10 —— 整个产品线一条规则都没有。这类不是"某个团队忘了配"，而是"这个产品压根没进过告警规划"，属于流程级缺口。
• ecs 610 台全达标 —— 说明公司对主机监控是有标准的，说明"能做好"。
• rds / redis 一半缺失 —— 中间状态，最典型：有人配过，但没配全，也没人复核。

第三层：明细表，按严重度下钻

明细表字段很多，实际有用的就这几个：

Environment 这一列是推断的（从实例名里的 prod/uat/test 猜），不要当权威数据用。命名不规范的环境会判错，需要人工核。

真实案例里最该先动的，是"生产环境 + 零规则"这一组。按环境拆开看：

29 这个数字不大，但含金量最高，双11出事大概率和这些资源有大关联，因为资源到顶了没人知道，除非你公司花大价钱搭建大盘，找人24小时盯着。

五、跑完这一趟，我拿到的结论

1. 总量的 11% 存在告警覆盖缺口：1131 个资源里 129 个不达标，其中 88 个是零规则。
2. 缺口高度集中在两类：完全没有告警规划的产品线（Nacos、CDN），和"配过但没配全"的中间态（RDS、Redis、RabbitMQ）。
3. 生产环境只有 29 个缺口，但每一个都是核心链路，含 SD-WAN 主备。
4. 主机监控是全公司做得最好的：610 台 ECS 全部达标。这说明组织能力没问题，问题在产品覆盖的完整性没人负责。

第 4 条是我觉得最有价值的发现。巡检报告的价值不在于"你缺了 129 个告警"，而在于它把"哪些地方是体系性缺失、哪些地方是执行没跟上"区分开了。

六、把它变成常态化机制

单次巡检只能说明"当天状态"。要变成保障能力，得挂到调度上：

每天 02:00  定时巡检 → 报告落本地
     ↓
规则判断：Under threshold 环比增加 > 20%
     ↓
推送告警（IM / 邮件），附报告链接
     ↓
责任人按产品认领，补规则
     ↓
次月巡检验证是否收敛

工具本身只支持单次巡检（run），定时交给外部调度器（Windows 任务计划、crontab、Jenkins 都行），不要让它常驻。

一个提醒：报告文件名时间戳和 schedule.cron 都按主机本地时区。云主机通常是 UTC，跑在云上会造成"凌晨 2 点的报告写着 18:00"。

七、安全边界（别跳过这节）

具体建议：

1. 用只读子账号，别用主账号。共享电脑、远程桌面、终端服务器上尤其注意。
2. 密钥不要走聊天工具。配置页的意义就在于此——密钥只在浏览器和本机环境变量之间流动，skill会约束AI不会主动去敏感信息，让环境变量安全地在内存中流转。
3. 报告不要上传公共网盘或第三方在线服务。里面的实例名和 ID 足够拼出你的架构。
4. 用完关掉配置服务（页面上的「关闭配置服务」按钮），不再需要时在页面删除账号，会连带清除环境变量。

八、一句话总结

云上最贵的不是没配告警，是你以为配了。

cloud-alert-rule-inspector 做的事很简单：把 1131 个资源和一堆告警规则做了一次 join，然后告诉你 129 个对不上。这件事人工能做，但要半天，而且下次资源变了还得重来。

大促保障做到最后，拼的不是谁扩容快，是谁的盲区小。

本文数据来自我个人的一次真实账号巡检（2 个地域、1131 个资源），实例名与 ID 已脱敏处理。