keepalived 是独立于 nginx 的高可用服务，通过 vip 漂移实现故障切换，日志默认输出至 /var/log/messages 或 /var/log/syslog，可配置分离至独立文件；关键日志如“entering master state”“check failed”等反映状态变化与健康异常，需结合日志监控、prometheus 或 zabbix 实现轻量预警，并确保健康检查真实反映业务可用性。
Keepalived 本身不通过 Nginx 运行，它是独立于 Nginx 的高可用（HA）服务，常与 Nginx 搭配使用实现 VIP（虚拟 IP）漂移和故障自动切换。因此，“Nginx 中 Keepalived”这一说法存在概念混淆——Keepalived 不是 Nginx 的模块或子进程，也不写入 Nginx 日志。它的日志和监控需单独配置和采集。
Keepalived 日志输出位置与配置
Keepalived 默认将日志输出到 /var/log/messages（CentOS/RHEL）或 /var/log/syslog（Ubuntu/Debian），使用 local0 设施（facility）。若需分离日志便于监控，可修改其配置：
- 编辑 /etc/keepalived/keepalived.conf，在 global_defs 块中添加：
notification_email_from keepalived@localhost<br>smtp_server 127.0.0.1<br>syslog_facility local1
- 修改 rsyslog 配置（如 /etc/rsyslog.d/keepalived.conf）：
local1.* /var/log/keepalived.log<br>& stop
- 重启 rsyslog 和 keepalived：
systemctl restart rsyslog keepalived
关键日志事件识别与含义
关注以下典型日志条目，它们直接反映主备状态变化与潜在风险：
- “VRRP_Instance(VI_1) Entering MASTER STATE”：当前节点升为主节点，VIP 已绑定 —— 正常切换或启动时的预期行为
- “VRRP_Instance(VI_1) Entering BACKUP STATE”：降为备节点 —— 需确认是否因优先级变更、网络中断或 health check 失败触发
- “Keepalived_healthcheckers: Check failed”：健康检查失败（如 Nginx 进程不存在、端口不可达、HTTP 返回非 2xx）—— 是故障预警核心信号
- “Keepalived_vrrp: VRRP_Instance(VI_1) Received advert with higher priority”：收到更高优先级通告 —— 可能意味对端恢复或配置异常
轻量级故障预警实现方式
无需复杂平台即可建立有效预警，推荐组合使用：
- 日志轮转 + grep + cron 定时扫描：每分钟检查 /var/log/keepalived.log 是否含 “Check failed” 或连续多次 “Entering BACKUP”，触发邮件或 webhook
-
Prometheus + node_exporter + custom exporter：用脚本解析 keepalived 状态（
kill -USR2 $(cat /var/run/keepalived.pid)获取统计）并暴露指标，例如keepalived_state{instance="node1"} 2（2=BACKUP） - Zabbix 或 Telegraf 直接采集日志文件：配置正则匹配关键错误模式，设置触发器阈值（如 5 分钟内出现 3 次 Check failed）
与 Nginx 联动验证建议
Keepalived 的健康检查常依赖 Nginx 状态，但二者故障边界需厘清：
- 确保 check 脚本或 HTTP check 端点真实反映业务可用性（例如访问
/healthz并校验响应体，而非仅端口通） - 避免健康检查自身成为单点：脚本应超时短（≤2s）、重试少（1~2次），且不依赖本地复杂服务（如 curl 不应调用外部 DNS）
- 当 Keepalived 切换后，手动验证 VIP 是否响应、Nginx worker 是否正常加载配置、后端 upstream 是否连通，防止“VIP 漂了但服务没起来”
