Logstash及Elasticsearch 压力测试说明书(十)

96
橡皮24
0.2 2018.11.09 18:47* 字数 2603

1 整体环境说明

1.1 硬件环境

1、 磁盘:SATA磁盘2块,磁盘阵列为RAID1

2、 CPU****:2个4核CPU。具体参数:Intel(R) Xeon(R) CPU E5405 @ 2.00GHz

3、 内存:8G(8*1G)

4、 网卡:1000Mb/s

1.2 软件环境

1、 kafka版本:kafka_2.11-0.11.0.3

2、 kafka集群数量:3

3、 logstash版本:logstash-5.6.11

4、 elasticsearch版本:elasticsearch-5.6.11

5、 elasticsearch集群数量:3

1.3 服务器自身瓶颈

由kafka性能测试得出结论。服务器SATA磁盘2块,磁盘阵列为RAID1的配置。磁盘写入数据瓶颈为94.8 MB/秒。读取数据瓶颈经过磁盘cache的磁盘读取为162.83 MB/秒,未经过磁盘cache的磁盘读取为106.88 MB/秒。

网卡瓶颈为1000Mb/s=125MB/s。

2 logstash测试前期准备

2.1 影响测试结果配置分析

Logstash的性能测试主要测试logstash在kafka集群消费消息的数量,和logstash在对日志进行过滤之后向elasticsearch输出的数量。

Elasticsearch性能测试主要测试从logstash传输过来的数据进行接收的速度。

2.1.1 Logstash分析

1、--pipeline-workers参数(-w)

此参数是filter和output模块的pipeline的线程,默认是cpu核数。

2、--pipeline-batch-size参数(-b)

是每个logstash pipeline线程,越大会越消耗JVM内存。是积累多少条日志进行向下传输。默认是125条。

3、jvm的大小。

4、多个logstash消费传输的速度。

注意:因为在ELK中只能使用filter过滤模块,所以不对过滤模块进行测试。

2.1.2 Elasticsearch分析

1、 提交文件的大小

也就是logstash--pipeline-batch-size的参数。所以可以一起测试

2、 jvm的大小

2.2 测试相关解释

2.2.1 命令解释

# ./bin/logstash -w 1 –b 1000 -f ./config/conf/test.conf --path.data=./test_pid/ | pv -abt > /dev/null

1、使用pv命令如果请yum直接安装,如果版本过低不支持a选项需要源码安装更新版本的pv命令。

2、-w为--pipeline-workers

3、-b为--pipeline-batch-size

2.2.2 配置文件解释

1、配置文件一

# cat test.conf

input {

 generator {

 count => 10000000

 message => '{"indexdiy":"catalina","input_type":"log","message":"[2018-09-26 12:30:13,030] [org.apache.tomcat.util.net.NioSelectorPool] [INFO] [Using a shared selector for servlet write/read]","offset":17600578,"project_tag":"catalina","source":"/opt/tomcat7/logs/catalina.out","type":"log"}'

 }

}

filter {

 json {

 source => "message"

 }

 mutate {

 gsub => ["message", "\n", ""]

 }

 grok {

 match => { "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{JAVACLASS:class}\] \[%{LOGLEVEL:level}\] \[%{GREEDYDATA:logmessage}"}

 }

 date {

 match => ["timestamp", "yyyy-MM-dd HH:mm:ss,SSS"]

 target => "@timestamp"

 }

}

output {

 stdout {

 codec => dots

 }

 elasticsearch {

 hosts => ["10.10.4.11:9200","10.10.4.12:9200","10.10.4.13:9200"]

 index => "test12_1"

 }

 kafka {

 bootstrap_servers => "10.10.4.11:9092,10.10.4.12:9092,10.10.4.13:9092"

 topic_id => "yace1013_1"

 }

}

配置文件解释:

Generator模块为自动创建消息模块。

Count为创建多少条消息。

Message为消息内容,此消息内容为tomcat的一条日志文件,大约300B。

Filter为过滤模块。

Codec为把每条消息都输出一个点(·),一个点的大小为1B

Elasticsearch为输出到es集群。

Kafka是输出到kafka集群,为了后期在kafka中消费。

3、 配置文件二

input {

 kafka {

 bootstrap_servers => "10.10.4.11:9092,10.10.4.12:9092,10.10.4.13:9092"

 topics => "catalina"

 group_id => "2s"

 }

}

filter {

 json {

 source => "message"

 }

 mutate {

 gsub => ["message", "\n", ""]

 }

 grok {

 match => { "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{JAVACLASS:class}\] \[%{LOGLEVEL:level}\] \[%{GREEDYDATA:logmessage}"}

 }

 date {

 match => ["timestamp", "yyyy-MM-dd HH:mm:ss,SSS"]

 target => "@timestamp"

 }

}

output {

 stdout {

 codec => dots

 }

}

配置文件解释:

Input为在kafka里消费消费数据。要先使用脚本在catalina.out里写上很多数据。

注意:要先启动下消费脚本在停止,这样logstash才可以订阅到kafka的topic。不让会因为没有订阅topic而不能消费。

其他不在赘述

2.2.3 输出结果解释

如果使用codec => dots(默认都使用方便计算),就是把每一条日志都转换为点(·)一个点是1Byte,如果结果为[5.53kiB/s],就是每秒钟5530条/秒。

注意:不同测试环境需要相应的注释一些模块

2.3 注意情况

1、 在测试的时候如果集群搭建在同一台服务服务器上,需要停止其他的服务,比如说,测试logstash消费kafka的能力,要把elasticsearch关掉,因为elasticsearch很消耗内存。会造成不准确的结果。

2、 在测试的时候时刻观察着服务器自身的瓶颈,如IO瓶颈,内存瓶颈、CPU瓶颈等。

3 Logstash本身性能测试

3.1 测试–w参数

1、结果如下表


2、CPU负载如下:

(1)-w为1


(2)-w为2


(3)-w为4


(4)w为6


(5)w为8


3、 磁盘IO使用情况(由于直接在输出了,并没有使用磁盘)


4、内存使用情况


3.2 -w参数总结

-w参数为--pipeline-workers,从结果可以看出-w参数根据自身cpu核数相关,实验服务器cpu总核数为8核,所以-w为6的时候性能最高,-w为8的时候性能反而会下降。cpu的负载也跟-w参数相关。服务器内存占用率也是比较大的。所以测试并没有测出logstash本身的性能所在,被cpu的核数限制。只有更多核数的服务器才能测试出logstash的准确性能。

3.3 –b参数测试

1、 结果如下表

由于-w选项为6的时候是服务器的一个瓶颈,所以测试-b的时候性能会下降,是服务器的原因,所以我们以-w为4进行测试。


2、 cpu负载


3、内存使用情况


3.4 -b参数总结

从结果可知,-b选项是依赖服务器本身性能的,没有一个确定的值。在测试服务区配置,-b的值为500的时候是最优的。这个最优值需要根据实际情况进行测试。

3.5 Jvm大小

修改jvm.options配置文件

1、 结果如下表


2、cpu负载


2、 内存使用情况

(1)jvm为1G


(2)jvm为2G


3.6 Jvm大小总结

Jvm参数对logstash的性能特别小,按照正常来说,一般设置2-4G为最佳。如果内存特别大可以考虑再增加。

4 Logstash消费kafka性能测试

由于机器数量有限,我在kafka一个节点上部署的logstash,由于一起工作可能会影响测试结果

4.1 Logstash数量

1、结果如下表


其中logstash为2的时候,13.1kiB/s数据为kafka节点上的logstash。

3、 CPU负载


4.2 Logstash数量总结

如果多个logstash在kafka里消费不会影响消费的速度,这样可以保证在日志特别多的时候可以横向扩展logstash来提高性能。从而解决logstash的瓶颈问题。但是要注意消费者组的分配,如果logstash的数量少于kafka的partition,可以随便分配。如果logstash的数量多于kafka的partition。需要分不同的消费者组去消费。不然会有消费者无法消费到数据。详细请看kafka性能测试文档。

5 Elasticsearch性能测试

Elasticsearch性能测试主要是测试自身性能,也就是logstash在往kafka里写入数据时候的速度,和自身的服务器瓶颈去观察elasticsearch的瓶颈所在。

5.1 Logstash向elasticsearch写入数据测试

由于机器数量问题,在elasticsearch节点上开启一个logstash,由于一起工作可能会影响测试结果。

5.1.1 logstash的数量

1、 结果如下表


其中6.04kiB/s的数据来自和elasticsearch节点在一起的logstash数据。

2、 CPU负载情况


3、 内存使用情况


5.1.2 Jvm大小总结

测试过jvm为2G和4G性能测距几乎没有,由于elasticsearch运行消耗很大的性能。所以在这里不详细说明,有更好配置的机器在进行测试。

5.1.3 elasticsearch自身测试

使用bigdisk插件对elasticsearch进行监控,发现只要elasticsearch启动,机器内存就被消耗了6.8G。只要有写入操作,内存就会到达7.5G。所以测试机器性能太差,需要更大的内存的服务器进行测试。

1、 启动未做任何操作


i

2、写入数据


5.2 Logstash向elasticsearch写入数据总结

由于logstash特别消耗cpu,elasticsearch特别消耗内存,而在两个logstash传入elasticsearch的时候logstash和elasticsearch在同一台服务器上,所以测试数据并不是特别准确。需要性能更好的服务器来进行测试。

6 Logstash和elasticsearch整体总结

6.1 Logstash总结

在测试环境机器硬件环境下。在logstash消费kafka的情况下单节点logstash的速度为14000条/秒,自身消费的速度为20000条/秒,输出到elasticsearch的速度为7430条/秒。

6.1.1 Logstash的性能

1、-b选项也就是--pipeline-batch-size参数,这是一个不确定的参数,越大会越消耗JVM内存。是积累多少条日志进行向下传输。这个可以根据实际情况进行测试之后得出结论。

2、-w选项也就是--pipeline-workers参数,此参数是filter和output模块的pipeline的线程,理论来说越大越好,但是不能超过cpu的总核数,因为-w选项越大,消耗cpu性能也就越多。所以实际情况下根据服务器的总核心数进行设置。

3、jvm的大小对logstash影响并不是特别大,在生产环境建议给2-4G。

6.2 Elasticsearch总结

Elasticsearch消耗内存严重,所以测试的数据并没有测试出elasticsearch的性能瓶颈所在点。

6.2.1 Elasticsearch性能

由于elasticsearch类似数据库,并且写入量特别大,一般在elk上不会成为瓶颈。主要优化还在于索引方面。

1、 bulk的参数,此参数相当于数据库里的bash操作。引入批量操作bulk,可以提高工作效率。但是由于机器性能无法测试。

2、 内存要求很高,elasticsearch要求内存很高,一般建议在32G以上。

3、 在内存要求满足的情况下,磁盘会成为瓶颈。官方建议使用SSD。

注意:以上性能并没有实际测试,只是通过官网或者其他来源得出的结论,只限参考。

ELK(新)
Web note ad 1