logstash性能测试

日志从客户端应用被收集，到最终写入elasticsearh被用户搜索到需要在好几段网络的流转。首先从客户端（filebeat或rsyslog)到kafka，再由kafka到logstash，再从logstash到elasticsearch。我们要提高整个集群的性能，首先得有专门的性能测试。但性能测试不能直接做起点到终点的测试，因为当性能不如预期的时候，这种测试无法知道性能的瓶颈到底出现在整个pipeline的哪一段。因此，我们得分开测试，测试kafka的吞吐与速度，测试logstash的吞吐和filter的处理速度，测试elasticSearch的吞吐和索引速度。有了每个组件的基本性能指标，才能基本预估整个系统的性能，进而对不符合预期的系统性能进行优化。这里我们先讨论logstash的性能。

基线

单个应用软件的性能，取决于多个方面：
- 应用可以使用的硬件资源：cpu单核速度，cpu核数，系统内存，网络节点之间的传输速度（网卡速度）
- 应用分配到的硬件资源：应用可以使用的cpu核数， 应用分配到的系统内存

一般来说，当使用多核cpu的情况下，为了能够最大化的使用cpu资源，应用使用的线程数应该等于cpu的内核数量。而内存方面，在保证基本系统运行的前提下，应用应该使用尽可能多的内存。

当前，在云上的logstash节点所使用的机器是2c4g的配置。对应的，在logstash的配置方面：
lostash.yml:
pipeline.workers: 2 (不配置的情况下，默认是系统核数)
pipeline.output.workers: 2 （不配置的情况下，默认是1/2系统核数）

jvm.options:
-Xms512m
-Xmx2g

当然，这样的配置是相对较低的，我们应该在拿到最终的资源后，在对应资源上做基线测试。

生成测试数据(Generator)

实际运行的时候这个插件是派不上用途的，但这个插件依然是非常重要的插件之 一。因为每一个使用 ELK stack 的运维人员都应该清楚一个道理:数据是支