主备切换前的业务预警通知核心是提前感知风险，可通过健康检查失败预警、系统指标监控、notify脚本日志分析及业务层主动上报四类方式实现事前预警。
主备切换前的业务预警通知，核心是让运维和业务方在切换发生前就感知风险，而不是等VIP飘走、服务中断才收到告警。关键不在于“切了之后发邮件”，而在于“切之前就知道大概率要切”。
基于健康检查失败提前触发预警
Keepalived 本身不直接支持“即将切换”的预测，但可以通过自定义脚本，在健康检查连续失败但尚未触发 VRRP 状态变更时发出预警：
- 在 vrrp_script 中定义探测逻辑（如 curl -f http://127.0.0.1:80/healthz），设置 fall 3（连续3次失败才降级）
- 同时用独立脚本每秒轮询该探测结果，一旦发现连续2次失败（比 Keepalived 的 fall 阈值早1次），立即执行预警通知（发邮件/钉钉/Webhook）
- 示例判断逻辑：if [ $(grep -c "fail" /tmp/healthz.log | tail -n 1) -ge 2 ]; then send_alert "健康检查异常，预计2秒后可能触发主备切换"; fi
监听 Keepalived 状态变化前的信号
Keepalived 的 notify 配置只在状态真正改变（如 BACKUP → MASTER）时触发，属于“事后通知”。若需“事前预警”，可结合系统指标做前置判断：
- 监控主节点 CPU、内存、磁盘 I/O、MySQL 连接数、慢查询速率等——这些指标持续恶化往往是切换导火索
- 用 Prometheus + Alertmanager 配置规则，例如：avg_over_time(mysql_threads_connected[5m]) > 95 and on(instance) (node_load1 / node_cpu_seconds_total{mode="idle"}[5m]) > 0.8
- 满足条件即触发“高负载预警”，标注“当前主节点资源紧张，建议人工检查，可能触发自动切换”
配置 notify_master/notify_backup 的增强版脚本
虽然 notify 是切换后执行，但可通过脚本内容反推“切换动因”，实现准事前反馈：
- 在 notify 脚本中加入日志分析：读取最近 30 秒的 keepalived 日志，提取 "Kernel is out of memory"、"connect timeout"、"check failed" 等关键词
- 根据失败类型分类通知：“因 MySQL 健康接口超时触发切换” vs “因网卡丢包率突增触发切换”
- 附带最近一次成功健康检查时间、失败次数、本地服务端口状态（netstat -tlnp | grep :3306），帮助快速定位根因
业务层主动上报异常信号
最可靠的预警来自业务自身。在应用代码或中间件中埋点，当出现以下情况时主动推送预警：
- 数据库连接池耗尽且重试 3 次仍失败
- 上游调用 VIP 超时率连续 10 秒 > 30%
- 应用健康接口（/healthz）返回 503 或响应时间 > 2s 达到阈值
- 所有信号统一打到消息队列（如 Kafka），由告警中心聚合判断是否进入“切换预备态”
