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