做好云主机监控告警配置与故障排查，关键不是把阈值设得越低越好，而是让告警能区分短暂波动与持续异常。可先为 CPU、磁盘和网络建立分级规则，再在告警发生时对齐监控曲线、系统日志与业务现象。
先设阈值：按持续时间分级，而非盯单个瞬时值
阈值应结合主机规格、业务负载和历史基线调整。下面的范围适合作为初始参考，不是所有云环境的固定标准。
- CPU：使用率超过 80% 且持续 5 至 10 分钟，可设为提醒；超过 95% 持续数分钟，可设为严重告警。批处理或编译任务可能正常使用较高 CPU，应按业务时段调整。
- 磁盘：使用率达到 80% 时检查增长趋势，达到 90% 时升级告警；同时监测可用空间、磁盘 I/O 等待和读写延迟。数据库或日志密集型应用需关注 I/O 指标，不能只看容量。
- 网络：持续接近实例带宽上限的 70% 至 80% 时提醒；若平台提供丢包、连接数或网络错误指标，也应纳入观察。可把持续丢包超过约 1% 作为排查信号，但需结合网络类型与业务容忍度判断。
设置告警规则时，优先选择“持续达到阈值”的条件，并分别配置提醒与严重级别。还要确认指标采集间隔、通知对象和静默时段，避免短暂尖峰造成频繁通知。
告警发生后，先确定异常范围
不要看到一条告警就立即重启。先记录发生时间、受影响主机和服务，再比较同一时段的 CPU、内存、磁盘与网络曲线。如果多个指标同时变化，通常比孤立指标更有定位价值。
- 确认告警是否持续，以及是否与业务响应变慢、连接失败或任务延迟同时发生。
- 查看主机近期变更，例如应用发布、配置调整、定时任务启动或磁盘扩容。
- 检查云平台侧的实例状态与监控指标，并核对主机内部采集数据是否完整。
- 按异常指标进入对应排查路径；保存告警时间和关键日志，便于后续复盘。
按指标定位，再用日志验证原因
CPU 高：区分进程占用与系统等待
查看进程级 CPU 使用情况，并观察负载、线程数和上下文切换趋势。若单个进程持续占用较高，核对其应用日志、请求量和近期版本变更；若 CPU 使用不高但负载明显升高，还要检查 I/O 等待或进程阻塞。Windows 主机可使用任务管理器和资源监视器查看进程与资源变化；其他系统可使用相应的进程和性能监控工具。
磁盘告警：容量与 I/O 分开检查
容量不足时，先找出增长最快的目录，核对应用日志、临时文件和备份保留策略，确认后再清理或扩容，避免误删运行数据。若空间充足但读写变慢，应查看磁盘 I/O、队列和延迟曲线，并对照应用日志中的超时信息。存储类型、负载模式不同，延迟的合理范围也不同，不宜套用单一毫秒阈值。
网络告警：看吞吐、丢包与连接状态
先判断是入站还是出站流量异常，再查看网络丢包、连接数和错误计数。流量突然升高时，核对访问日志、任务调度和外部依赖调用；吞吐正常但连接失败时，检查服务监听状态、访问控制规则及目标端是否可达。将这些现象与系统日志中的接口错误、超时记录按时间对齐，能减少盲目重启。
形成可复用的排查闭环
每次处理后记录告警阈值、触发时段、证据和处置结果。若频繁误报，先延长持续时间或按业务时段拆分规则；若故障发生却未告警，则检查采集是否中断、阈值是否过宽，以及是否缺少关键指标。这样，云主机监控告警配置与故障排查才能从单次救火变成可复用流程。
常见问题
CPU 短时超过阈值，需要立即处理吗？
不一定。若很快恢复且业务正常，可观察趋势；持续超限或伴随服务异常时再按进程和日志定位。
磁盘使用率不到 90%，为什么仍会告警？
告警可能针对 I/O 延迟、空间增长速度或可用空间，而不只是使用率。应核对具体触发指标。
不同云厂商的阈值能直接照搬吗？
不建议。实例规格、监控采样方式和存储性能不同，应先观察基线，再调整阈值与持续时间。
告警后要不要先重启主机？
通常先保留监控曲线与日志并确认影响范围。重启可能中断取证，也未必解决资源或配置问题。