LG_AI_Research1. 问题现象与紧急处理
那天凌晨3点，监控系统突然狂发告警——某Kafka集群的broker节点磁盘使用率达到100%，紧接着该节点从集群中离线。作为消息队列的核心组件，这种故障会直接导致生产者消息堆积和消费者延迟飙升。我第一时间SSH登录故障节点，用df -h确认磁盘确实被占满，同时发现Kafka日志目录（默认/var/log/kafka）膨胀到异常大小。
紧急处理三板斧：
- 通过
du -sh * | sort -rh快速定位占用空间最大的文件，发现是kafka-server.log文件达到200GB - 立即执行日志轮转：
kafka-log-dirs --bootstrap-server localhost:9092 --alter --topic-partitions my_topic:0 --log-dir /var/log/kafka --config retention.bytes=1073741824 - 临时清理旧日志释放空间：
find /var/log/kafka -type f -mtime +7 -exec rm {} \;
重要提示：直接删除日志文件可能导致消息丢失！优先通过Kafka自带的日志清理机制处理。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 根因分析与配置优化
2.1 日志保留策略失效
检查server.properties配置发现：
properties复制log.retention.hours=168
log.retention.bytes=1073741824
理论上应该保留7天或1GB数据（以先到者为准），但实际未生效。原因在于：
- 没有启用日志清理器：
log.cleaner.enable=true被注释 - 检查周期过长：
log.retention.check.interval.ms=300000（5分钟）
优化方案：
properties复制log.cleaner.enable=true
log.retention.check.interval.ms=180000 # 3分钟
log.segment.bytes=1073741824 # 控制单个日志段大小
log.cleanup.policy=delete,compact # 双重保障