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

最新推荐文章于 2024-07-27 00:06:07 发布

点火三周

最新推荐文章于 2024-07-27 00:06:07 发布

阅读量1.4w

点赞数 9

分类专栏： ELK 点火三周的Elastic Stack专栏文章标签： filebeat 内存泄漏调优

本文链接：https://blog.csdn.net/u013613428/article/details/84557827

版权

本文详述了filebeat在监控大量文件、频繁rotate日志和由于multiline配置不当导致的内存泄漏问题。通过filebeat日志和pprof工具，分析内存使用情况，并提供调优建议，包括合理配置避免通配符监控过多文件，优化multiline策略，限制filebeat进程资源等。

摘要由CSDN通过智能技术生成

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