告警设计与故障发现
好的告警会把你从事故里拉出来；坏的告警会让你对事故彻底麻木。告警太少会错过故障，告警太多会让人忽略所有通知。
告警分层
graph TD
A[指标数据] --> B{阈值判断}
B -->|低严重度| C[记录日志 / 工单]
B -->|中严重度| D[Slack / 邮件通知]
B -->|高严重度| E[立即呼叫 / PagerDuty]
告警设计原则
| 原则 | 说明 | 反例 |
|---|---|---|
| 可行动 | 收到后知道做什么 | "CPU 使用率" 不如 "CPU > 90% 持续 5 分钟" |
| 可分级 | 不同严重度不同处理 | 所有告警都发邮件 → 告警风暴 |
| 少而准 | 避免噪音淹没真问题 | 每分钟一条"低磁盘预警" |
| 有收敛 | 相同故障合并通知 | 5 台机器同时报警 → 发 5 条独立消息 |
三条必备基础告警（示例配置）
# 可用于 Alertmanager / 自定义脚本的告警定义格式
alerts:
- name: healthcheck_down
condition: "http_check_status{target='myapp'} == 0 for 2m"
severity: critical
action: "立即检查应用进程和 Nginx 状态"
- name: high_cpu
condition: "avg(cpu_usage) > 90 for 5m"
severity: warning
action: "查看占用进程 top，检查是否有异常任务"
- name: disk_near_full
condition: "disk_usage{mount='/'} > 85"
severity: warning
action: "清理日志，检查是否有大文件写入"
常见误区
- 把所有告警都设成最高级别：当所有告警都是 CRITICAL，真正的故障会被淹没在噪音里
- 告警阈值用绝对值而不是持续时间：CPU 短暂峰值很正常，"CPU > 90% 持续 5 分钟"远比"CPU > 90%"有意义
- 告警收到但没有运行手册：告警邮件里应该直接附上排查步骤链接，而不是让人半夜去翻文档
本节执行清单
- [ ] 先定义 3 条关键告警：健康检查、CPU、磁盘
- [ ] 给每条告警写出对应的处理动作
- [ ] 删除或降级一条没有行动价值的噪音告警
- [ ] 测试一次告警触发，确认通知能正常送达
下一章：Shell 自动化与运维脚本——把重复动作变成机器能做的事。