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:
	Topic: ops_coffee	Partition: 0	Leader: 1	Replicas: 1,2	Isr: 1,2
	Topic: ops_coffee	Partition: 1	Leader: 2	Replicas: 2,3	Isr: 2,3
	Topic: ops_coffee	Partition: 2	Leader: 3	Replicas: 3,1	Isr: 3,1
复制代码

至此对kafka consumer group有了更深刻的了解，能够在具体的使用中游刃有余

---

相关文章推荐阅读：

• ELK构建MySQL慢日志收集平台详解
• ELK日志系统之使用Rsyslog快速方便的收集Nginx日志
• ELK日志系统之通用应用程序日志接入方案
• Logstash读取Kafka数据写入HDFS详解
• Filebeat的Registry文件解读
• Elasticsearch Query DSL查询入门