告警体系必须闭环管理：明确接收人与SLA、绑定值班机制、强制runbook_url、分级静默、抑制衍生告警；关键指标需持续采集+异常检测，规则须结合上下文避免误报；日志告警需结构化过滤聚合，并附日志样本。
告警必须有明确的接收人和响应 SLA
没人处理的告警不是告警，是噪音。Linux 告警体系失效的第一原因是“发出去就不管了”。systemd-journal 里堆满 Failed to start xyz.service，但没人订阅、没人分级、没人确认——这等于没建。
实操建议：
- 每个告警通道（邮件 / 钉钉 / Slack）必须绑定到具体值班人或小组，且有轮值表可查
- 在告警内容里强制包含
runbook_url字段，指向已验证的处置步骤文档 - 对非紧急告警（如磁盘使用率 >85%）设置静默窗口（
silence_duration: 2h），避免重复轰炸 - 用
prometheus-alertmanager的inhibit_rules抑制衍生告警：比如主机宕机后，自动抑制其上所有服务告警
关键指标不能只靠 top 或 df 手动巡检
手动 df -h 看磁盘、top 看 CPU，本质是事后补救。真正有效的告警必须基于持续采集 + 异常检测，而非快照判断。
实操建议：
- 用
node_exporter暴露node_filesystem_avail_bytes而非依赖定时df脚本——前者带时间序列、支持趋势预测（如predict_linear(node_filesystem_avail_bytes[7d], 24*3600)） - 内存告警别只盯
MemAvailable，要结合node_memory_Pgpgin_total和node_vmstat_pgpgin判断是否发生频繁换入换出 - 对 SSH 登录失败，不要只统计
/var/log/auth.log行数，要用faillog -u或pam_faillock的计数器做速率限制告警（如 5 分钟内失败 ≥10 次）
告警规则必须区分“异常”和“预期波动”
把 load1 > 4 当成硬阈值告警，在多核机器上会误报；把 disk_read_bytes_total 日环比下降 90% 当故障，可能只是业务低峰。规则不结合上下文，准确率必然崩塌。
实操建议：
- CPU 使用率告警用
1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))，而非top -bn1 | grep 'Cpu(s)'解析——前者是采样均值，后者是瞬时快照 - 磁盘 IO 延迟告警优先用
irate(node_disk_io_time_seconds_total[5m])，比iostat -x更稳定，且能规避短时抖动 - 对 cron 任务失败，告警条件应为“连续 3 次失败”或“失败时间偏离计划时间 >5min”，而非单次 exit code ≠ 0
日志类告警必须做过滤和聚合，否则秒变洪泛
grep "ERROR" /var/log/syslog | mail -s "error!" admin 这种脚本上线三天就会让邮箱失联。原始日志高频、重复、无上下文，直接告警毫无操作价值。
实操建议：
- 用
mtail或fluentd提前提取结构化字段（如http_status、error_code），再基于字段聚合：比如“error_code == "DB_CONN_TIMEOUT"且每分钟 ≥5 次”才触发 - 对 systemd 服务日志，用
journalctl -u nginx --since "2 hours ago" | grep -c "failed"是反模式；应配置systemd-journald的ForwardToSyslog=no，再由promtail抓取并打标 - 所有日志告警必须带
log_sample字段，截取匹配行前后 2 行，避免“只说报错不说哪行”
真实运维中，最难的不是写第一条告警规则，而是持续清理失效规则、定期校准阈值、确保每个 alert() 后面都跟着一个被验证过的 runbook。漏掉任意一环，体系就退化成噪音生成器。
