系统运维的过程中, 每一个细节都值得我们关注
下图为我们的基本日志处理架构
所有日志由 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 有了更深入的了解, 可以在具体的使用中游刃有余
来源: https://www.cnblogs.com/37Y37/p/11130295.html