监控显示 __consumer_offsets 日均写入 180GB，三台 broker 的数据盘两天就满，业务 topic 的 retention 却只有 12 小时。乍看像缓存或者权限的锅，追下去往往不是。
kafka-consumer-groups.sh --bootstrap-server kafka:9092 --list | wc -l du -sh /data/kafka-logs/__consumer_offsets-* kafka-configs.sh --bootstrap-server kafka:9092 --describe \ --entity-type topics --entity-name __consumer_offsets
追下去是这么回事：消费者组多、提交频繁，位点消息按 50 个分区分散写入，副本数 3 时磁盘放大三倍。offsets.topic.replication.factor 默认还是 3，清理策略是 compact 但段不滚动就不会清。
「Kafka 内部 topic」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。
偶发问题先统计频率，一小时几次和一天一次，查法完全不同。改完顺手把文档补一句，省得下次自己重新推一遍。
监控和日志的时间要对上，时区不一致会多绕很大一圈。
具体做法是，先统计消费者组数量和提交频率 确认是不是心跳式提交过密；把自动提交间隔从 1 秒放宽 或改手动提交；除了 offsets.retention.minutes 还要调 segment.bytes 让段能滚；长期给内部 topic 单独限流或扩盘。
验收就看一点，内部 topic 日增量降到 40GB 以下 磁盘使用率一周内保持平稳。