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