最近一段時間，配合新的商業模式，e網打進產品進行系統重構，由於客戶量比較大，那麼對應的資料量比較大，涉及的系統架構很複雜，對應的伺服器也成倍的增加。伺服器日誌的收集和檢視也變的比較麻煩，於是就在想是否可以把各個應用日誌統一收集過來。
現在的做法：每天凌晨30分左右啟動乙個任務，把日誌從各個伺服器統一收集過來，然後通過匯入分析程式對日誌進行處理，並把結果資料輸入到資料庫中。這樣的做法在可以支援幾台到十幾台規模的併發服務。但當管理的伺服器達到幾十台，而且有大量的伺服器中間會有上線/下線變更的時候，集中的日誌定期同步 更顯得非常難於管理，而日誌的同步由於要避開白天的高峰，往往需要用凌晨的低峰時段進行同步，24小時下來，上g的日誌同步也是風險很高的操作。而成為瓶 頸的日誌排序合併操作也會妨礙其他後續計算的週期。
如果能實現應用日誌的集中收集，那麼對個應用日誌的壓縮、打包、收集就無須任務了，對於應用伺服器的變更也沒有影響。前段時間看了log4j的功能，可以通過log4j進行擴充套件達到我們日誌收集的目的，系統結構圖如下：
原理：現在大部分的系統都採用log4j來記錄應用日誌，那麼我們使用log4j收集日誌，然後寫入到指定的日誌收集伺服器上，資料通過 udp 進行傳輸。服務端收到這些資料後，先放入到對應的佇列中，都個執行緒同步去處理這些日誌。
log4j自定義：
日誌收集服務端：
日誌收集服務端啟動偵聽執行緒，偵聽某個埠（比如：8080），發現有日誌資料過來後，立馬讀入這個資料並放入到相應的佇列中。
其他功能：
根據日誌的情況可做統計分析，可做報警等等，這個就看詳細的應用場景。
分布式日誌跟蹤收集 amqp tracer
h2.需求 使用lager的trace功能，可以從任何節點發起trace,相關節點收到trace命令後，開始收集符合trace條件的日誌資訊 trace到的日誌資訊都匯集到lager amqp backend中 h2.方案 lager amqp backend增加 amqp tracer.erl 模...
集群 分布式 集中式 偽分布式
將專案部署到一台機器上 對機器效能要求高 單體應用 將專案拆分 按業務或者服務 將專案部署在不同的機器上執行 對機器效能要求下降 集群是對機器數量的乙個概念 乙個專案，多機備份，做負載均衡及容錯 所有集群節點分布在多台機器上 集群主要作用就是分散請求，分散壓力，提高併發處理能力 減輕單一應用的壓力 ...
分布式日誌收集之Logstash 筆記（一）
2 命令列引數僅適合簡單的配置，如果配置比較多，我們一般會寫入乙個以.conf結尾的配置檔案裡，然後使用 f命令載入，將 1 中的配置，寫入hello.conf 然後使用bin logstash f hello.conf 執行載入，即可達到同樣效果 3 常用的資料模組 input filter ou...