Debian环境下Kafka故障排查清单
一 快速定位流程
- 服务状态与系统日志
- 查看 Kafka 与依赖组件状态：sudo systemctl status kafka、sudo systemctl status zookeeper。
- 查看服务输出与内核日志：journalctl -u kafka -n 200 --no-pager、tail -f /var/log/kafka/server.log、必要时查看 /var/log/syslog 与 dmesg。
- 资源与依赖
- 资源检查：free -h、df -h、top/htop。
- 依赖检查：确认 ZooKeeper 已就绪（Kafka 强依赖其进行元数据管理）。
- 网络连通与端口
- 连通性：ping <broker_ip>、traceroute <broker_ip>。
- 端口与防火墙：检查 9092 端口占用（netstat -tlnp | grep 9092 或 lsof -i :9092），放行防火墙（如 sudo ufw allow 9092/tcp）。
- 配置与数据目录
- 核对关键配置：/etc/kafka/server.properties 中的 listeners、advertised.listeners、zookeeper.connect、log.dirs。
- 数据目录可用空间与权限（常见路径 /var/lib/kafka/data 或 /var/lib/kafka）。
- 最小可行性验证
- 列出主题：kafka-topics.sh --list --bootstrap-server <broker_ip>:9092。
- 控制台生产/消费：
- 生产：kafka-console-producer.sh --bootstrap-server <broker_ip>:9092 --topic
- 消费：kafka-console-consumer.sh --bootstrap-server <broker_ip>:9092 --topic --from-beginning
以上步骤覆盖服务状态、日志、资源、网络、配置与连通性，是定位问题的起点。
二 systemd 启动失败专项排查
- 获取完整日志
- 服务日志：journalctl -u kafka -n 200 --no-pager
- 应用日志：tail -n 100 /var/log/kafka/server.log（或安装目录下的 logs/server.log）
- 常见根因
- 单元配置不当：如 Type 与启动方式不匹配（前台/后台）、未声明 SuccessExitStatus、缺少依赖 After=network.target zookeeper.service。
- 资源限制过低：LimitNOFILE 不足导致打开文件受限，内存不足 触发 OOM Killer。
- 端口冲突：9092 被占用导致进程立即退出。
- 依赖未就绪：ZooKeeper 未启动或连接超时。
- 排查与修复要点
- 核对单元文件关键项：
- Type=forking（若通过脚本启动守护进程）
- ExecStart/ExecStop 正确
- Restart=on-failure、RestartSec=10
- SuccessExitStatus=0 143
- LimitNOFILE=65536（或更高）
- Environment=“JAVA_HOME=/usr/lib/jvm/java-11-openjdk”
- 资源与端口检查：ulimit -n、df -h、netstat -tlnp | grep 9092
- 依赖就绪：确保 ZooKeeper 已启动并可连接
- 使配置生效：systemctl daemon-reload && systemctl restart kafka
以上方法与要点可有效定位 systemd 场景下的启动失败与异常退出。
三 常见错误与修复对照表
| 症状 |
快速检查 |
修复建议 |
| 服务启动即停或反复重启 |
journalctl 报错、server.log 无持续输出 |
检查单元文件 Type/依赖/重启策略；确认脚本前台/后台行为与 Type 一致 |
| Fatal error during KafkaServer startup |
server.log 堆栈、配置与目录权限 |
核对 server.properties（listeners/advertised.listeners/zookeeper.connect/log.dirs）、目录权限与可用空间 |
| 端口 9092 无法访问 |
netstat/lsof 显示被占用或防火墙拦截 |
释放占用端口或调整 listeners；放行防火墙 sudo ufw allow 9092/tcp |
| 无法列出主题或生产/消费失败 |
9092 连通性、ZooKeeper 状态 |
测试 ping/traceroute、检查 ZooKeeper 运行、用 CLI 最小验证 |
| 磁盘写满或 I/O 报错 |
df -h、iostat、server.log 的 I/O 错误 |
清理或扩容数据盘；优化保留策略；必要时迁移至更高 IOPS 的磁盘 |
| 频繁 GC 或 OOM |
GC 日志、free/ulimit |
调整 -Xmx/-Xms 与 GC 策略；提升 LimitNOFILE 与系统内存；排查内存泄漏 |
| 高延迟/吞吐低 |
iostat、网络带宽、分区数 |
启用压缩（如 compression.type=gzip）、增大批量（batch.size/linger.ms）、优化分区数与磁盘/网络 |
以上对照表覆盖了启动、网络、磁盘、JVM 与性能等高频问题及处置路径。
四 性能与容量瓶颈定位
- 硬件与系统
- 磁盘 I/O：关注 iostat -x 1 10 的 await/avgqu-sz/ %util，SSD 明显优于 HDD。
- 内存与 GC：堆设置与 GC 行为（频繁 GC 影响延迟与吞吐）。
- 网络：带宽与延迟（跨机房/跨地域尤为关键）。
- 配置与架构
- 分区与并发：分区数需与 Producer/Consumer 并发匹配，避免数据倾斜。
- 副本因子：过高增加网络/磁盘开销，过低影响可靠性。
- Broker 参数：num.partitions、log.segment.bytes、log.retention.hours、replica.fetch.max.bytes、message.max.bytes。
- 操作系统：ulimit -n、net.core.somaxconn、net.ipv4.tcp_max_syn_backlog 等网络与文件句柄调优。
- 监控与验证
- 指标可视化：Prometheus + Grafana 监控吞吐、延迟、错误率、分区状态等。
- 带宽验证：用 iperf 测试节点间带宽，排除网络瓶颈。
通过分层定位（硬件→配置→架构→监控），可系统性识别并化解性能瓶颈。
