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、 启动未做任何操作
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。
注意：以上性能并没有实际测试，只是通过官网或者其他来源得出的结论，只限参考。