Linux 如何建立有效的告警体系

告警体系必须闭环管理：明确接收人与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。漏掉任意一环，体系就退化成噪音生成器。