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查詢入門