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

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

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

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

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有了更深入的瞭解,可以在具體的使用中游刃有餘


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

相關文章推薦閱讀:

相關文章