云主机告警类型怎么选？

选择云主机（ECS/EC2等）的告警类型，核心原则是：不遗漏关键故障，不淹没于噪音，没有一套“万能”配置，需要根据你的业务重要性（核心库 vs 边缘业务）和运维人力来权衡。

以下是一个经过实践检验的分级选择策略，以及各类告警的具体配置建议。

第一阶段：必选（关乎可用性与数据安全）

这些告警一旦触发，通常代表主机已经或即将不可用，需要立即响应。

1、CPU 使用率

阈值：≥ 90% 持续5分钟 或≥ 95% 持续1分钟。

为什么：CPU长时间爆满通常意味着死循环、高并发攻击或挖矿病毒，会直接导致服务响应超时。

2、内存使用率

阈值：≥ 90% 持续5分钟，对于内存密集型应用（如Java应用），可放宽到 85%。

注意：Linux系统内存“使用率”可能包含Cache/Buffer，如果关注应用OOM（Out of Memory，内存耗尽），建议同时监控Swap使用率 或可用内存绝对值。

3、磁盘使用率——根分区（/ 或 C:）

阈值：≥ 85% 发出警告，≥ 92% 严重告警（持续5分钟）。

为什么：磁盘写满会导致数据库写入失败、服务崩溃，注意，日志文件、Docker容器日志是常见元凶。

4、磁盘 Inode 使用率（Linux 专属）

阈值：≥ 80%。

为什么：磁盘还有空间，但Inode用完了（通常是小文件过多，如cron任务、PHP Session、邮件队列），应用照样无法创建文件。

5、网络出带宽（Outbound）

阈值：≥ 80% 最大带宽。

为什么：带宽打满会导致丢包、访问慢，通常需配合流量监控排查是否被攻击或数据被盗。

6、主机不可达 / Agent 离线

阈值：任何一次 心跳丢失（通常云厂商内置）。

为什么：主机宕机或网络故障，最高优先级。

第二阶段：推荐（关联应用性能与早期预警）

1、CPU 平均负载（Load Average）

阈值：Load > CPU核心数 * 1.5（例如4核CPU，Load > 6）。

为什么：比CPU使用率更早发现问题，当大量进程在等待I/O（如磁盘坏道）时，CPU使用率可能不高，但Load会飙升。

2、磁盘 I/O 等待时间（I/O Wait）

阈值：≥ 30% 持续10分钟。

为什么：数据库、日志写入慢的元凶，如果I/O高但CPU低，说明瓶颈在磁盘。

3、内存中的 OOM Killer（内存溢出杀死进程）

阈值：任何一次 出现Out of memory: Kill process 日志。

为什么：这是内存不足的最终结局，会随机Kill进程（包括数据库），务必告警。

4、进程数 / TCP连接数

阈值：接近或超过系统最大限制（如ulimit -n 的80%）。

为什么：应用出现连接泄漏时的典型特征。

第三阶段：可选（用于容量规划，可设置成通知而非告警）

1、磁盘使用率——数据盘（/data 或 D:）

阈值：≥ 70%（通知），≥ 90%（告警）。

为什么：数据盘通常有计划扩容，不必太敏感，超70%意味着该规划扩容了。

2、网络入带宽（Inbound）

阈值：≥ 80% 最大带宽。

为什么：出带宽影响用户访问，入带宽主要影响服务器处理能力（如被DDoS），可结合日志判断。

3、磁盘使用率超过80%后，以7天 / 30天为周期计算增长率

用途：判断是否因为日志增长导致磁盘即将占满，用于自动化扩容。

如何避免“告警风暴”（关键技巧）

配置了所有指标后，如果不做调整，你会收到大量“CPU突然跳高又回落”的垃圾告警，建议：

1、设置静默期：避免频繁告警。

- CPU > 90% 持续5分钟 才告警，而不是持续1分钟。

2、分级通知：

P0/P1级（主机不可达、磁盘满、OOM）：直接打电话或短信。

P2级（CPU > 90%、Load高）：发即时通讯工具通知（钉钉/飞书/企业微信机器人）。

P3级（CPU > 70%、磁盘使用率 > 80%）：发邮件，第二天早上看即可。

3、组合告警（高级用法）：

不良：CPU > 90% 就告警。

良好：CPU > 90%且Load也高且该主机上的应用响应时间上升。

- 大多数云厂商（阿里云、AWS CloudWatch、腾讯云）支持多条件组合。

最后建议：

先配置必选的6项，运行一周，观察噪音情况，如果经常误报（如CPU偶尔冲到90%又回落），就调整阈值或持续时长，如果经常漏报（如磁盘突然写满，你只设了90%报警，发现时已满），就加一个> 85% 的提前警告。

这样逐步迭代，就能得到最适合你业务的告警方案。

文章摘自：https://idc.huochengrm.cn/zj/25935.html