您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關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插件作為輸入源。日志會在本地緩存,并通過重傳機制確保能送達目的地。
失敗場景提示
轉發失敗
轉發器收到應用層的日志事件后,先將事件寫入本地磁盤緩存(由buffer_path指定)。每個flush_interval到來時,緩存事件被轉發至聚合器。
轉發器進程若發生崩潰,進程重啟后會自動重發已緩存的日志;轉發器和聚合器網絡若發生故障,轉發器也會對日志進行重傳。這在一定程度上保證了轉發器的健壯性。
但仍有一些情況可導致數據丟失:
轉發器收到業務層日志,在將日志寫入緩存之前發生崩潰
磁盤損壞
聚合失敗
聚合器采用和轉發器相同的失敗處理機制,失敗場景類似。
錯誤排查
采用此架構進行部署時,有時候會遇到“no nodes are available”的錯誤提示。這可能是節點間網絡不通導致的。需要注意的是,節點之間通過24224端口傳輸數據,既使用TCP,也會使用UDP。
可通過以下命令進行檢查:
$ telnet host 24224$ nmap -p 24224 -sU host
關于Fluentd中如何配置高可用就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。