先快速介紹一下十二贊的日誌收集系統：十二贊的日誌收集系統，分為兩塊，一塊是線上系統的各種報錯、異常的日誌收集，主要是各種線上**執行期間產生，我們稱之為log-collect，一塊是使用者行為操作的日誌收集，主要是由各個業務系統根據使用者的行為來上報，比如使用者a訪問了xx頁面，使用者b收藏了某某商品等,我們稱之為eventdb。
基於這兩塊的日誌收集，我們實現了一些自己非常自豪的特性。比如，基於log-collect，我們做到了能夠主動去發現問題，搶在大多數客戶發現異常之前，就把問題處理掉，從而做到不斷地提高saas系統的可用率和穩定性；基於eventdb,我們能做到非常完善的行為收集，將我們的返利模組、分銷模組的準確度、實時性大幅度提高。
下面我們介紹一下系統的架構。
從需求上，我們認為log-collect是為了及時發現問題，並馬上解決掉。但是這些日誌，在我們解決掉問題之後，是不需要再保留這個日誌的。比如，舉個例子，使用者註冊的時候，可能輸了乙個12012345678的號碼，這個號碼是不對的，導致我們的驗證簡訊發不出去，簡訊模組就會報錯。我們的log-collect會收集到這條報錯日誌，馬上告警。開發同學收到告警通知時，就馬上去處理這個問題，使用者輸入120這個號段時，提示使用者該號段是不被支援的，以後就再也不需要處理這個了，因為這條告警日誌，我們是不存的，只存檔15天就丟棄掉。
log-collect
基於這種差異，我們在架構上也有不同。下面是log-collect的架構圖：
我們每一台服務端機器上都有乙個live tail,實時監控日誌檔案，一旦日誌檔案有新的寫入，就立刻傳送到http的乙個日誌閘道器。這個閘道器就立刻把這條件日誌推送給乙個廣播伺服器，並寫入到乙個資料庫（資料庫會清掉7天之前的資料。）這個資料丟給廣播伺服器了之後，會在特定的頻道進行廣播。我寫了一些客戶端，訂閱廣播，根據日誌內容的不同，將日誌發給倍洽上不同的告警頻道。（關於bearychat/中文名倍洽,大家可以自行去其官網上了解）。手機上裝了倍洽，就可以隨時接受告警通知了：
eventdb
下圖是eventdb的架構圖:
與log-collect相同的，收到新的行為事件後，閘道器也會在乙個特定的頻道進行廣播。不同的有兩點，一點是另一條鏈路先把行為事件寫入到阿里雲的oss儲存起來，然後寫了crontab每小時、每天定期從oss檔案裡匯入到eventdb這個資料庫；另一點是廣播客戶端工作的事情也變成了實時寫入到eventdb這個資料庫。
在事件收集上，也不一樣，log-collect是在所有的伺服器上部署了livetail來從日誌檔案中讀取，而eventdb是需要各個業務系統自己向日誌閘道器來匯報事件的。
Go實現海量日誌收集系統 一
當然即使是機器規模不大，乙個系統通常也會涉及到多種語言的開發，拿我們公司來說，底層是通過c 開發的，而也業務應用層是通過python開發的，並且即使是c 也分了很多級別應用，python這邊同樣也是有多個應用，那麼問題來了，每次系統出問題了，如何能夠迅速查問題?好一點的情況可能是python應用層查...
log日誌系統《一》
using system using system.io using unityengine using system.reflection using system.diagnostics unity 的 debug 的封裝類 public class wilog public static vo...
hadoop日誌分析系統一 Hadoop的認識
hadoop是乙個分布式的大資料處理平台 核心組成 hdfs分布式檔案系統 高度容錯的分布式檔案儲存系統 mapreduce平行計算模型 一種計算的模型 common元件 hadoop的核心元件 其它元件 hbase 高可靠性 高效能 面向列 可伸縮的分布式儲存系統 hive 資料倉儲 sqoop ...