Filebeat向Kafka发日志时出现特定INFO日志的原因、影响及解决方法

Hey，我来帮你彻底搞懂这条Filebeat日志的问题～

先把你遇到的日志贴出来：

Apr 17 20:14:10 appserver filebeat: 2018/04/18 00:14:10.378702 log.go:36: INFO producer/broker/[[0]] maximum request accumulated, waiting for space

下面分三个部分给你拆解：

本质上这是Filebeat的Kafka生产者在“喊停”——它发给Kafka的请求队列已经满了，没法继续塞新请求了，只能等Kafka处理完一部分请求腾出空间。

具体触发的场景通常是这几种：

• Kafka broker太忙了：比如CPU跑满、磁盘IO跟不上，处理请求的速度远远慢于Filebeat发请求的速度；
• Filebeat发得太猛：比如你把批次大小（batch.size）设得太大，或者并发请求数调得过高，一下子把Kafka的接收能力顶满；
• 网络拖后腿：Filebeat和Kafka之间的网络延迟高、带宽不够，导致请求传输慢，积压在Filebeat的队列里。

先给你吃个定心丸：这是INFO级别的日志，不属于严重异常，更像是一个“预警黄灯”。

短期出现几次完全不用担心，Filebeat会自动等队列有空位再继续发送，而且如果你开启了Filebeat的磁盘队列（默认可能没开，需要手动配置），就算内存队列满了，也会把日志写到磁盘上，绝对不会丢数据。

但如果这条日志刷得特别频繁，甚至开始出现WARN或者ERROR级别的日志（比如failed to send events），那就要重视了——这说明你的日志传输链路已经接近饱和，再不管的话可能会出现日志堆积、发送延迟越来越高的问题。

根据实际运维经验，给你几个实用的优化方向：

调整Filebeat的发送配置 #

• 降低batch.size和bulk_max_size：减少每次发给Kafka的日志量，避免一下子把Kafka压垮；
• 扩容请求队列：适当调大queue.buffering.max.messages或者queue.buffering.max.kbytes，给Filebeat多留一点缓冲空间，但注意别超过服务器的内存上限；
• 开启磁盘队列：在Filebeat配置里加queue.disk.enabled: true，把内存装不下的请求写到磁盘，既避免内存溢出，又保证数据不丢。

优化Kafka集群 #

• 检查broker资源：看看Kafka节点的CPU、内存、磁盘IO是不是跑满了，如果是，赶紧扩容节点；
• 调整主题分区数：给对应的日志主题增加num.partitions，让多个broker同时处理这个主题的请求，提升并行处理能力；
• 优化磁盘配置：如果Kafka用的是机械硬盘，换成SSD能大幅提升IO性能，或者调整log.flush.interval.ms等参数，减少磁盘IO压力。

优化网络链路 #

• 尽量让Filebeat和Kafka在同一个局域网内，避免跨机房的高延迟；
• 检查网络带宽，如果是带宽不够导致的请求积压，考虑升级带宽或者限制Filebeat的发送速率。

内容的提问来源于stack exchange，提问作者Dario R