Debian上Kafka故障排查方法
systemctl status kafka确认Kafka服务是否处于active (running)状态。若未运行,通过sudo systemctl start kafka启动服务,并观察启动日志判断是否成功。top、htop或free -h查看CPU、内存使用率;用df -h检查磁盘空间(确保log.dirs所在分区有足够空间);用iostat -x 1监控磁盘IO利用率(IO.UTIL超过70%可能导致性能瓶颈)。/var/log/kafka/server.log(或/data/kafka/logs/server.log),重点关注错误信息(如ERROR、Exception)、IO异常(如Input/Output error)、ZooKeeper连接问题(如Connection timed out)或内存溢出(如OutOfMemoryError)。journalctl -u kafka或tail -f /var/log/syslog查看系统级错误(如Buffer I/O error),判断是否为硬件或系统配置问题。-Xloggc:/var/log/kafka/gc.log到KAFKA_OPTS),用gceasy.io或GCViewer分析是否存在Full GC频繁、内存泄漏等问题。/etc/kafka/server.properties,重点确认以下参数:
listeners:监听地址(如PLAINTEXT://0.0.0.0:9092),确保能被客户端访问;advertised.listeners:对外公布的地址(如PLAINTEXT://your_broker_ip:9092),需与客户端配置一致;zookeeper.connect:ZooKeeper连接字符串(如localhost:2181),确保ZooKeeper服务正常;log.dirs:日志目录路径(如/var/lib/kafka),需存在且具备kafka用户写权限(chown -R kafka:kafka /var/lib/kafka)。内存不足错误,调整KAFKA_HEAP_OPTS(如export KAFKA_HEAP_OPTS="-Xmx4G -Xms4G",设置在kafka-server-start.sh中),避免设置过大导致OOM。systemctl status zookeeper检查状态,若未运行,通过sudo systemctl start zookeeper启动。zkCli.sh -server localhost:2181),执行ls /brokers/ids,查看是否有当前Broker的ID(如0、1)。若无,说明Broker未成功连接ZooKeeper,需检查zookeeper.connect配置和网络连通性。netstat -tulnp | grep 9092或ss -tulnp | grep 9092查看Kafka端口(默认9092)是否被占用。若被占用,修改server.properties中的port或停止占用进程。ping <broker_ip>测试Broker与客户端/其他Broker的网络连接;用telnet <broker_ip> 9092或nc -zv <broker_ip> 9092测试端口是否可达。若不通,检查防火墙(sudo ufw allow 9092)或安全组设置。df -h查看log.dirs所在分区的剩余空间(建议保留至少20%空间),若空间不足,清理旧日志或扩容磁盘。fsck /dev/sdX(替换为实际分区)检查和修复文件系统错误,避免Kafka启动失败。producer.log、consumer.log),关注发送失败(如NotEnoughReplicas)、消费延迟(如lag过高)或连接错误(如Connection refused)。kafka-console-producer.sh --broker-list localhost:9092 --topic test发送测试消息,用kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning消费消息,验证消息是否能正常收发;kafka-topics.sh --describe --topic <topic_name> --bootstrap-server localhost:9092查看Topic的分区分布(如Leader是否均匀分布在各Broker),判断是否存在分区倾斜问题。Prometheus + Grafana搭建Kafka监控面板,监控关键指标(如Under Replicated Partitions(未复制分区数,大于0表示副本同步失败)、Message Throughput(消息吞吐量,突然下降可能为网络或Broker问题)、Broker CPU Usage(CPU使用率,过高可能导致处理延迟))。jstack <kafka_pid>获取线程转储(保存到文件),分析BLOCKED或DEADLOCK线程,定位具体代码问题。