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软件版本可能有关系。所以,本文中的结论仅供参考。