3種解決辦法

https://tech.meituan.com/mt-log-system-arch.html

4 架構設計考慮

下面將從可用性，可靠性，可擴展性和兼容性等方面，對上述的架構做細致的解析。

4.1 可用性(availablity)

對日誌收集系統來說，可用性(availablity)指固定周期內系統無故障運行總時間。要想提高系統的可用性，就需要消除系統的單點，提高系統的冗余度。下面來看看美團的日誌收集系統在可用性方面的考慮。

4.1.1 Agent死掉

Agent死掉分為兩種情況：機器死機或者Agent進程死掉。

對於機器死機的情況來說，由於產生日誌的進程也同樣會死掉，所以不會再產生新的日誌，不存在不提供服務的情況。

對於Agent進程死掉的情況來說，確實會降低系統的可用性。對此，我們有下面三種方式來提高系統的可用性。首先，所有的Agent在supervise的方式下啟動，如果進程死掉會被系統立即重啟，以提供服務。其次，對所有的Agent進行存活監控，發現Agent死掉立即報警。最後，對於非常重要的日誌，建議應用直接將日誌寫磁盤，Agent使用spooldir的方式獲得最新的日誌。

4.1.2 Collector死掉

由於中心服務器提供的是對等的且無差別的服務，且Agent訪問Collector做了LoadBalance和重試機制。所以當某個Collector無法提供服務時，Agent的重試策略會將數據發送到其它可用的Collector上面。所以整個服務不受影響。

4.1.3 Hdfs正常停機

我們在Collector的HdfsSink中提供了開關選項，可以控制Collector停止寫Hdfs，並且將所有的events緩存到FileChannel的功能。

4.1.4 Hdfs異常停機或不可訪問

假如Hdfs異常停機或不可訪問，此時Collector無法寫Hdfs。由於我們使用DualChannel，Collector可以將所收到的events緩存到FileChannel，保存在磁盤上，繼續提供服務。當Hdfs恢復服務以後，再將FileChannel中緩存的events再發送到Hdfs上。這種機制類似於Scribe，可以提供較好的容錯性。

4.1.5 Collector變慢或者Agent/Collector網絡變慢

如果Collector處理速度變慢（比如機器load過高）或者Agent/Collector之間的網絡變慢，可能導致Agent發送到Collector的速度變慢。同樣的，對於此種情況，我們在Agent端使用DualChannel，Agent可以將收到的events緩存到FileChannel，保存在磁盤上，繼續提供服務。當Collector恢復服務以後，再將FileChannel中緩存的events再發送給Collector。

4.1.6 Hdfs變慢

當Hadoop上的任務較多且有大量的讀寫操作時，Hdfs的讀寫數據往往變的很慢。由於每天，每周都有高峰使用期，所以這種情況非常普遍。

對於Hdfs變慢的問題，我們同樣使用DualChannel來解決。當Hdfs寫入較快時，所有的events只經過MemChannel傳遞數據，減少磁盤IO，獲得較高性能。當Hdfs寫入較慢時，所有的events只經過FileChannel傳遞數據，有一個較大的數據緩存空間。

Flume Agent進程死掉