Fluent Bit 背压导致 mem buf overlimit
问题现象
Fluent Bit 日志中 tail 输入插件反复触发内存缓冲区超限，插件被暂停与恢复：
[input:tail:tail.0] paused (mem buf overlimit)
[input:tail:tail.0] resume (mem buf overlimit)
高频切换说明内存缓冲区一直处于”满”的状态。
根本原因：背压（Backpressure）
日志产生速度 > Fluent Bit 发送到 VictoriaLogs 的速度
tail 插件默认使用纯内存缓冲。当 Mem_Buf_Limit 设定的上限被填满、而下游（VictoriaLogs）来不及消费时，Fluent Bit 暂停该输入插件保护自己不被撑爆，待内存释放后再恢复。
本质
mem buf overlimit是 Fluent Bit 的自我保护机制，不是 bug。但代价是暂停采集——暂停期间若不落盘，日志可能丢失。
解决方案（按优先级）
1. 启用文件系统缓冲 ⭐ 最根本
这是解决背压问题最彻底的方法：当日志产生速度超过发送速度时，Fluent Bit 先把数据写入磁盘，而不是无限占用内存或直接暂停输入。
[SERVICE]
flush 1
storage.path /var/log/flb-storage/
storage.sync normal
storage.checksum off
storage.max_chunks_up 128 # 内存中最多保留的 chunk 数
storage.backlog.mem_limit 5M
[INPUT]
Name tail
Tag kube.*
Path /var/log/containers/*.log
storage.type filesystem # ← 启用文件系统缓冲启用后，即使输出端暂时变慢，数据也会先落盘，等 VictoriaLogs 恢复后再发送，mem buf overlimit 告警会大幅减少。
2. 调整 Mem_Buf_Limit
[INPUT]
Name tail
Tag kube.*
Path /var/log/containers/*.log
Mem_Buf_Limit 64MB # 按实际内存与流量调整社区经验：500 个 Pod 以上的集群，将该值从 5MB 提升到 64MB 可显著提升稳定性。
该参数有生效前提
Mem_Buf_Limit仅在storage.type memory（默认）时生效。 若启用了文件系统缓冲，该参数会被忽略，转而由storage.max_chunks_up控制内存缓冲大小。两个参数不要同时调，否则会困惑于”改了没效果”。
3. 调整管道级缓冲 emitter_mem_buf_limit
若使用了 Filter 插件（尤其 rewrite_tag、multiline），它们内部有独立的 emitter 缓冲，默认上限 10MB。输出端背压时该缓冲也会溢出并导致管道暂停。
[FILTER]
Name rewrite_tag
Match kube.*
Rule $log level ^ERROR$ error true
Emitter_Name re_emitted
Emitter_Mem_Buf_Limit 50MB4. 检查 VictoriaLogs 端性能
tail 反复暂停的直接原因是输出端 HTTP 请求虽然返回 200，但处理吞吐量不足。需检查：
| 检查项 | 说明 |
|---|---|
| 资源瓶颈 | 节点 CPU、内存、磁盘 I/O 是否成为瓶颈。VictoriaLogs 对内存较敏感，限制过紧会导致 OOM 或处理缓慢 |
| 写入压力 | Fluent Bit → VictoriaLogs 的 HTTP 请求延迟，延迟高说明处理不过来 |
| 单节点压力 | 单节点部署的写入能力有上限，需评估是否扩展为集群模式 |
5. 监控与调优
[SERVICE]
http_server on # 开启监控端口
# 通过 /api/v1/metrics 查看指标关注指标：
input_tail的records、bytes— 输入速率output_http的retries、errors— 输出问题
其它手段：
- 分析日志流量模式：用
bytes_over_time等分析流量高峰，判断是否存在突发写入 - 调整 flush 间隔：从 5 秒改为 1 秒，加快发送频率、减少内存积压，但会增加网络请求次数
参数速查表
| 参数 | 位置 | 作用 | 生效前提 |
|---|---|---|---|
Mem_Buf_Limit | [INPUT] | 输入插件内存缓冲上限 | 仅 storage.type memory |
storage.type | [INPUT] | memory / filesystem | — |
storage.max_chunks_up | [SERVICE] | 内存中保留的 chunk 数 | 启用 filesystem 后 |
storage.backlog.mem_limit | [SERVICE] | 积压数据内存上限 | — |
emitter_mem_buf_limit | [FILTER] | Filter emitter 缓冲上限 | 默认 10MB |
flush | [SERVICE] | 刷新间隔（秒） | — |
结论
首选方案
启用
storage.type filesystem进行文件系统缓冲，让磁盘作为内存的溢出容器。同时结合调整
Mem_Buf_Limit、emitter_mem_buf_limit，并排查 VictoriaLogs 端性能，可以有效缓解乃至消除该问题。
参考链接
- VictoriaLogs-日志保留策略 — 下游存储的容量规划
- LogsQL-查询语言 — 用 LogsQL 分析日志流量与错失情况