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。

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