通过分析Keepalived日志中的切换事件次数、时间戳及前后服务状态，可判断系统稳定性；高频抖动、无触发切换、延迟超长等异常需排查配置、网络或健康检查问题。

直接看日志里的切换事件次数和时间戳，再结合切换前后的服务状态，就能判断系统是否稳定。频繁切换或无故漂移说明配置或网络有隐患，不是真高可用。

抓取并解析 Keepalived 切换日志

Keepalived 的所有状态变更（如 MASTER → BACKUP、BACKUP → MASTER）都记在系统日志里。默认路径是 /var/log/messages（CentOS/RHEL）或 /var/log/syslog（Ubuntu/Debian），也可用 journalctl 实时查看：

• 查最近10次切换记录：journalctl -u keepalived | grep -i "transition\|entering\|leaving" | tail -10
• 按时间倒序提取完整切换行：journalctl -u keepalived --since "7 days ago" | grep -E "(MASTER|BACKUP).*transition|state change"
• 关键字段包括：时间戳、节点角色（MASTER/BACKUP）、vrrp_instance 名（如 VI_1）、原因（如 "priority higher", "recv an advertisement", "timeout"）

识别异常切换模式

稳定系统应极少主动切换。以下情况需重点排查：

• 高频抖动：1分钟内多次来回切换（如 MASTER→BACKUP→MASTER），大概率是 advert_int 不一致、virtual_router_id 冲突 或防火墙丢弃 VRRP 报文（检查 tcpdump -i eth0 vrrp 是否收得到组播）
• 无触发切换：日志显示 “Transition to MASTER” 却没对应故障（如 Nginx 未挂、keepalived 未停），说明健康检查脚本失效或 track_script 未绑定到实例
• 延迟超长：从主节点宕机到备节点接管超过 3 秒（advert_int × 3），可能是网络延迟大、SELinux 阻断脚本执行，或 systemd 启动超时导致 keepalived 初始化慢

关联服务状态做归因分析

单看 VIP 漂移不够，必须验证切换是否真正解决了问题：

• 在每次 “Entering MASTER” 日志时间点前后 10 秒，检查：curl -s http://127.0.0.1/health 和 systemctl is-active nginx，确认服务当时是否真实可用
• 若日志显示 “Leaving MASTER” 但 Nginx 仍 running，说明健康检查逻辑错误（例如脚本 exit 0 却没校验端口）
• 对比两节点日志：主节点报 “stop” 而备节点无 “recv advertisement”，基本可断定是 物理链路中断或网卡 down，不是软件问题

建立稳定性量化指标

用简单命令生成周报级数据，比纯人工翻日志更可靠：

• 周切换次数：journalctl -u keepalived --since "1 week ago" | grep -c "transition" —— 稳定系统应 ≤ 2 次（含计划维护）
• 平均切换耗时：用 awk 提取每次 “Leaving MASTER” 和下一条 “Entering MASTER” 的时间差，求均值
• VIP 归属连续性：运行 watch -n 1 'ip addr show eth0 | grep 192.168.10.100' 观察 5 分钟，确认 VIP 是否始终只出现在一台机器上