Keepalived中进程监控异常问题分析与解决方案

问题背景

在使用Keepalived实现高可用性(HA)方案时，管理员可能会遇到系统日志中出现"can't read from XXXXXX/stat"的错误信息。这种情况通常发生在Keepalived与HAProxy、Postfix等服务的组合部署环境中，特别是在SMTP邮件中继服务器的高可用架构中。

现象描述

当系统运行一段时间后，管理员通过systemctl status keepalived命令可能会看到类似"can't read from XXXXXX/stat"的错误提示。同时，VIP(虚拟IP)的流量可能会异常地同时流向主备两台服务器，导致服务混乱。重启Keepalived服务可以暂时解决问题，但一段时间后问题会再次出现。

根本原因分析

经过深入调查，这个问题实际上与Keepalived本身无关，而是与进程监控脚本的实现方式有关。具体原因如下：

1. pidof命令的行为特性：在Ubuntu 22.04系统中，pidof命令在查找进程时会尝试读取/proc/[PID]/stat文件。当目标进程在pidof执行期间恰好退出时，就会出现"can't read from XXXXXX/stat"的错误提示。

2. 监控脚本设计缺陷：常见的监控脚本会使用pidof命令来检查目标进程是否存在，然后通过判断输出结果来确定进程状态。这种实现方式存在竞态条件，当进程快速启停时就会触发上述问题。

3. Keepalived配置不当：同时使用了vrrp_track_process和自定义脚本两种方式来监控同一进程，导致监控逻辑复杂化。

解决方案

方案一：使用Keepalived内置的进程跟踪功能

Keepalived本身提供了强大的进程跟踪功能，可以替代外部脚本监控：

global_defs {
  # 全局配置
}

vrrp_track_process track_haproxy {
    process haproxy
    delay 1
}

vrrp_track_process track_postfix {
    process master  # Postfix的主进程名为master
    delay 1
}

vrrp_instance VI_XX {
  # 其他配置...
  
  track_process {
    track_haproxy
    track_postfix
  }
}

这种方式的优势：

• 直接由Keepalived内核监控进程状态，效率更高
• 避免了外部脚本执行带来的性能开销和竞态条件
• 配置更简洁，维护更方便

方案二：优化监控脚本实现

如果必须使用外部脚本监控，可以采用以下优化方案：

#!/bin/sh
# 使用-q选项，通过退出码判断而不是输出内容
if ! pidof -q haproxy || ! pidof -q master; then
  exit 1
fi

优化要点：

• 使用-q选项让pidof静默运行
• 通过命令的退出码(而非输出内容)判断进程状态
• 减少了竞态条件出现的概率

最佳实践建议

1. 优先使用内置功能：Keepalived的vrrp_track_process是专门为进程监控设计的，应该作为首选方案。

2. 避免重复监控：不要同时使用vrrp_track_process和vrrp_script监控同一进程，这会导致资源浪费和潜在冲突。

3. 合理设置监控间隔：根据业务需求设置适当的监控间隔，过于频繁的监控会增加系统负担。

4. 考虑进程启动时间：对于启动较慢的服务，适当增加delay参数，避免误判。

5. 日志监控：定期检查系统日志，及时发现并处理类似问题。

总结

Keepalived作为高可用解决方案的核心组件，其稳定运行至关重要。通过理解进程监控的工作原理，合理配置Keepalived的监控机制，可以有效避免"can't read from XXXXXX/stat"这类问题的发生。在实际部署中，建议优先使用Keepalived内置的进程跟踪功能，它不仅效率更高，而且能够避免外部脚本带来的各种潜在问题。