Kafka Broker 磁盘满导致消息积压排查指南

生产环境中 Kafka Broker 磁盘空间耗尽会触发一连串连锁反应：Broker 拒绝写入、ISR 成员被剔除、Leader 发生切换，最终导致生产者端消息大量积压甚至请求超时。与消费端延迟排查不同，从生产者视角出发能够更快定位到"数据写不进去"的根因，因为生产者是整个消息链路的入口，它的报错信息往往最早暴露问题。

磁盘满如何一步步拖垮写入链路

理解连锁机制是排查的前提。当 Broker 磁盘使用率超过 log.cleaner.max.dedupe 和 log.retention 配置的阈值后，Kafka 会按以下顺序产生影响：

第一阶段，Broker 日志目录空间不足。此时 Broker 无法为 Topic 创建新的 LogSegment，新的写入请求会被拒绝，生产者收到 NotEnoughReplicasException 或 DiskException。注意这个阶段旧的 LogSegment 仍然可以被读取，消费者暂未受到影响。

第二阶段，副本同步失败导致 ISR 缩减。Follower 副本因磁盘写入受阻而无法及时追上 Leader，超过 replica.lag.time.max.ms（默认 30 秒）后被 Leader 从 ISR 中移除。ISR 数量低于 min.insync.replicas 时，acks=all 的生产者写入会被直接拒绝。

第三阶段，如果受影响的 Broker 恰好是某个 Partition 的 Leader，Broker 可能因资源耗尽触发 Controller 的 Leader 选举。Leader 切换期间所有对该 Partition 的读写都会暂停，生产者端表现为请求超时和重试风暴。

第一步：确认磁盘使用分布

排查的起点是搞清楚磁盘空间到底被什么占了。登录受影响的 Broker 节点，执行 df -h 查看各挂载点使用率，然后用 du -sh /path/to/kafka-logs/* 定位到具体 Topic 目录。

常见占盘元凶包括：

未清理的过期日志段。检查 log.retention.hours 和 log.retention.bytes 配置是否合理，默认保留 7 天可能在高吞吐场景下不够用。临时文件和崩溃恢复日志。Broker 异常退出后可能在日志目录留下 .cleaned、.deleted 后缀文件，这些文件不会被自动清理，需要手动删除。Consumer Group 的 Offset 提交日志。__consumer_offsets Topic 默认 50 个分区，如果保留策略设置不当，它本身也会占用可观空间。

用 ls -la /path/to/kafka-logs/topic-name/ | head -20 查看最早和最新的 LogSegment 时间戳，判断是否存在未被清理的过期数据。如果发现 .kafka-clean 或 .tmp 后缀文件，先确认没有正在进行的 Log Compaction 任务，然后安全删除。

第二步：紧急释放空间

确认根因后，优先恢复写入能力。以下是几种快速释放空间的操作：

删除已确认不再需要的 Topic 是最直接的方式。执行 kafka-topics.sh --bootstrap-server <broker> --delete --topic <topic-name>，Topic 删除后对应的日志目录会被清理。但注意删除操作是异步的，实际释放空间可能需要等待一段时间。

缩小保留策略临时生效。对非关键 Topic 修改 retention.ms 为较小值（如 1 小时），加速旧数据清理。修改后执行 kafka-configs.sh 刷新配置，不需要重启 Broker。

手动删除孤立的 LogSegment 文件。在确认没有副本正在同步的前提下，直接删除超过保留时间的 .log 和 .index 文件。操作前务必停止相关 Partition 的 Leader，避免数据不一致。

第三步：检查 ISR 状态与生产者积压

磁盘空间释放后，需要确认 ISR 是否恢复正常。使用 kafka-replica-verification.sh 检查各 Partition 的副本同步状态。如果 ISR 仍然缩减，问题可能不在磁盘，而是网络或 Follower 的 Consumer Lag。

生产者端检查积压情况。用 kafka-producer-perf-test.sh 发送测试消息验证写入是否恢复正常。如果生产者仍然报错，检查 max.block.ms 配置——默认 60 秒可能在故障恢复期间导致请求积压超时。

关注 UnderReplicatedPartitions 指标。正常集群该值应为 0，如果持续大于 0 说明仍有 Partition 处于非健康状态。同时监控 IsrShrinkRate 指标，如果在恢复后仍然频繁触发 ISR 缩减，需要检查是否存在慢盘或网络抖动。

第四步：预防措施与配置优化

排查修复只是第一步，防止复发才是重点。

配置磁盘使用率告警。建议设置两级告警：80% 时发出预警，90% 时触发自动清理或扩容。监控粒度建议精确到每个 Topic 目录级别。

优化日志保留策略。对不同优先级的 Topic 采用差异化保留策略：核心业务 Topic 保留 3-7 天，日志类 Topic 保留 24-48 小时。启用 log.cleanup.policy=delete 配合 retention.bytes 做空间上限控制。

预留足够的磁盘水位。建议 Broker 日志目录所在磁盘至少保留 20% 的可用空间作为缓冲。在高吞吐场景下，可以将日志目录分布在多块磁盘上，使用 log.dirs 配置多个路径实现负载分散。

配置 min.insync.replicas=2 配合 acks=all 确保写入安全的同时，也为单 Broker 故障留出容错余量。同时设置合理的 replica.lag.time.max.ms，避免在短暂抖动期间频繁触发 ISR 变更。

常见误判与避坑

排查过程中有几个容易踩的坑：误将消费者 Lag 当成生产者问题。消费者 Lag 增长不一定是写入故障，也可能是消费者处理逻辑变慢。区分方法是检查 Broker 的 RequestQueueSize 指标，如果生产者请求在队列中堆积，问题出在 Broker 端。

误删正在写入的 LogSegment。在 Leader 选举进行中删除文件可能导致数据损坏。删除前使用 kafka-leader-election.sh 确认目标 Partition 的 Leader 状态，并在低峰期操作。

忽略磁盘 IO 性能退化。磁盘空间充足但 IO 延迟升高同样会导致 ISR 缩减。使用 iostat -x 1 检查 await 和 util 指标，如果 util 持续接近 100%，磁盘本身可能已经老化需要更换。