為什麼需要分散式日誌系統？
當企業在不同地點設立資訊系統時，如果想要透過日誌瞭解設備的紀錄，或是回報其效能狀況時，需要同仁使用指令，分別進入不同地點的設備，查詢日誌/效能的資訊，且取得的資訊是未經整理的，需要使用人工進行判讀，這樣的作法不僅浪費人力且效率非常低。
採用分散式日誌其中一個原因是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的效能。
FC的 Filter功能，雖可定義過濾特定的字串，目前沒有開放在 FC 的介面上設定字串過濾，亦即 FC 會將收到的日誌全部送至SAFE3.0主機中。Output會依設定送給SAFE3.0底層的緩衝區或索引區，進行日誌保存，而FC本身具備緩衝的功能，當前端收集器與SAFE3.0主機間斷線時，能在 FC 保留前端設備送過來的 Syslog日誌。
採用FC分散式架構，可減輕SAFE3.0處理解析的負擔，讓多出來的資源提供大量的資料查詢，大幅提升其效能。除了查詢，亦可將效能用在日誌的統計和檢索，例如：哪些服務需要事件的告警或效能異常的通知等。
歡迎對SAFE3.0「前端收集器」架構有興趣的朋友與我們聯繫。
