记录一次ELK集群优化

ELK性能测试及调优

基本情况

每台应用服务器上部署日志agent，监控多个日志目录，将目录下的日志收集到ELK-Redis服务器中缓冲，在ELK-Redis服务器上开启logstash对缓冲的日志解析并提交到ES集群存储。

 

每条日志包含日期，消息，5个关键字，ip，mac，用户名，进程号，服务名等共约17个字段；

每条日志约200~500Byte

生产环境中每天产生50GB日志，约2.5亿条；

 

测试目的

为验证及优化agent采集能力、ES集群处理能力及资源占用情况，进行此次性能测试。

环境信息

应用服务器	地址	CPU	RAM	日志文件数	日志文件行数
Linux	10.2.25.82	2	4G	2776	31745296
Linux	10.2.25.83	2	4G	2747	35109522
Linux	10.2.25.78	2	4G	695	45553768
Linux	10.2.25.79	2	4G	3036	35525706
AIX	10.2.251.111	12	8G	9932	77669711
AIX	10.2.251.112	12	8G	1402	71758203

 

ELK服务器	地址	CPU	RAM	备注
Redis-Linux	10.2.245.74	8	24G	运行logstash
ES-Linux	10.2.245.71	4	16G
ES-Linux	10.2.245.72	4	16G
ES-Linux	10.2.245.73	4	16G	后期改为Logstash
ES-Linux	10.2.245.68	4	16G	后期扩展
ES-Linux	10.2.245.69	4	16G	后期扩展
ES-Linux	190.2.245.70	4	16G	后期扩展

 

软件版本

软件	版本	备注
Elasticsearch	2.4.1	安装插件head，bigdesk
Logstash	2.4.0	AIX上使用java7 32bit，Linux上使用java8 64bit
Filebeat	5.2

 

其他软件如Redis，pv等不一一列出。

采集端性能

由于各应用服务器操作系统的差异，在Linux环境中使用filebeat采集，在AIX环境中暂时使用logstash采集。

Linux-Filebeat性能

默认配置

单个filebeat实例可采集15000条/秒，折合390GB/天，性能可以满足要求。

系统负荷启动时：

系统负荷稳定时：                                                                                                            

AIX-Logstash性能

默认配置

单个实例平均采集数：1300/s，折合38GB/天。

系统负荷启动时：

 

系统负荷稳定时：

 

调整redis输出配置

output {

         #stdout{ codec => rubydebug }

         redis{

                   host=> "10.2.245.74"

                   port=> 6379

                   db=> 0

                   data_type=> "list"

                   key=> "list_zzm1"

                   batch => true

                   batch_events => 2048

         }

}

 

单个实例平均采集数：8400/s，折合218GB/天。优化后，AIX下logstash采集性能提高约6倍。

消费端性能

Linux-Logstash性能

消费端性能即logstash的性能，由于可更改的参数较多，下面对各参数分别进行验证。

可调参数：

序号	参数	类别	说明
1	LS_HEAP_SIZE	LS	Logstash堆内存大小，默认1g
2	-w	LS启动	logstash线程数，默认与cpu数相同
3	-b	LS启动	Batch数，即logstash取多少数据进行一次filter，默认125
4	redis.threads	LS input	Redis线程数，默认1
5	redis.batch_count	LS input	Redis每次pop的数量，默认1
6	es.workers	LS output	Es提交线程，默认1
7	es.flush_size	LS output	ESbulk提交数，默认500

 

在ELK-Redis服务器上安装pv，配置logstash输出为dots和ES，启动方式为：

./logstash -f logstash_dots.conf | pv -abt> /dev/null

 

说明：

1）  由于logstash是java应用，启动过程中随着jvm内存使用提高其处理速率也逐渐提高；

2）  pv输出是平均值，而logstash启动过程约8秒，进一步造成显示速率的延迟，下表为启动3个logstash实例一段时间检测到的速率：

处理队列	5min后	10min后	20min后
List_zzm1	3.7k/s	4.5k/s	5.1k/s
List_u1z1	1.2k/s	1.6k/s	1.9k/s
List_ngp1	1k/s	1.2k/s	1.5k/s

3）  后续记录结果均采用开启3分钟后的数值；

4）  关闭ES输出配置，只输出到dots的情况下，单个logstash实例处理可达20k/s；

默认配置

输出速率：约2.5k/s

ES索引速率：

系统负荷：

 

启动参数-b 8000

输出速率：5.8k/s

ES索引速率：

系统负荷：

 

启动参数-w 16

输出速率：4.8k/s

ES索引速率：

系统负荷：

 

启动参数-w 16 –b 8000

输出速率：6k/s

ES索引速率：

系统负荷：

 

启动参数-w 16 –b 16000

输出速率：6k/s

ES索引速率：

输入Redis.threads=>8

输出速率：4.6k/s

ES索引速率：

系统负荷：

输入Redis.threads=>8 batch_count=>1024

输出速率：4.7k/s

ES索引速率：

 

输入Redis.threads=>8 batch_count=>10240

输出速率：4.7k/s

ES索引速率：

输出ES.workers =>8

输出速率：11.3k/s

ES索引速率：

系统负荷：

输出ES.flush_size=>4096

输出速率：4.6k/s

ES索引速率：

系统负荷：

 

增加workers =>8 flush_size=>4096

输出速率：12k/s

ES索引速率：

 

综合调整参数

启动参数–b 8192

输入Redis.batch_count=>1024

输出ES.workers=>8 flush_size=>4096

输出速率：8.4k/s

 

启动多个logstash实例

Agent输出到3个队列：

list_zzm1

list_u1z1

list_ngp1

开启3个logstash收集：

[PVVMBG0008][elk][/app/logstash-2.4.0/bin]#./logstash-f logstash_dots_zzm1.conf -l ./logstash_zzm1.log -b 8000 | pv -abt >/dev/null

6.19MiB 0:23:37 [4.86KiB/s]

[PVVMBG0008][elk][/app/logstash-2.4.0/bin]#./logstash-f logstash_dots_u1z1.conf -l ./logstash_u1z1.log -b 8000 | pv -abt >/dev/null

3.51MiB 0:24:15 [2.73KiB/s]

[PVVMBG0008][elk][/app/logstash-2.4.0/bin]#./logstash-f logstash_dots_ngp1.conf -l ./logstash_ngp1.log -b 8000 | pv -abt > /dev/null

3.69MiB 0:23:51 [2.64KiB/s]

 

输出速率：4.86+2.74+2.64≈10.2k/s

ES索引速率：

 

系统负荷：

此时，ES节点负荷：

  

优化后，消费端logstash性能提高约15倍。

测试记录

3节点2分片1副本

ES服务器	索引速率	折算结果
10.2.245.71	9k/s	Logstash：22/2=11k/s 处理时间：约6.5小时
10.2.245.72	8k/s
10.2.245.73	5k/s

 

4节点2分片1副本

ES服务器	索引速率	折算结果
10.2.245.71	8k/s	Logstash：34/2=17k/s 处理时间：4.1小时
10.2.245.72	8k/s
10.2.245.73	9k/s
10.2.245.75	9k/s

 

6节点3分片1副本

ES服务器	索引速率	折算结果
10.2.245.68	6k/s	Logstash：36/2=18k/s 处理时间：3.85小时
10.2.245.69	7k/s
190.2.245.70	6k/s
10.2.245.71	7k/s
10.2.245.72	5k/s
10.2.245.73	5k/s

 

5节点3分片1副本，增加一个logstash消费节点

ES服务器	索引速率	折算结果
10.2.245.68	7k/s	Logstash：39/2=19.5k/s 处理时间：3.56小时
10.2.245.69	7k/s
190.2.245.70	9k/s
10.2.245.71	9k/s
10.2.245.72	7k/s

 

 

总结

ES集群写入速率达到10k/s时，cpu、内存基本达到饱和。

Logstash(8cpu 24G RAM)处理速率达到15k/s时，cpu基本达到饱和。

 

ES集群3节点配置为2分片1副本存在数据分配不均匀的情况：

	索引1	索引2	索引3	索引4
ES-1	0	0 1	0	0
ES-2	0 1	1	1	0 1
ES-3	1	0	0 1	1

由于部分索引数据超大：

 

当某个节点分配到该索引的两个分片时，该节点成为集群的瓶颈，其他节点的索引速率小于该节点的索引速率（10k/s）。

 

配置为4节点后，索引分片分配相对均匀：

	索引1	索引2	索引3	索引4
ES-1	0	0	1	0
ES-2	0	1	1	1
ES-3	1	0	0	1
ES-4	1	1	0	0

4个节点写入速率能达到基本一致（10k/s）。

优化措施汇总

采集端

通过设置过滤器，仅保留xcom中包含Routing-async的日志

发送到redis使用批量提交batch=>true

Logstash配置max_open_files=>20000

Logstash配置sincedb_path=>sincedb_trace

Logstash配置congestion_threshold=>5000000

 

消费端

从redis读取使用批量读取

调整logstash内存LS_HEAP_SIZE=4G

调整logstash启动参数-b 8192

调整logstash输出到ES的批量数flush_size=>8192

开启多个logstash实例解析日志

 

Redis

设置maxmemory，避免内存不足引发崩溃

延长持久化间隔为5分钟

 

ES

内存设置ES_HEAP_SIZE=8G

threadpool设置bulk队列增大

GC方式改为G1

 

架构

2个专门数据节点，3个数据+备用主节点

Logstash改为2节点

 

其他问题

Redis内存问题

Redis服务器目前内存24G，开启3个logstash占用12G，保留2G给操作系统，仅剩余10G供redis使用。每条日志（json格式）约650B，152万条日志/GB内存。测试中Redis可能会因内存不足而崩溃（实际测试中，开启采集端几分钟后redis的内存就会跑满）。

当redis占用内存超出后，采集端会报错：

ERR Failed to RPUSH to redis list with OOMcommand not allowed when used memory > 'maxmemory'.

 

1）  filebeat会一直尝试，直到发布成功；

2）  Logstash添加配置：congestion_threshold => 5000000，会实时检查队列长度，如果超过则阻塞。

 

Redis队列问题

实际测试发现，logstash提交到redis的“能力”弱于filebeat。运行一段时间后，filebeat产生的队列增加比较快，logstash产生的队列则慢慢消耗完，导致后续无法获取数据。

考虑改变elk架构，增加一个logstash解析节点，专门接收filebeat日志队列。

 

Logstash解析能力问题

增加的10.2.245.73（4CPU,16G RAM）处理能力：约7k/s

原10.2.245.74（8CPU,24G RAM）处理能力：约12k/s

共计19k/s。

以50GB日志计算，约需要：(50/200)/(3600*19200)≈3.6小时

ES full GC问题

执行一次full GC可能超过半个小时，GC期间节点的cpu内存资源占满，会影响整个集群的读写。暂时没有解决办法。

 

ES reject bulk request问题

在head中查看节点状态：

当设置的提交worker数过多，会造成队列拥堵，超过50时直接拒绝请求且不可恢复。

解决办法：

curl -XPUT '10.2.245.71:9200/_cluster/settings'-d '{

   "transient": {

       "threadpool.index.type": "fixed",

       "threadpool.index.size": 8,

       "threadpool.index.queue_size": 500

    }

}'

同时减少logstash输出的worker数量，加大flush_size，进一步观察。

写在最后：

网络上很多此类调优文章，很多选项试了报错或没用，比如_source字段设置为compress，比如上文中threadpool.index.size其实设置了也没用，看ES日志里面会将这个值改回处理器数量。当然，这些和ELK软件版本可能有关系。所以，本文中的结论仅供参考。