Fluentd部署：高可用配置
對於高訪問量的web站點或者服務，可以採用Fluentd的高可用配置模式。
- 訊息分發語義
Fluentd設計初衷主要是用作事件日誌分發系統的。這類系統支援幾種不同的分發模式：
- 至多一次。訊息被立即傳送，若傳輸成功，該訊息不會再被髮送。傳送失敗，則會導致訊息丟失。現實環境下會有很多情況導致傳送失敗，比如網路暫時不可用。
- 至少一次。訊息至少會被髮送一次，若傳送失敗，訊息會被重發。這保證了訊息不會被丟失，但可能導致接收端收到重複的訊息。
- 精確只發一次。訊息剛好傳送一次，能確保送達且不會重複。這是大家所期望的分發模式。實現此模式可能需要採用同步化的日誌處理方式，當達到傳送瓶頸時，告知業務層已無法接收更多的日誌。
為了在不影響業務效能的情況下收集大量的日誌，日誌層必須以非同步的方式執行。因此，Fluentd只提供了前兩種傳輸模式。
- 網路拓撲
為使得Fluentd具備高可用性，典型的部署架構需要包含兩種不同角色的Fluentd模組：轉發器（forwarder）和聚合器（aggregator）。其拓撲結構如下圖所示
轉發器部署在業務節點，用於收集業務方產生的本地日誌事件，並將事件傳送至聚合器。
聚合器持續地從轉發器接收日誌，對日誌進行快取，並定期上傳日誌到下一個處理方（典型的就是儲存）。
聚合器採用主備模式。如上圖，192.168.0.1為主，192.168.0.2為備。
- 轉發器配置
轉發器的典型配置如下所示：
# TCP input <source> @type forward port 24224 </source> # HTTP input <source> @type http port 8888 </source> # Log Forwarding <match mytag.**> @type forward # primary host <server> host 192.168.0.1 port 24224 </server> # use secondary host <server> host 192.168.0.2 port 24224 standby </server> # use longer flush_interval to reduce CPU usage. # note that this is a trade-off against latency. <buffer> flush_interval 60s </buffer> </match>
這裡有兩個輸入源，使用forward外掛將日誌事件傳送到兩個聚合器server中，其中通過standby指定192.168.0.2為備用聚合器。若兩個聚合器節點都不可用，日誌將會快取在轉發器節點。
- 聚合器配置
聚合器的典型配置如下所示：
# Input
<source>
@type forward
port 24224
</source>
# Output
<match mytag.**>
...
</match>
這個比較簡單，使用forward外掛作為輸入源。日誌會在本地快取，並通過重傳機制確保能送達目的地。
- 失敗場景提示
5.1 轉發失敗
轉發器收到應用層的日誌事件後，先將事件寫入本地磁碟快取（由buffer_path指定）。每個flush_interval到來時，快取事件被轉發至聚合器。
轉發器程序若發生崩潰，程序重啟後會自動重發已快取的日誌；轉發器和聚合器網路若發生故障，轉發器也會對日誌進行重傳。這在一定程度上保證了轉發器的健壯性。
但仍有一些情況可導致資料丟失：
- 轉發器收到業務層日誌，在將日誌寫入快取之前發生崩潰
- 磁碟損壞
5.2 聚合失敗
聚合器採用和轉發器相同的失敗處理機制，失敗場景類似。
- 錯誤排查
採用此架構進行部署時，有時候會遇到“no nodes are available”的錯誤提示。這可能是節點間網路不通導致的。需要注意的是，節點之間通過24224埠傳輸資料，既使用TCP，也會使用UDP。
可通過以下命令進行檢查：
$ telnet host 24224
$ nmap -p 24224 -sU host