公司的KafKa+Logstash+Elasticsearch日志收集系统的吞吐量存在问题，logstash的消费速度跟不上，造成数据堆积；
三者的版本分别是：0.8.2.1、1.5.3、1.4.0
数据从KafKa中消费，采用的是logstash-input-kafka插件，输出到Elasticsearch中采用的是logstash-output-Elasticsearch插件。
对于两个插件分别进行了一定的配置，参照了下面的博客：点击打开链接
但是问题并没有得到解决，消费的速度没有什么提升，或者说提升很小，还有数据堆积。考虑到使用的logstash版本以及插件的版本比较低，所以进行了版本升级：
在logstash的网站上下载了集成所有插件的2.3.4版本的logstash，配置的过程中遇到了以下问题：
Elasticsearch插件的配置：
1、新版本的插件没有host和port配置，改成了hosts：["127.0.0.1:9200"]
2、新版本的配置中没有protocol配置
在运行logstash的过程中，命令中有参数-l logs，用来配置log的目录logs，我没有手动创建这个目录，所以日志一直没有生成，开始一直没有找到日志文件，一旦有了日志，其中就提示了配置文件的问题，很容易就将新版本的logstash以及两个插件配置好了。
但是配置好之后，新版本的logstash的吞吐量有所上升，但是在数据量大、上升比较快的时候仍然会有数据堆积，所以问题还是没有解决。
下面的分析思路：
1、观察logstash的消费过程发现，kafka的中的数据均衡很差，少部分节点中的数据多，增长快，大部分节点中几乎没有数据，所以logstash的多线程到节点的分区中取数据，对于性能的提升不大。由于logstash对于数据的消费采用的是fetch的方式，个人感觉：每个线程会不断的去kafka中取数据，发现没有数据之后，在过一段时间之后又会去取，虽然这些分区中没有数据，但是仍然占用了一部分cpu去取数据，这反而会影响到有数据的线程。如果可以知道哪个节点上有数据，将cpu资源都给这几个节点，针对这几个节点进行数据抓取，效率会快很多。现在的情况是，每个分区都分配了一个cpu核心，其中2/3的核心是在不断去读却读不到数据，只有1/3的cpu在读取，这对于计算资源是很浪费的。
上面的想法是傻逼的。。。并不是每个分区分配一个线程，就是将一个核心绑定给了这个线程，线程申请的是cpu的计算资源，是从所有的核心中去申请，一个线程对应的分区中没有数据，那么这个线程就不占用cpu资源，或者说占用的很少，那么剩余的cpu资源就可以给别的线程用。注意：线程绑定的是cpu的计算资源，并不是一个线程绑定一个核心。所以说某些分区中数据少，kafka的负载均衡不好，并不会怎么影响logstash从中消费数据的速度。问题可能还是存在于logstash向ES中写数据的速度。
2、通过工具观察一下Elasticsearch的索引速度，如果很慢，很可能是logstash的output环节影响到了吞吐量。