Filebeat 内存涨到 2G 被 OOM killed registry 里积压了什么

Filebeat 跑了两周 RSS 涨到 2.1G，被内核 OOM kill，重启后从 registry 里恢复位置，重复发送了 40 万行日志。日志里能对上时间点，这种反而好排。

输出端阻塞时事件堆在内存队列里，bulk 请求一直失败且重试没有上限。registry 文件在强制 kill 时没有刷盘，重启后位置回退。这一点先确认清楚，后面就不用反复试。

queue.disk:
  max_size: 2GB
output.elasticsearch:
  bulk_max_size: 800

围绕「采集器内存溢出」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。

别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。

处理上按这个顺序：把队列改成磁盘队列 避免内存堆积；给 output 设置超时和重试上限 失败就丢弃并计数；调大 registry 的刷盘频率；重启前先停采集 等队列排空。

结果对不对很好判断，内存稳定在 400M 以内 重启后日志条数没有重复。