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

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

所有日志由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架构下利用Kafka Group实现Logstash的高可用的更多相关文章

  1. RHEL 5.4下部署LVS(DR)+keepalived实现高性能高可用负载均衡

    原文地址:http://www.cnblogs.com/mchina/archive/2012/05/23/2514728.html 一.简介 LVS是Linux Virtual Server的简写, ...

  2. Centos 7 下 Corosync + Pacemaker + psc + HA-proxy 实现业务高可用

    一.介绍: 1.本博客Corosync + Pacemaker + psc + HA-proxy 实现业务高可用,以httpd 服务实现高可用为例. 2.架构思路 a.三台web 节点,功能:全部安装 ...

  3. RHEL 5.4下部署LVS(DR)+keepalived实现高性能高可用负载均衡(转)

    一.简介 LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统.本项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一. ...

  4. CentOS 6.3下部署LVS(NAT)+keepalived实现高性能高可用负载均衡

    一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2.6.32-279.el6.i686 LVS版本:ipvsadm-1.26 keepalive ...

  5. 转载--CentOS 6.3下部署LVS(NAT)+keepalived实现高性能高可用负载均衡

    源地址:http://www.cnblogs.com/mchina/archive/2012/08/27/2644391.html 一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台: ...

  6. CentOS 6.3下部署LVS(NAT)+keepalived实现高性能高可用负载均衡【转】

    CentOS 6.3下部署LVS(NAT)+keepalived实现高性能高可用负载均衡   一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2 ...

  7. CentOS 6.3下部署LVS(NAT)+keepalived实现高性能高可用负载均衡(转)

    一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2.6.32-279.el6.i686 LVS版本:ipvsadm-1.26 keepalive ...

  8. ELK 架构之 Elasticsearch、Kibana、Logstash 和 Filebeat 安装配置汇总(6.2.4 版本)

    相关文章: ELK 架构之 Elasticsearch 和 Kibana 安装配置 ELK 架构之 Logstash 和 Filebeat 安装配置 ELK 架构之 Logstash 和 Filebe ...

  9. Kafka学习笔记-如何保证高可用

    一.术语 1.1 Broker Kafka 集群包含一个或多个服务器,服务器节点称为broker. broker存储topic的数据. 如果某topic有N个partition,集群有N个broker ...

随机推荐

  1. Cache memory power reduction techniques

    Methods and apparatus to provide for power consumption reduction in memories (such as cache memories ...

  2. 希尔伯特空间(Hilbert Space)

    欧氏空间 → 线性空间 + 内积 ⇒ 内积空间(元素的长度,元素的夹角和正交) 内积空间 + 完备性 ⇒ 希尔伯特空间 0. 欧几里得空间 欧氏空间是一个特别的度量空间,它使得我们能够对其的拓扑性质, ...

  3. Codeforces Beta Round #7--D. Palindrome Degree(Manacer)

    题目:http://blog.csdn.net/winddreams/article/details/44218961 求出每一个点为中心的最长字符串,推断该串是不是从开头的回文串. #include ...

  4. 使用python移动飞信模块发送短信

    作者:miaoo 1.应用场景 由于自己做的一个系统需要用到发送短信到自己手机的功能,于是搜索了一下,发现了一个通过移动飞信通道发送短信开源库:PyFetion PyFetion 模拟实现了飞信的通信 ...

  5. WPF Windows背景透明其中的文字保持不透明

    原文:WPF Windows背景透明其中的文字保持不透明 版权声明:本文为博主原创,未经允许不得转载.交流.源码资料加群:161154103 https://blog.csdn.net/mpegfou ...

  6. [AC自己主动机+可能性dp] hdu 3689 Infinite monkey theorem

    意甲冠军: 给n快报,和m频率. 然后进入n字母出现的概率 然后给目标字符串str 然后问m概率倍的目标字符串是敲数量. 思维: AC自己主动机+可能性dp简单的问题. 首先建立trie图,然后就是状 ...

  7. MIT墙上的格言(如果你把任务留到最后一分钟,那么你一定能在一分钟内完成任务)

    1,永远不能忘记傅立叶变换. Never far no can forget Fuliye changer. 2,盲目的研究者就像法拉第和麦克斯韦之间的电学家一样无所适从. Blind Eye's r ...

  8. Swift 中使用 SwiftyJSON 制作一个比特币价格 APP

    Swift 中处理 JSON 数据有很多种方式,可以使用原生的 NSJSONSerialization,也可以使用很多第三方库.原生的 NSJSONSerialization 方式这篇文章中介绍过.这 ...

  9. Apache Cordova介绍

    原文:Apache Cordova介绍 Apache Cordova是一套设备API,允许移动应用的开发者使用JavaScript来访问本地设备的功能,比如摄像头.加速计.它可以与UI框架(如jQue ...

  10. 微信小程序把玩(二)window配置

    原文:微信小程序把玩(二)window配置 window用于设置小程序的状态栏.导航条.标题.窗口背景色.注意在app.json中配置的属性会被子window属性覆盖 只需在app.json配置即可