1. 问题背景

开发反馈紧急环境的某应用在日志平台搜不到日志，登录对应的 filebeat 主机后发现 filebeat 所在目录的磁盘满了，检查 filebeat 日志后发现有大量报错如下：

{"log.level":"error","@timestamp":"2026-03-03T14:10:29.554+0800","log.logger":"kafka","message":"Kafka (topic=busilog_jinji_jbs): dropping too large message of size 34482."}

每小时都有 1G 以上的相关日志

2. 初步排查（检查 Filebeat 配置、Kafka Broker 配置）

以下为 filebeat 配置，max_message_bytes 设置为 10000000，约 10M

[sre@kwephis19864613 filebeat]$ grep -Ev '^$|^#' filebeat.yml 
filebeat.inputs:
......
max_procs: 2
output.kafka:
  enabled: true
  hosts: ["...:9092","...:9092","...:9092"]
  topic: '%{[fields.log_topic]}'
  max_message_bytes: 10000000
  worker: 1
processors:
  - add_host_metadata: ~

以下为 kafka 的 server.properties 配置，没有显示配置，根据官网文档，message.max.bytes 默认值为 1M

https://kafka.apache.org/22/configuration/broker-configs/

kwephispre17557:/hwapp/software/kafka/kafka_2.12-2.2.1/config # grep -Ev '^$|^#' server.properties 
broker.id=4
listeners=PLAINTEXT://7.220.13.223:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=209715200
log.dirs=/hwapp/software/kafka/logs
num.partitions=3
default.replication.factor=2
log.retention.hours=1
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connect=7.220.13.223:2181,7.220.13.67:2181,7.220.13.185:2181
zookeeper.connection.timeout.ms=6000
max.poll.interval.ms=60000
group.initial.rebalance.delay.ms=10000

两个配置的值都远远大于 33kb

3. 深入分析

Topic 级别限制

尝试查看目标 topic busilog_asp_jinji_jbs 是否有自定义限制，但查出来是空白

kwephispre17557:/hwapp/software/kafka/kafka_2.12-2.2.1/bin # ./kafka-configs.sh --zookeeper 7.220.13.223:2181   --entity-type topics   --entity-name busilog_jinji_jbs   --describe
Configs for topic 'busilog_jinji_jbs' are

4. 解决方案（设置 Topic 的 max.message.bytes）

以下命令执行成功后，filebeat 报错立即停止

./kafka-configs.sh --zookeeper 7.220.13.223:2181   --entity-type topics   --entity-name busilog_jinji_jbs   --alter --add-config max.message.bytes=10485760

5. 原因总结

应该不会有人手动配置，怀疑是 bug

目前只发现这一台 filebeat 有问题，先继续观察

Topic级别的配置具有最高优先级，当消息被拒时，直接为Topic设置合适的max.message.bytes是最直接有效的解决方案。