核心思路是通过keepalived notify脚本、nginx upstream状态日志和stub_status主动探测三类信号源，实现vip切换、服务级故障转移及进程假死的可观测告警。告警需含类型、指标快照与可执行建议。
核心思路是让 Nginx 自身或其周边组件主动“说话”——把故障转移事件转化为可观测、可采集、可路由的信号，再接入监控平台触发告警。不依赖人工盯屏，也不靠事后翻日志。
用 Keepalived 的 notify 脚本上报切换事件
当主备节点通过 VRRP 协议完成 MASTER → BACKUP 切换时，Keepalived 会调用配置的 notify 脚本，并传入当前状态（master/backup/fault）。这是最直接、最可靠的故障转移信号源。
- 在
vrrp_instance VI_1块中配置：notify /opt/scripts/notify.sh -
notify.sh接收 $1 参数后，可立即执行：
→ 向 Prometheus Pushgateway 推送带标签的事件指标（如keepalived_state_change{role="master",node="nginx-a"} 1）
→ 调用 curl 发送 Webhook 至 Alertmanager、钉钉或企业微信机器人
→ 写入本地日志并由 Filebeat 实时采集，打上event:failover字段供 ELK 或 Grafana Loki 关联查询 - 关键细节：脚本需具备幂等性，避免同一事件重复告警；建议加时间戳和进程 PID 记录，便于排障回溯
从 Nginx upstream 状态反向识别服务级故障转移
当后端服务异常导致 Nginx 主动踢出节点、流量切走时，这属于“逻辑层故障转移”，虽无 VIP 变更，但业务已受影响，同样需要告警。
- 启用
upstream健康检查（需 Nginx Plus 或第三方模块如ngx_http_upstream_check_module），并在日志中记录状态变化：log_format upstream_log '$remote_addr - [$time_local] "$request" $status $upstream_addr $upstream_state'; - 用轻量脚本监听 access 日志或错误日志，匹配
"down"、"unhealthy"、"no live upstreams"等关键词，每分钟聚合一次异常切换次数 - 若 5 分钟内某 upstream 出现 ≥3 次节点剔除，即触发告警，附带被踢节点 IP 和最近 3 条上游响应头（如
X-Upstream-Status: 502）
利用 stub_status + 自定义探测实现主动心跳式感知
当 Nginx 进程僵死、Worker 全卡住但进程未退出时，单纯看进程存在性会漏报。此时需结合运行时指标判断“是否真能服务”。
- 配置安全的
/internal/nginx_health端点，返回 HTTP 200 并包含关键指标：Active connections: 291Reading: 5 Writing: 179 Waiting: 107
同时校验Waiting值是否长期 >80% 总连接数（说明请求积压） - 用 Blackbox Exporter 定期探测该端点，配合 Prometheus rule 判断：
absent(nginx_http_connections_waiting{job="nginx-health"} > 0.8 * nginx_http_connections_active)→ 表示无响应但连接堆积，极可能已假死 - 一旦探测失败或指标异常持续 2 分钟，触发“Nginx 服务不可用”告警，并自动标记该节点为 maintenance 状态（如调用 Consul API 或更新 DNS 权重）
告警内容必须带上下文，不能只说“切换了”
运维人员收到告警第一反应是“为什么切？影响范围多大？下一步做什么？”，所以告警消息要自带诊断线索。
- 包含切换类型（VIP 切换 / upstream 踢节点 / 进程假死）
- 附带前 30 秒的关键指标快照：active connections、requests/sec、5xx 比率、缓存命中率突降幅度
- 给出可执行建议，例如：
→ “检查 backend2.example.com 的 8080 端口连通性”
→ “查看 /var/log/nginx/error.log 中最近 5 条 upstream timeout 日志”
→ “确认 Keepalived 配置中 preempt_delay 是否生效”
