告警轰炸还是该响不响？华为云CES告警配置实战与五个常见坑

在华为云上跑业务，监控告警是运维的第一道防线。但很多团队的告警体系往往走向两个极端：要么半夜手机被告警短信“轰炸”，真正重要的消息淹没在噪音里；要么服务器内存早已打满、磁盘写爆，却一条告警都没收到。本文围绕云监控服务（CES），从指标选择、阈值与连续周期、通知渠道、告警抑制，到主机监控插件 Agent 的安装验证，再到用压测工具模拟故障来验证告警，系统梳理一套可落地的告警配置方法，并总结几个最常见的坑。

一、先搞清楚 CES 的数据从哪来

CES 的监控数据大致分两类：

• 基础监控：由云平台从虚拟化层采集，无需安装任何组件，例如 ECS 的 CPU 使用率、网络流入/流出速率、磁盘读写速率等；
• 主机监控（操作系统监控）：需要在 ECS 内安装主机监控插件 Agent，从操作系统内部采集，例如内存使用率、磁盘使用率、inode 使用率、进程数、TCP 连接数等更细粒度的指标。

这个区别非常关键：虚拟化层“看不到”虚拟机内部的内存分配和文件系统使用情况，所以内存、磁盘使用率这类指标必须依赖 Agent。很多人“内存指标没数据”的问题，根源就在这里。

除了 ECS，RDS、ELB、OBS、DCS 等云服务也会自动上报各自的指标到 CES，可以统一在 CES 中配置告警。

二、告警规则的几个核心要素

一条告警规则通常由以下部分组成：

1. 监控对象与指标：选择资源（某台 ECS、某个资源分组或全部资源）和要监控的指标；
2. 统计方式与周期：如原始值、平均值、最大值、最小值等，以及聚合周期；
3. 阈值与比较条件：例如“大于等于 80%”；
4. 连续触发次数：连续多少个周期满足条件才触发告警，用于过滤瞬时毛刺；
5. 告警级别：区分紧急、重要、次要、提示等不同级别，便于分级处理；
6. 告警策略/通知频率：触发后只通知一次，还是按一定间隔重复通知；
7. 通知对象：通过 SMN 主题或通知组把消息发送给相关人员。

可用的统计周期、连续次数取值范围、重复通知间隔等，均以控制台和官方文档为准。

下面是一份适合常规 Web 业务的告警规则参考：

配置时的几个原则：

• 阈值留出处理时间：磁盘到 100% 再告警已经晚了，要在还有处理余地时就通知；
• 分级告警：同一指标设置“预警”和“紧急”两档，不同级别发给不同的人或渠道；
• 连续周期过滤噪音：CPU 这类波动大的指标不要设成连续 1 次，否则一次定时任务就会触发告警；
• 按资源分组管理：把同一业务的机器放入资源分组，对分组统一配置规则，新增机器加入分组即可自动纳入监控。

三、通知渠道：SMN 主题与通知组

告警的价值在于“通知到人”。CES 常见的通知方式有两种：

• SMN 主题：先在消息通知服务（SMN）中创建主题，再为主题添加订阅（邮件、短信、HTTP/HTTPS 回调等），告警规则选择该主题即可；
• 通知组：在 CES 中直接维护一组通知对象，适合简单场景快速配置。

最容易被忽略的一点：SMN 订阅添加后通常需要订阅者确认。例如邮件订阅会收到一封确认邮件，点击确认链接前订阅处于未确认状态，告警消息不会送达。配置完成后，务必检查订阅状态。

另外，如果需要对接企业内部的 IM 机器人或工单系统，可以使用 HTTP/HTTPS 订阅，把告警推送到自己的回调接口，再由接口转发。

四、一键告警：快速建立基线

对于刚上云、还没有成体系告警的团队，CES 提供了“一键告警”能力，可以为常用云服务按预置的推荐规则快速开启告警。它适合用来快速建立一个基础的告警基线，避免“裸奔”。

但预置规则是通用模板，阈值和通知策略不一定适合你的业务。建议开启后逐条检查，结合实际负载调整阈值，并确认通知对象正确，否则可能出现告警发给了没人看的邮箱。

五、安装并验证主机监控插件 Agent

Agent 的安装方式可以在 CES 控制台的主机监控页面找到对应操作系统的安装命令，部分场景也支持批量安装。安装前需注意：

• ECS 需要能访问 CES 的服务端点（通常需要 DNS 解析正常，私网场景需确认内网 DNS 配置）；
• Agent 上报数据需要相应的授权，按控制台提示完成授权或委托配置；
• 安装命令、安装路径、进程名称以官方文档为准。

安装后，可以在 Linux 上用下面的命令确认 Agent 运行状态（以常见安装方式为例）：

# 查看 Agent 进程是否存在
ps -ef | grep -i telescope | grep -v grep

# 查看 Agent 相关服务状态（服务名以实际安装为准）
systemctl list-units --type=service | grep -i telescope

# 确认 DNS 能解析外部域名，排查网络问题
cat /etc/resolv.conf
nslookup www.huaweicloud.com

如果进程正常、控制台中主机的插件状态显示为运行中，一般几分钟后即可在监控视图中看到内存、磁盘等指标。

六、用压测模拟故障，验证告警真的会响

配置完告警却从不测试，等于没有配置。建议在测试机上主动制造负载，确认告警能按预期触发、通知能按预期送达。

模拟 CPU 高负载：

# 安装 stress-ng（CentOS/EulerOS 使用 yum，Ubuntu 使用 apt）
yum install -y stress-ng || apt-get install -y stress-ng

# 占满 2 个 CPU 核心，持续 10 分钟
stress-ng --cpu 2 --timeout 600s

# 另开终端观察负载
top

模拟内存占用：

# 启动 1 个内存压测进程，占用约 80% 内存，持续 10 分钟
stress-ng --vm 1 --vm-bytes 80% --timeout 600s
free -h

模拟磁盘写满：

# 查看各挂载点使用率
df -h

# 在测试目录写入一个 5GB 的大文件（按磁盘剩余空间调整 count）
dd if=/dev/zero of=/data/testfile bs=1M count=5120 status=progress

# 测试结束后务必删除
rm -f /data/testfile

测试时注意：压测持续时间要大于“统计周期 × 连续触发次数”，否则条件还没满足压测就结束了；生产环境严禁执行，磁盘测试不要写系统盘根目录，以免影响系统运行。

七、常见坑

坑一：告警轰炸。 表现为同一个问题在短时间内收到几十条消息。常见原因：连续周期设为 1，指标一抖就告警；重复通知间隔太短；同一指标在多个规则中重复配置；一次故障引发上下游大量资源同时告警。解决思路是加大连续周期、合理设置重复通知频率、做好分级，并利用告警屏蔽/静默能力，在计划内的变更窗口或已知问题处理期间临时屏蔽相关告警，变更结束后记得恢复。

坑二：告警不触发。 先确认三件事：规则是否处于启用状态、监控对象是否选对（比如新建的机器没在规则范围内）、指标是否真的达到了阈值且满足连续次数。还要区分“告警没触发”和“告警触发了但没收到”：前者看 CES 告警记录，后者看 SMN 订阅状态、短信或邮件是否被拦截、通知对象是否正确。

坑三：内存、磁盘指标没数据。 绝大多数是 Agent 问题：没有安装、进程异常退出、授权未完成、DNS 或网络不通导致数据无法上报。按上一节的命令逐项检查。另外，磁盘使用率是按挂载点统计的，新挂载的数据盘需要确认已被 Agent 采集到。

坑四：统计方式选错。 用“平均值”监控磁盘使用率问题不大，但用平均值监控突发型指标可能把峰值“平均掉”，而用“最大值”监控 CPU 又可能过于敏感。应根据指标特性选择合适的统计方式。

坑五：只配了阈值告警，没配事件告警。 机器意外重启、宕机等情况，指标可能直接中断而不是越过阈值。建议同时配置云服务器相关的事件告警，弥补指标告警的盲区。

八、排障清单

• [ ] 告警规则是否已启用，监控对象/资源分组范围是否覆盖目标资源；
• [ ] 指标类型是否需要 Agent，Agent 是否已安装且运行正常；
• [ ] Agent 授权、DNS 解析与网络连通性是否正常；
• [ ] 统计方式、周期、阈值、连续触发次数是否合理；
• [ ] 压测时长是否大于“统计周期 × 连续次数”；
• [ ] CES 告警记录中是否已有触发记录；
• [ ] SMN 主题订阅是否已确认，通知组成员是否正确；
• [ ] 邮件是否进了垃圾箱，短信是否被拦截；
• [ ] 重复通知频率和分级是否合理，是否存在重复规则；
• [ ] 计划内变更是否设置了屏蔽，结束后是否已恢复；
• [ ] 是否补充了云服务器事件类告警。

结语

好的告警体系不是“越多越好”，而是“该响的一定响，不该响的尽量不响”。先用一键告警建立基线，再按业务特点调整阈值和连续周期，补齐 Agent 采集的内存、磁盘指标，配好分级通知和屏蔽策略，最后用压测实际验证一遍。花一个下午把这套流程走通，能让你在真正的故障面前从容很多。