CentOS 上 Kafka 故障排查步骤
一 快速定位流程
- 查看服务状态与日志：优先检查 systemctl status kafka 与 journalctl -xeu kafka，再到 $KAFKA_HOME/logs/server.log 定位具体报错。
- 确认依赖：确保 Zookeeper 已启动且 server.properties 中的 zookeeper.connect 可达。
- 校验关键配置：检查 log.dirs 是否存在且权限正确（属主为运行 Kafka 的用户，权限 755）。
- 端口连通：确认 9092 未被占用且监听在正确接口，外部访问需放通 firewalld/iptables。
- 本地连通自检：使用脚本前台启动或临时前台运行，快速观察异常输出。
- 客户端连通：用 kafka-topics.sh --list --bootstrap-server :9092 验证元数据可达。
以上步骤覆盖了最常见的启动失败与不可达场景，可快速缩小问题范围。
二 常见故障与修复对照表
| 症状 |
快速检查 |
修复建议 |
| 启动失败，提示 Failed to start Kafka Server |
查看 server.log；检查 Zookeeper 状态与连接串 |
启动/修复 Zookeeper；校正 zookeeper.connect；必要时查看 /var/log/kafka/server.log 获取细节 |
| 启动即退出，日志含 Cannot allocate memory |
dmesg/日志出现 errno=12 |
释放内存或降低 KAFKA_HEAP_OPTS（如调小堆），再重启 |
| 端口 9092 无法访问或被占用 |
ss/ netstat 查看 9092；lsof -i:9092 |
释放占用进程或修改 listeners 端口；放通 firewalld/iptables |
| 日志目录不可用 |
ls -ld 检查 log.dirs |
创建目录并赋权：mkdir -p /path && chown kafka:kafka -R /path && chmod 755 /path |
| 节点加入集群异常，meta 与 broker.id 不一致 |
查看 logDir/meta.properties |
对齐 broker.id 或清理该 logDir 后重启（新节点建议清理） |
| UnknownHostException/主机名解析失败 |
getent hosts |
在 /etc/hosts 添加 “IP 主机名” 映射 |
| 客户端报 TimeoutException/无法获取元数据 |
本地/远程 telnet 9092 |
校验 listeners/advertised.listeners 对外可达；放通防火墙；必要时改为 IP 直连 |
| 文件句柄/进程数不足导致异常 |
ulimit -a；/etc/security/limits.conf |
提升 nofile/nproc（如 65536），重启会话后生效 |
以上条目对应到实际报错关键词（如 “Could not connect to Zookeeper”“Address already in use”“Log directory does not exist or is not writable”“Topic not present in metadata after 60000 ms”）可迅速定位并处理。
三 关键配置与网络检查
- 配置项核对
- listeners/advertised.listeners：对外暴露的地址与端口，建议生产使用 IP 或确保 DNS 可解析；与客户端 bootstrap.servers 一致。
- zookeeper.connect：Zookeeper 地址列表，逗号分隔，确保网络与 ACL 可达。
- log.dirs：多磁盘可用逗号分隔；目录必须存在且可写。
- 防火墙与 SELinux
- 放通端口：firewall-cmd --add-port=9092/tcp --permanent && firewall-cmd --reload；或按需关闭测试。
- SELinux 临时置 permissive 验证是否为策略问题：setenforce 0（生产慎用）。
- 主机名解析
- 在 /etc/hosts 明确映射 内网IP 主机名，避免 UnknownHostException。
- 资源限制
- 提升 nofile/nproc：编辑 /etc/security/limits.conf（如 * soft/hard nofile 65536），并重启登录会话；用 ulimit -a 校验。
这些检查能解决绝大多数“起不来/连不通/不稳定”的配置与网络类问题。
四 内存与 GC 问题处理
- 现象与定位
- 启动日志出现 error=‘Cannot allocate memory’ (errno=12) 或频繁因 OOM 退出，多为容器/虚拟机内存不足或堆设置过大。
- 处理建议
- 释放同机占用或扩容；
- 降低 KAFKA_HEAP_OPTS（如 -Xmx/-Xms），避免超过物理内存；
- 前台启动观察完整错误输出，再决定堆与 GC 策略。
- GC 调优方向（可选）
- 使用 G1GC，并合理设置堆与 Direct Memory，减少停顿与 Direct OOM。
上述方法可快速解决内存不足导致的启动失败，并给出后续 GC 优化路径。
五 系统层面优化与稳定性
- Page Cache 与 swap
- 降低 vm.swappiness（如 1），减少 swap 对延迟的影响；
- 适度设置 vm.dirty_background_ratio（如 5）与 vm.dirty_ratio（如 60–80），避免一次性大 flush 造成抖动。
- 磁盘与文件系统
- 优先 SSD；文件系统建议 XFS；挂载选项使用 noatime。
- 网络栈
- 提升 socket 缓冲：net.core.{wmem,rmem}{default,max} 与 net.ipv4.tcp{wmem,rmem}；开启 tcp_nodelay。
- 监控与压测
- 结合 JMX/Prometheus+Grafana 监控吞吐、延迟、请求耗时、IO 与 GC；定期压测找瓶颈并回放调参。
这些系统级优化能显著提升稳定性与吞吐，建议结合业务负载逐步验证与固化参数。