ELK架構下利用Kafka Group實現Logstash的高可用

運維咖啡吧發表於2019-07-04
架構Kafka

系統運維的過程中，每一個細節都值得我們關注

下圖為我們的基本日誌處理架構

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

ELK架構下利用Kafka Group實現Logstash的高可用

為了便於理解，我麼先介紹一下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有了更深入的瞭解，可以在具體的使用中游刃有餘

掃碼關注公眾號檢視更多實用文章

相關文章推薦閱讀：

相關文章