用了Elasticsearch,一口气上5T

filebeat 文件句柄占用不释放,导致空间告警

Beats | 作者 Jiehui Tang | 发布于2020年05月14日 | 阅读数:474

我们生产环境最近有服务器出现空间告警,登录上去排查后,发现是filebeat(5.4.0)占用了大量已被删除的日志文件句柄,接近300个,具体如下(列出部分):

fd未被释放.png

 
经排查,当时这台服务器上SystemErr.log日志文件突然日志量增大,1分钟会滚动8个日志文件(每个日志文件20MB),当达到50个时,最早的那个会被删除。
 
为了防止文件句柄被占用不释放,我们也提前梳理配置了相关的配置参数(见下面下划线标记),filebeat 配置的相关参数如下:
---
filebeat.prospectors:
  -
    clean_inactive: 168h
    close_inactive: 1m
    close_removed: false
    close_renamed: true

    close_timeout: 1h
    encoding: utf-8
    fields:
      logSource: WAS
      topicName: Log_IFMC
    fields_under_root: true
    ignore_older: 5m
    input_type: log
    max_bytes: 307200
    multiline.match: after
    multiline.negate: true
    multiline.pattern: "^\\["
    paths:
      - /soft/IBM/WebSphere/AppServer/profiles/BEMC*/logs/bemc*/*
filebeat.spool_size: 256
output.kafka:
  enabled: true
  hosts:
    - "0.0.0.0:9092"
    - "0.0.0.0:9092"
    - "0.0.0.0:9092"
    - "0.0.0.0:9092"
    - "0.0.0.0:9092"
    - "0.0.0.0:9092"
  topic: "%{[topicName]}_LOG"
tags:
  - json
但是以上这样的配置,依然出现了这个问题,filebeat自身持续打印出下面这种日

filebeat日志内容.png

 
麻烦大家有遇到过类似的或者懂得帮忙看一下,谢谢。
 
 附上filebeat的日志文件

 
已邀请:

Jiehui Tang

赞同来自:

还有一些发现,我把lsof列出来的日志文件,查看filebeat打印的日志,发现有些日志文件是会在重命名后被 harversted(见图一)之后就不再打印它的信息,有些日志文件不会重新被harversted,但是会每隔10s打印“2020-05-13T16:54:03+08:00 INFO File is falling under ignore_older before harvesting is finished. Adjust your close_* settings:"信息,还有些日志文件什么消息都没打印。


图一
 

 很奇怪,如果close_renamed生效,则应该lsof出来的日志文件都会在重命名后重新被harversted(因为path配置的是*,处于扫描的范围)。
所以怀疑是否close_renamed对于filebeat 5.4而言会不生效。
 
还有一点,lsof列出的日志文件,删除后,会被filebeat占用长达1h,直到触发  close_timeout: 1h 这项配置才被释放,难道filebeat在这种场景下日志采集的速度变得非常慢吗?这其中如果日志文件被重新harversted的,那么日志会慢慢地被读取,而不被重新harversted的日志文件,则filebeat根本就不采集了。

要回复问题请先登录注册