Keepalived日志是定位高可用异常的核心依据，需重点关注状态变更（如“Transition to MASTER STATE”）、健康检查失败原因（如timeout、503）及脑裂线索（如“Cant receive advert”），日志默认输出至/var/log/messages或syslog，可通过log_facility和log_level优化。
Keepalived 日志是定位高可用切换异常、VIP 漂移失败、脑裂或健康检查失灵等问题的核心依据。关键不在于日志量多少，而在于快速识别 状态变更记录、检查失败原因 和 进程级警告。
关注核心日志位置与输出级别
Keepalived 默认将日志写入 /var/log/messages（RHEL/CentOS）或 /var/log/syslog（Debian/Ubuntu），不单独建日志文件。若需更细粒度追踪，需在 keepalived.conf 的 global_defs 块中显式配置：
- log_facility LOCAL0–LOCAL7：指定 syslog 设施，便于通过 rsyslog 过滤分流
- log_level 3–6：数值越大越详细（3=WARNING，4=NOTICE，5=INFO，6=DEBUG）；生产环境建议设为 4 或 5，避免 DEBUG 级别淹没关键信息
识别典型状态变更与切换事件
Keepalived 主进程状态变化会以明确关键词打点，需重点筛查以下字段：
- "Transition to MASTER STATE" 或 "Entering MASTER STATE"：本节点升主成功，后续应有 "VRRP_Instance(xxx) Sending gratuitous ARPs" 表明 ARP 通告发出
- "Transition to BACKUP STATE"：主动降备或被更高优先级节点抢占，需结合前序日志看是否因权重变化、vrrp_script 失败或收到更高优先级 Advertisement
- "VRRP_Instance(xxx) Received higher prio advert"：说明收到邻居通告，触发让权；若频繁出现，检查对方节点是否未正确降备、网络延迟抖动或组播包被丢弃
定位健康检查失败的直接原因
real_server 的存活依赖 vrrp_script 或 TCP/HTTP 检查，失败时日志通常带具体错误码或超时提示：
- "(xxx) failed (code=127)"：脚本无法执行（路径错、无执行权限、解释器缺失）
- "(xxx) failed (timeout)"：检查超时，优先排查目标端口是否监听、防火墙是否放行、后端服务是否僵死
- "(xxx) failed (status code=503)"：HTTP 检查返回非 2xx/3xx，说明服务虽响应但业务异常（如 Nginx 返回 maintenance 页面）
- 注意：check interval 和 rise/fall 计数 共同决定切换时机；日志中连续多次 "failed" 后才触发 real_server down，勿仅看单次失败
排查脑裂与 VIP 冲突问题
当两个节点同时持有 VIP，大概率是 VRRP 通信中断且 failover 逻辑失效。日志线索包括：
- 持续出现 "VRRP_Instance(xxx) Cant receive advert"：组播收包失败，检查网卡是否 UP、multicast group（224.0.0.18）是否被交换机过滤、iptables 是否 DROP 了 VRRP 协议（IPPROTO_VRRP / protocol 112）
- MASTER 节点日志无任何 "Received advert" 记录，BACKUP 节点却显示 "Entering MASTER STATE"：说明 MASTER 实际已宕机但未释放 VIP，或 BACKUP 因网络隔离误判升主
- 用 tcpdump -i eth0 ip proto 112 抓包验证 VRRP 包双向可达性，比单纯看日志更可靠
