Kafka故障排查配置指南
Kafka故障排查需系统化推进：先检查服务状态与启动日志，确认Kafka及ZooKeeper运行正常；核对关键配置如broker.id、监听地址、ZK连接及目录权限；测试网络连通性与端口占用，监控硬件资源避免磁盘、内存或CPU瓶颈；最后通过日志错误信息定位具体问题，如分区选举异常或连接超时，并针对性调整。
遇到Kafka出问题，先别慌。一套系统化的排查流程，往往比盲目尝试更有效。下面这张图，可以帮你快速建立起一个清晰的排查思路。
接下来，咱们就顺着这个思路，一步步拆解。
1. 检查Kafka服务状态
排查的第一步，永远是确认服务本身是否“活着”。在Linux环境下，最直接的办法就是用systemctl status kafka命令看一眼。如果服务没启动，那就systemctl start kafka启动它。要是启动命令下去，服务还是起不来，那问题就指向了更深处——要么是配置有误，要么是依赖的服务（比如ZooKeeper）没就位，这时候就得接着往下看了。
2. 查看Kafka日志文件
日志是故障定位的“金钥匙”。Kafka的日志通常默认放在/var/log/kafka/目录下，核心日志文件是server.log。想实时追踪最新动态？tail -f /var/log/kafka/server.log这个命令你肯定不陌生。
看日志得有重点，优先关注ERROR和WARN级别的信息。比如，看到NotLeaderForPartitionException，基本就和分区Leader选举或副本同步挂上钩了；而SocketTimeoutException则大概率是网络或客户端连接超时的问题。这些错误信息，往往就是破案的关键线索。
3. 验证Kafka配置文件
配置是Kafka运行的“剧本”，剧本错了，戏肯定唱不下去。核心配置文件server.properties里的下面这几项，务必反复核对：
broker.id：这是每个Broker的身份证，集群内必须唯一，重复了就会出乱子。listeners：Broker自己监听哪个地址和端口（例如PLAINTEXT://0.0.0.0:9092）。advertised.listeners：这个更重要，是告诉客户端“你应该通过这个地址来找我”。如果Broker躲在NAT网关或者Docker后面，这里必须配置成客户端能访问到的公网IP或域名，否则客户端会找不到北。zookeeper.connect：ZooKeeper集群的地址。Kafka的元数据管理全靠它，这里填错了或者ZooKeeper服务挂了，Kafka集群直接就瘫痪了。log.dirs：数据到底存哪儿。确保这个目录存在，并且Kafka进程有写入权限，否则数据落不了盘。num.partitions：Topic的默认分区数。分区数直接决定了Topic的并行处理能力，如果单个分区的吞吐（比如超过10MB/s）成了瓶颈，就该考虑增加分区了。replication.factor：Topic的副本因子，决定了数据的高可用性。记住一个硬性条件：副本数不能超过集群中存活的Broker数量。
4. 测试网络连通性
分布式系统的基石就是网络。Broker之间、客户端与Broker之间，网络必须通畅。两个最基础但极其有效的命令：
- Ping测试：
ping，先确认IP层能不能通。 - Telnet测试：
telnet（端口以实际配置为准），这能验证TCP连接和端口是否被防火墙拦截。9092
5. 检查硬件资源使用
Kafka是个“资源大户”，硬件资源不足会直接导致性能断崖式下跌。主要盯紧这三块：
- 磁盘空间：用
df -h看看log.dirs所在的磁盘。一旦磁盘写满，生产者就会报错，建议至少保留20%的余量。 - 内存：
free -h看系统内存，同时确保Kafka的JVM堆内存参数（-Xmx,-Xms）设置合理，通常设为物理内存的1/4到1/2是个不错的起点。 - CPU：
top或htop看一下Kafka进程的CPU使用率。如果长期在80%以上高位运行，要么是配置需要优化（比如调整线程数），要么就该考虑硬件扩容了。
6. 确认ZooKeeper状态
Kafka的集群协调、Leader选举都离不开ZooKeeper。它要是“病”了，Kafka也好不了。检查两步走：
- 先看服务状态：
systemctl status zookeeper。 - 再进客户端看集群状态：用
zkCli.sh -server连接后，执行:2181 stat命令。如果能看到Mode: leader或Mode: follower，说明集群在正常工作。
7. 检查端口占用情况
Kafka默认用的9092端口，可能会被其他程序意外占用。用netstat -tuln | grep 9092或ss -tuln | grep 9092查一下。如果真被占了，要么在server.properties里把listeners改成其他端口（比如9093），要么就得把占用端口的进程停掉（kill -9 ，操作前请确认）。
8. 验证配置生效
改完配置，别忘了重启服务让改动生效：systemctl restart kafka。重启之后，保险起见，最好再用systemctl status和tail -f看一眼日志，确保没有新的报错蹦出来。
9. 常见配置相关故障及解决方法
最后，分享几个典型的配置相关故障和解决思路，遇到时可以快速对照：
NotLeaderForPartitionException：生产者或消费者报这个错，通常意味着它们连接到的Broker不是当前分区的Leader。先用kafka-topics.sh --describe --topic命令查看Topic的分区详情，重点看Leader是谁，以及ISR（同步副本集合）是否正常。如果ISR为空，说明副本同步出了问题，可能需要重启滞后的Broker。--bootstrap-server :9092 SocketTimeoutException：网络延迟高或者Broker压力大时常见。可以尝试适当调大客户端配置中的request.timeout.ms和socket.timeout.ms参数值（默认都是30000毫秒），给网络和服务器多一点响应时间。InvalidConfigurationException：启动时报这个，基本就是配置文件格式或内容有误。检查server.properties，确保是key=value的格式，没有多余的空格或特殊字符，并且参数值在合法范围内（比如前面提到的副本数不能超过Broker数）。