KafKa+Logstash日志收集系统的吞吐量存在问题分析思路

　　KafKa+Logstash日志收集系统的吞吐量存在问题分析思路

　　公司的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、新版插件没有主机和端口配置。已改为hosts：["127.0.0.1:9200"]

　　2、新版本配置中没有协议配置

　　在运行logstash的过程中，命令中有一个参数-l logs，用于配置日志目录logs。我没有手动创建这个目录，所以没有生成日志，也没有找到一开始的日志文件。一旦有日志，提示配置文件的问题，新版本的logstash和两个插件的配置很容易。

　　但是配置后，新版本logstash的吞吐量有所增加，但是在数据量大且增加比较快的情况下还是会有数据堆积，所以问题还是没有解决。

　　以下分析思路：

　　1、 观察logstash的消费过程，发现Kafka中的数据平衡性很差，少数节点数据量大，增长快，大部分节点几乎没有数据，所以logstash的多-threaded to node partition 在进程中摄取数据并不会大大提高性能。由于logstash使用的是fetch方式进行数据消费，感觉每个线程都会不断从Kafka中取数据。发现没有数据后，过一段时间再去取。虽然这些分区中没有数据，但还是会占用一部分cpu去取数据，这会影响到有数据的线程。如果可以知道哪个节点有数据，那么所有的CPU资源都给了这些节点，这些节点的数据抓取效率会快很多。目前的情况是每个partition分配一个cpu core，其中2/3的core在不停的读但是不能读数据，只有1/3的cpu在读，浪费了计算资源。

　　上面的想法是傻瓜式。 . 不是每个分区都分配一个线程，即一个核心绑定到这个线程。线程申请cpu的计算资源，从所有核申请。一个线程对应的分区中没有数据，那么这个线程如果没有占用CPU资源，或者说剩余的CPU资源可以被其他线程使用。注意：线程绑定的是cpu的计算资源，不是线程绑定的核。所以有些分区的数据很少，Kafka的负载均衡不好，从它消费数据不会影响logstash的速度。问题可能还是在于logstash向ES写入数据的速度。

　　2、 通过工具观察Elasticsearch的索引速度。如果很慢，很可能是logstash的输出链接影响了吞吐量。