Logstash优化心得

版权声明：本文为原创文章，未经博主允许不得转载。重点内容

背景

前些时间测试线上ELK环境，发现beats组件直连elasticsearch数据灌入异常快，但是过了logstash数据明显迟缓。判定logstah的灌入存在瓶颈。以下为logstash调优细节。

环境

本次针对的优化对象是线上的日志分析平台，主要数据源为metricbeat和filebeat（基础服务器数据和应用日志）

• ES节点：顶配3点集群，各方面负载不高，无写入瓶颈
• logstah节点：2个汇聚端，
• 网络：内网万兆传输，无瓶颈
• 数据量（条）：2~3w/s，每天约两亿多

架构

分析

logstah的功能是一个管道，通过input灌入数据，filter过滤数据，output输入数据

• input：filebeat和metricbeat总连接数为500左右，且观察日志无retry 或 timeout等输出，无明显瓶颈
• filter和output：logstash的正则解析过程非常消耗资源，但是我们的节点资源消耗居然不高。在新版的logstash中优化了input，filter，output的线程模式，在配置文件中可以通过配置pipeline.workers来调整filter和
  output的线程数

网友的测评数据是两个点的logstah可以承受600+的连接数。但是我懒，未验证。

优化

查询官网手册后，最影响logstah传输效率的参数有以下几个：

1. pipeline.workers：决定filter和output的线程数，官方建议大于CPU数，如果logstah节点是混用服务器，建议等于或小于CPU数
2. pipeline.batch.size：单个线程每次调用ES bulk index API时的事件数。这些时间将被放到内存中。最好的设定值是不断地测试，测试，测试。
3. JVM_heap：内存堆大小，通过配置jvm_option来修改。

结果

我的配置是：

pipeline.workers: 30
pipeline.output.workers: 30
pipeline.batch.size: 2500
pipeline.batch.delay: 5
---JVM_conf
-Xms32g
-Xmx32g

由于我的CPU为20核，稍微增加了线程数为30核，pipeline.batch.size由默认的150修改为2500。由于我的机器配置比较高，配置32G内存来换取更好的性能。

• 公式

logstash在过滤过程中会将输入的数据放入内存中，规则如下：

pipeline.workers * pipeline.batch.size / flush_size = ES bulk index API 调用数

优化结果

调优后的传输数据如下：

• 上浮部分为优化后