Keepalived监控Nginx需分层检测与策略响应：进程层、端口层、功能层三重检查；支持直接停止、拯救重启、权重降级三种响应模式；配置需注意interval、weight/priority配合、authentication及virtual_router_id；辅以双心跳、外部仲裁和日志闭环防脑裂。
Keepalived 监控 Nginx 服务不是简单“看进程在不在”，而是要结合故障类型、业务容忍度和切换代价，设计分层响应策略。核心在于：监控脚本不能只做判断，还要承担干预责任；Keepalived 配置不能只设权重，更要匹配状态机逻辑。
监控脚本需区分故障场景
单一用 ps | grep nginx 判断是否存活，容易误判。Nginx 可能进程存在但无法响应请求（如 worker 全卡死、配置加载失败、端口被占）。建议脚本中叠加三层检查：
-
进程层：确认 master + 至少一个 worker 进程存在（
pgrep -f "nginx: master process" && pgrep -f "nginx: worker process" | wc -l） -
端口层：用
curl -I --connect-timeout 2 -s http://127.0.0.1:80/ | head -1验证 HTTP 响应头是否返回 200/30x - 功能层（可选）：对 upstream 后端发起探针，验证反向代理链路是否通（如 curl 后端健康检查页）
三种主流响应策略及适用场景
Keepalived 不是“一挂就切”，而应按业务连续性要求选择动作路径：
-
直接停止模式：脚本检测失败后立即执行
systemctl stop keepalived。适用于强一致性系统（如支付网关），宁可秒级中断也不接受错误响应 -
拯救一次模式：先尝试
systemctl restart nginx，等待 2–3 秒再复检；失败才停 Keepalived。适合多数 Web 服务，兼顾恢复率与切换时效 -
权重降级模式：脚本返回非零值，触发 Keepalived 自动降低本节点优先级（如
weight -20），使备节点自动升主。适合双主或多活架构，避免 VIP 漂移引发全局重连
Keepalived 配置关键细节
很多故障源于配置疏漏，而非逻辑错误：
- interval 值不宜过小：设为 2 秒较稳妥；低于 1 秒易因瞬时负载高导致误判，且增加内核 VRRP 报文压力
- weight 要配合 priority 使用：例如主节点 priority 设 100，脚本 weight 设 -30，则故障时 priority 变为 70；备节点 priority 设 90 即可确保无缝接管
- 必须启用 authentication：尤其在多 VRRP 实例共存时，防止不同集群间 VRRP 报文误认造成脑裂
- virtual_router_id 必须主备一致且唯一：同一二层网络中不可重复，否则 VRRP 状态混乱
补充防护：避免脑裂与假切换
真实生产环境需额外加固：
-
添加双心跳通道：除默认 VRRP 组播外，在 keepalived.conf 中配置
vrrp_sync_group并启用 unicast_peer，防止单网卡或交换机隔离导致双 MASTER - 加入外部仲裁判断：脚本中调用 etcd 或 Redis 的 key TTL 检查，确认“本节点是否被其他节点标记为异常”，避免本地监控失真
-
日志闭环记录：脚本开头写入
echo "$(date): check start" >> /var/log/keepalived/check.log，便于回溯切换根因
