报价宝 › 科技 ›

ELK架构下利用Kafka Group实现Logstash的高可用

报价宝来源：baojiabao.com 发布时间：2019-09-01 21:57:00 11月16日更新

报价宝综合消息ELK架构下利用Kafka Group实现Logstash的高可用

系统运维的过程中，每一个细节都值得我们关注

下图为我们的基本日志处理架构

所有日志由Rsyslog或者Filebeat收集，然后传输给Kafka，Logstash作为Consumer消费Kafka里边的资料，分别写入Elasticsearch和Hadoop，最后使用Kibana输出到web端供相关人员检视，或者是由Spark接手进入更深层次的分析。

在以上整个架构中，核心的几个元件Kafka、Elasticsearch、Hadoop天生支援高可用，唯独Logstash是不支援的，用单个Logstash去处理日志，不仅存在处理瓶颈更重要的是在整个系统中存在单点的问题，如果Logstash宕机则将会导致整个丛集的不可用，后果可想而知

如何解决Logstash的单点问题呢？我们可以借助Kafka的Consumer Group来实现

Kafka Consumer Group

为了便于理解，我么先介绍一下Kafka里边几个重要的角色：

Broker：一台kafka服务器就是一个broker，一个kafka丛集由多个broker组成，上图中的kafka丛集有3台kafka服务器组成，也就是有3个broker，一个broker上可以有多个topic。

Topic：是个逻辑上的概念，用来区分不同的讯息类别，类似于数据库中的表，可以将一组相同的资料传送给一个Topic，在日志处理中通常会将不同型别的日志写入不同的Topic，例如nginx日志写入名字为 nginx_log 的topic，tomcat日志写入名字为 tomcat_log 的topic，topic上图中没有标出，我们可以理解为图上的三个partition构成了一个topic

Partition：是kafka资料储存的基本物理单元，同一个Topic的资料可以被储存在一个或多个partition中，例如上图中的一个topic资料被储存在了partition1，partition2，partition3中，通常我们设定一个topic下partition的数量为broker的整数倍，这样一来资料能够均匀分布，二来可以同时利用丛集下的所有服务器资源

Producer：生产者，向kafka写资料的服务，例如filebeat

Consumer：消费者，去kafka取资料的服务，例如logstash

Consumer Group：也是个逻辑上的概念，为一组consumer的集合，同一个topic的资料会广播给不同的group，同一个group中只有一个consumer能拿到这个资料

也就是说对于同一个topic，每个group都可以拿到同样的所有资料，但是资料进入group后只能被其中的一个consumer消费，基于这一点我们只需要启动多个logstsh，并将这些logstash分配在同一个组里边就可以实现logstash的高可用了

input {

kafka {

bootstrap_servers => "10.8.9.2:9092,10.8.9.3:9092,10.8.9.4:9092"

topics => ["ops_coffee_cn"]

group_id => "groupA"

codec => "json"

}

以上为logstash消费kafka丛集的配置，其中加入了 group_id 引数， group_id 是一个的字串，唯一标识一个group，具有相同 group_id 的consumer构成了一个consumer group，这样启动多个logstash程序，只需要保证 group_id 一致就能达到logstash高可用的目的，一个logstash挂掉同一Group内的logstash可以继续消费

除了高可用外同一Group内的多个Logstash可以同时消费kafka内topic的资料，从而提高logstash的处理能力，但需要注意的是消费kafka资料时，每个consumer最多只能使用一个partition，当一个Group内consumer的数量大于partition的数量时， 只有等于partition个数的consumer能同时消费 ，其他的consumer处于等待状态。

例如一个topic下有3个partition，那么在一个有5个consumer的group中只有3个consumer在同时消费topic的资料，而另外两个consumer处于等待状态，所以想要增加logstash的消费效能，可以适当的增加topic的partition数量，但kafka中partition数量过多也会导致kafka丛集故障恢复时间过长，消耗更多的档案控制代码与客户端内存等问题，也并不是partition配置越多越好，需要在使用中找到一个平衡

kafka partition

kafka中partition数量可以在建立topic时指定：

# bin/kafka-topics.sh --zookeeper 127.0.0.1:2181 --create --topic ops_coffee --partitions 3

Created topic "ops_coffee".

--partitions：指定分割槽数，如果不指定预设会使用配置档案中 num.partitions 配置的数量

也可以手动修改partition的数量：

# bin/kafka-topics.sh --alter --zookeeper 127.0.0.1:2181 --partitions 5 --topic ops_coffee

Adding partitions succeeded!

注意partition的数量只能增加不能减少

如果想要知道topic的partition资讯，可以通过以下命令检视topic详情：

# bin/kafka-topics.sh --zookeeper 127.0.0.1:2181 --describe --topic ops_coffee

Topic:ops_coffee PartitionCount:3 ReplicationFactor:2 Configs: