filebeat占用 cpu和mem资源过多问题说明

filebeat处理日志异常

摘要

用du -sh看到sql.log日志大小128M ，实际占用14G磁盘空间，文件句柄并没有释放。filebeat处理sql.log日志异常，导致cpu和mem飙升。说明：用true时，运行的filebeat进程持有已经被删除了的文件的句柄（closed_renamed: false不会释放句柄），因此sql.log文件不会真正在磁盘中被删除，分区超级块中的信息也不会更改。用rm -f时，filebeat的close_removed：true，会释放文件句柄。

故障现象

• 生产k8s集群一个项目的4个副本中2个pod个运行异常，原因是宿主机filebeat资源利用过高导致k8s-worker异常；
• 生产k8s集群部分项目输出日志过大, 采用*.log通配符搜集，单个sql.log日志文件超过30G，导致生产k8s集群不稳定。

排查过程

• 2020-8-14 上午多次收到生产k8s集群磁盘容量不足告警，经排查发现为xxx日志量过大引起（该项目单pod 12h内有超过100G日志），尤其是sql.log（单个文件超过30G）；通知研发手动删除大日志，临时解决。

• 2020-8-14下午，xxx研发反映4个pod中有2个异常，经排查发现为filebeat占用的cpu和mem过大引起。删除xxx日志后，重启filebeat解决问题。与研发讨论后，使用true方式每个6小时置空一次sql.log日志。

• 2020-8-16 上午生产k8s集群出现netchecker 网络异常告警，发现filebeat占用cpu和mem过高。驱逐异常机器后，逐个添加xxx的日志并观察filebeat资源占用。发现是xxx sql.log日志引起。1个k8s-worker节点虽然用du -sh看到sql.log日志大小128M ，但是实际占用14G磁盘空间，文件句柄并没有释放。故cat打开很慢， 看上去就像打开异常。filebeat实际采集的还是14G的sql日志文件。

• 2020-8-16 晚上调整生产环境xxx sql.log日志置空脚本，将true方式改为rm -f 后touch方式，filebeat问题不再出现。

解决方案

• 运维侧添加日志清除脚本： rm -f /data/web_logs/xxx/sql.log && touch /data/web_logs/xxx/sql.log && rm -f /data/web_logs/xxx/.log.；
• 研发侧取消优化日志输出： xxx研发已经升级xxx版本，以优化日志输出。

参考资料

1. du查看的文件大小与df查看的大小相差太大~ 你遇到过吗？
2. df和du显示的磁盘空间使用情况不一致的原因及处理

附录

filebeat.yml 关键配置

- type: log
  enabled: true
  paths:
    - /data/web_logs/xxx/*.log
 fields:
    type: xxx
    node: nm
    logtopic: docker-xxx
  close_inactive: 5m
  close_renamed: false
  clean_removed: true
  ignore_older: 24h
  tail_files: false