為什麼需要分散式日誌系統?
當企業在不同地點設立資訊系統時,如果想要透過日誌瞭解設備的紀錄,或是回報其效能狀況時,需要同仁使用指令,分別進入不同地點的設備,查詢日誌/效能的資訊,且取得的資訊是未經整理的,需要使用人工進行判讀,這樣的作法不僅浪費人力且效率非常低。
採用分散式日誌其中一個原因是SAFE3.0主機的運算能力有限。SAFE3.0主機補僅要負責解析工作,同時也要接受用戶查詢、定期排程與告警通知等,將會增加主機的負擔,降低接收日誌的 EPS(Events Per Second)數。如採用分散式架構,將提高SAFE3.0主機的效能,雖可使用 Cluster 架構來解決主機負載的問題,但這個架構需要較大的投資成本。
其次是網路層封包傳送的限制。當 Syslog 透過 UDP 協定傳送時,因為跨廣域(WAN) 網路傳輸時,會造成封包遺失的問題,改用分散式架構將可解決掉封包的問題。


SAFE3.0的「前端收集器」架構
SAFE3.0 在 v3.1版增加「前端收集器」(Front-end Collector, 簡稱FC)的功能,具備完整的分散式日誌收集架構,讓分散於不同地點的資訊系統或設備日誌,透過FC傳送到SAFE3.0主機進行管理,如查詢、報表製作及告警等。SAFE3.0,的分散式架構,可以輕鬆地解決了上述日誌收集困難及網路的問題。
前端收集器FC功能包括:日誌收集、過濾、輸出等功能,主要由Input、Filter、Output這三個核心元件組成。Input接收來自設備的 Syslog,再由Filter進行日誌解析與過濾的功能。如果設定為不解析(如圖一),則由FC轉送來源設備日誌給SAFE3.0主機,跟平常拋送日誌給SAFE3.0的功能一樣;如果在FC設定為解析(如圖二),則會部署解析規則在前端的 FC主機中,日誌經過解析後,直接放進SAFE3.0的索引區中,提高SAFE3.0的效能。

 
news01 01
 
news01 02

 

FC的 Filter功能,雖可定義過濾特定的字串,目前沒有開放在 FC 的介面上設定字串過濾,亦即 FC 會將收到的日誌全部送至SAFE3.0主機中。Output會依設定送給SAFE3.0底層的緩衝區或索引區,進行日誌保存,而FC本身具備緩衝的功能,當前端收集器與SAFE3.0主機間斷線時,能在 FC 保留前端設備送過來的 Syslog日誌。

採用FC分散式架構,可減輕SAFE3.0處理解析的負擔,讓多出來的資源提供大量的資料查詢,大幅提升其效能。除了查詢,亦可將效能用在日誌的統計和檢索,例如:哪些服務需要事件的告警或效能異常的通知等。

歡迎對SAFE3.0「前端收集器」架構有興趣的朋友與我們聯繫