服务器半夜出问题，最让人头疼的往往是没人及时看到。阿里云报警要做的，就是把这种“不知道”变成一条准时送到手机上的消息。设得好，磁盘快满的时候能提前几分钟提醒你；设得随便，每天几十条短信很快就会被当成噪音划掉。这里用三个场景说明阿里云报警怎么设才靠谱。
一条报警规则由哪几部分组成
阿里云的报警主要依托云监控（CloudMonitor）。一条完整的规则一般包含三块内容：监控对象和指标，比如某台 ECS 的 CPU 使用率，或某个 RDS 实例的连接数；触发条件，也就是阈值、统计周期和连续触发次数，例如“过去 5 分钟平均 CPU 超过 80%，连续 3 个周期”；通知方式，可以是短信、邮件、钉钉机器人或 Webhook，发给指定的联系人或联系人组。
三块里面，触发条件最容易出问题。阈值压得太低，报警天天响；统计周期取得太短，一个瞬时毛刺就能把人叫醒。
案例一：大促期间 ECS 负载一直偏高
某电商团队在大促前给订单服务的 ECS 配了 CPU 报警，阈值 80%，统计周期 1 分钟。活动一开始，报警几分钟就响一次，值班同学很快就开始不看短信了。
后来查明，定时任务每 10 分钟会让 CPU 冲高 30 秒左右，这属于正常业务行为，算不上故障。团队做了两处调整：统计周期改成 5 分钟，触发条件改为“连续 3 个周期平均值超过 80%”。调整之后，每天的报警从几十条降到个位数，而一次真实的流量异常在 12 分钟内就被抓到了。
所以规则最好按业务的真实波形来定，别直接用默认值。
案例二：数据库连接数快到上限
某 SaaS 团队的 RDS 最大连接数是 2000。应用扩容之后，连接池配置没跟着改，夜间批量任务一跑，连接数就一点点往上爬。他们当时只配了 CPU 报警，没有连接数报警，直到业务接口开始超时才发现。
补上规则后，连接数分了两级：使用率超过 70% 时推送到钉钉群，方便白天排查；超过 90% 时短信通知值班人员，用于夜间应急。分级之后，既能提前看到风险，也不会半夜把所有人都吵醒。
案例三：业务错误要靠日志来报
云监控管的是资源层指标，业务层的错误很多时候只能从日志里看出来。某支付服务的接口开始返回 500，但 ECS 的 CPU 和内存都很正常，资源报警一点动静也没有。团队后来把应用日志接入日志服务（SLS），设置关键字“PaymentTimeout”每分钟出现超过 20 次就触发报警，并通过 Webhook 推到内部工单系统。这次问题是在数据库主从切换后被发现的，比用户投诉早了约 15 分钟。
配置步骤
- 在云监控控制台创建联系人和联系人组，先确认手机号和邮箱能收到消息。
- 选资源时只挑最关心的指标。一口气全部设上，很快就会变成噪音。
- 先观察一到两周的历史基线，再根据基线设阈值。直接拍脑袋定的阈值，大多会偏松或偏紧。
- 设置统计周期和连续次数，把瞬时毛刺过滤掉。
- 区分白天和夜间的通知策略，夜间不重要的规则可以走钉钉，必要时开启静默时段。
- 用压测或手动制造负载验证一遍：报警要真的触发，通知也要真的送达。
几个常见坑
- ECS 默认不采集内存使用率。要设内存报警，得先安装云监控插件，否则规则建了也不会有数据。
- 同一个故障常常同时触发好几条规则，按业务分组后合并通知，能省下不少重复短信。
- 每月看一次报警数量和处理结果。长期没人处理的规则，要么删掉，要么调整阈值。
- 短信偶尔会有延迟，关键报警最好再配一个钉钉或其他渠道做备份。
