自动告警是人工干预起点而非终点，需实现精准分层、可操作告警：覆盖基础设施、服务连通、业务逻辑三层状态；告警内容须带节点IP、失败详情、关联快照及自动动作；通道按P0-P2分级管控；并预置监控看板、诊断命令、回滚按钮等处置入口。
自动告警不是故障转移的终点，而是人工干预的起点。真正的高可用体系中，告警必须精准、分层、可操作——既要避免误报打扰，又要确保关键故障不被漏掉。
告警要覆盖三层状态
单看进程是否运行远远不够。一个 Apache 进程活着，但数据库连不上、健康接口返回 500、页面关键字段缺失，服务实际已不可用。
- 基础设施层：CPU 持续超 90%、磁盘剩余不足 10%、内存 OOM 日志出现
-
服务连通层：VIP 是否响应、80/443 端口是否监听、
/health接口 HTTP 状态码是否为 200 - 业务逻辑层：模拟真实请求（如登录接口返回 token）、校验仪表盘数据更新时间戳是否在 30 秒内
告警内容必须带上下文
收到“MySQL 主库宕机”这类告警，运维人员仍需登录查日志、比对从库延迟、确认 binlog 位置——这会拖慢响应速度。理想告警应附带关键信息：
- 故障节点 IP 和角色（如
mysql-master-01 (10.0.1.10)） - 检测方式与失败详情（如
curl -f http://10.0.1.10:3306/health 返回 timeout） - 关联状态快照（如
Seconds_Behind_Master: 127，IO/SQL 线程: Yes/No） - 自动执行动作记录（如 “已触发 Keepalived 降权，VIP 正在漂移”）
告警通道要分级且可控
不是所有异常都值得深夜电话。按影响程度设定不同通道和响应要求：
- 一级（P0）：主库不可写、核心 VIP 漂移失败、全量服务 5xx 率 > 5% → 电话 + 企业微信强提醒 + 自动创建工单
- 二级（P1）：单个从库同步延迟 > 300 秒、非核心服务健康检查失败 → 企业微信 + 邮件，要求 15 分钟内响应
- 三级（P2）：磁盘使用率 85%、慢查询数突增 → 邮件汇总，每日早会同步
人工干预入口要预置就绪
告警本身不能代替操作。系统应在告警发出的同时，提供一键直达的处置入口：
- 链接到实时监控看板（含当前拓扑、延迟热力图、日志关键词聚合）
- 嵌入常用诊断命令（如点击即可执行
SHOW SLAVE STATUS\G并高亮关键字段） - 提供标准化回滚按钮（如“回切原主库”，但仅在数据一致性验证通过后启用）
- 附带切换检查清单（是否已通知应用方？DNS 缓存是否过期？binlog 位置是否安全？）
