记filebeat内存泄漏问题分析及调优

ELK 从发布5.0之后加入了beats套件之后，就改名叫做elastic stack了。beats是一组轻量级的软件，给我们提供了简便，快捷的方式来实时收集、丰富更多的数据用以支撑我们的分析。但由于beats都需要安装在ELK集群之外，在宿主机之上，其对宿主机的性能的影响往往成为了考量其是否能被使用的关键，而不是它到底提供了什么样的功能。因为业务的稳定运行才是核心KPI，而其他因运维而生的数据永远是更低的优先级。影响宿主机性能的方面可能有很多，比如CPU占用率，网络吞吐占用率，磁盘IO，内存等，这里我们详细讨论一下内存泄漏的问题

filebeat是beats套件的核心组件之一（另一个核心是metricbeat），它一般和生成被采集文件（主要是日志）的程序安装在一个地方，根据官方的建议，是filebeat是不建议用来采集NFS（网络共享磁盘）上的数据的。当filebeat运行起来之后，必定会对cpu，内存，网络等资源产生一定的消耗，当这种消耗能够限定在一个可接受的范围时，我觉得没人会限制你在生产环境上使用filebeat。但如果出现一些非预期的情况，比如占用了大量的内存，那么运维团队肯定是优先保障核心业务的资源，把filebeat进程给杀了。很可惜的是，内存泄漏的问题，从filebeat的诞生到现在就一直没有完全解决过，无论是什么版本（最新的6.5版本暂时还没有观测到）在不同场景和配置下，均出现内存占用过多的问题。在这里，我主要描述一下我碰到的在filebeat 6.0上遇到的问题。

问题场景和配置

我们使用了一套统一的简单配置监控了很多的主机，正是这种无差异化的简单配置，造成了问题。这是不对的，这是不对的，这是不对的！！！ 合理的方式是具体问题具体分析，针对不同的场景是做定制化的配置。

• multiline，多行的配置，当日志文件不符合规范，大量的匹配pattern的时候，会造成内存泄漏
• max_procs，限制filebeat的进程数量，其实是内核数，建议手动设为1

filebeat.prospectors:
- type: log
  enabled: true
  paths:
    - /qhapp/*/*.log
  tail_files: true
  multiline.pattern: '^[[:space:]]+|^Caused by:|^.+Exception:|^\d+\serror'
  multiline.negate: false
  multiline.match: after
  fields:
    app_id: bi_lass
    service: "{
   { hostvars[inventory_hostname]['service'] }}"
    ip_address: "{
   { hostvars[inventory_hostname]['ansible_host'] }}"
    topic: qh_app_raw_log

filebeat.config.modules:
  path: ${
   path.config}/modules.d/*.yml
  reload.enabled: false

setup.template.settings:
  index.number_of_shards: 3
  #index.codec: best_compression
  #_source.enabled: false
output.kafka:
  enabled: true
  hosts: [{
   {
   kafka_url}}]

  topic: '%{[fields][topic]}'

max_procs: 1

注意，以上的配置中，仅仅对cpu的内核数进行了限制，而没有对内存的使用率进行特殊的限制。从配置层面来说，影响filebeat内存使用情况的指标主要有两个：

• queue.mem.events消息队列的大小，默认值是4096，这个参数在6.0以前的版本是spool-size，通过命令行，在启动时进行配置
• max_message_bytes 单条消息的大小, 默认值是10M

filebeat最大的可能占用的内存是max_message_bytes * queue.mem.events = 40G，考虑到这个queue是用于存储encode过的数据，raw数据也是要存储的，所以，在没有对内存进行限制的情况下，最大的内存占用情况是可以达到超过80G。

因此，建议是同时对filebeat的CPU和内存进行限制。

下面，我们看看