linux kafka崩了咋办

“Linux 上 Kafka 崩了”这个说法比较笼统，要先看是进程挂了、起不来，还是运行异常（丢消息、消费堆积、频繁 GC/OOM）。下面按排查顺序 + 常见场景 + 应急操作给你一套实战流程。

一、先确认 Kafka 到底“怎么崩”

1. 看进程是否还在

ps -ef | grep kafka
# 或
jps | grep Kafka

• 进程不在 → 崩溃 / 被 kill / OOM
• 进程在但不可用 → 假死 / Zookeeper 或 Controller 问题

2. 看 Kafka 日志（最重要）

cd $KAFKA_HOME/logs
tail -n 500 server.log

重点看：

• OutOfMemoryError
• Shutdown broker
• Fatal error
• Failed to acquire lock on
• ZooKeeper session expired

3. 看系统日志（是否被 kill）

dmesg | grep -i kill
# 或
grep -i "out of memory" /var/log/messages

常见于：

• Kafka 被 OOM Killer 干掉

二、最常见崩溃原因 & 解决办法

✅ 场景 1：OOM（内存不足）

现象

• 进程突然消失
• dmesg 中有 Out of memory: Kill process

解决

# 看内存
free -h

调整 Kafka 堆内存（不要超过物理内存 50%）：

export KAFKA_HEAP_OPTS="-Xms4G -Xmx4G"

⚠️ Kafka 依赖 page cache，堆太大反而更慢

✅ 场景 2：Zookeeper 断开 / Session 过期

现象

ZooKeeper session expired
Controller moved to another broker

解决

• 检查 Zookeeper 状态

echo stat | nc zk_host 2181

• 重启顺序必须正确：

# 先 ZK
zkServer.sh start

# 再 Kafka
kafka-server-start.sh -daemon server.properties

✅ 场景 3：磁盘满了（最容易被忽略）

现象

• Kafka 起不来
• 日志疯狂报错

df -h

解决

• 清理旧日志

du -sh /data/kafka-logs/*

• 修改保留策略：

log.retention.hours=72
log.cleanup.policy=delete

✅ 场景 4：broker ID 冲突

现象

Configured broker.id 1 doesn't match stored broker.id 2

解决

• 删掉 meta 文件（谨慎）

rm /data/kafka-logs/meta.properties

或修改 server.properties

broker.id=2

✅ 场景 5：Controller 频繁切换

现象

• 消费卡住
• 日志中 controller 来回切

原因

• 网络抖动
• GC 停顿

解决

• 降低 GC 停顿（G1）

-XX:+UseG1GC

三、紧急恢复步骤（通用）

# 1. 停 Kafka
kafka-server-stop.sh

# 2. 查日志
tail -n 500 logs/server.log

# 3. 查磁盘 / 内存
df -h
free -h

# 4. 重启
kafka-server-start.sh -daemon config/server.properties

四、如果是生产环境（重要）

✅ 不要立刻删数据
✅ 先确认：

• 是否多副本
• 是否影响业务
• 是否能滚动重启

如果你是：

• Kafka 起不来
• 消费堆积
• 数据丢失
• 容器 / K8s 环境

把下面信息发我，我可以直接帮你定位：

1. Kafka 版本
2. 错误日志（关键几行）
3. 是单机还是集群
4. 是否用了 ZK / KRaft

我可以按你的具体报错“对症下药”。