先快速介紹一下十二贊的日志收集系統：十二贊的日志收集系統，分為兩塊，一塊是線上系統的各種報錯、異常的日志收集，主要是各種線上代碼運行期間產生，我們稱之為log-collect，一塊是用戶行為操作的日志收集，主要是由各個業務系統根據用戶的行為來上報，比如用戶A訪問了xx頁面，用戶B收藏了某某商品等,我們稱之為eventdb。

基于這兩塊的日志收集，我們實現了一些自己非常自豪的特性。比如，基于log-collect，我們做到了能夠主動去發現問題，搶在大多數客戶發現異常之前，就把問題處理掉，從而做到不斷地提高Saas系統的可用率和穩定性；基于eventdb,我們能做到非常完善的行為收集，將我們的返利模塊、分銷模塊的準確度、實時性大幅度提高。

下面我們介紹一下系統的架構。

從需求上，我們認為log-collect是為了及時發現問題，并馬上解決掉。但是這些日志，在我們解決掉問題之后，是不需要再保留這個日志的。比如，舉個例子，用戶注冊的時候，可能輸了一個12012345678的號碼，這個號碼是不對的，導致我們的驗證短信發不出去，短信模塊就會報錯。我們的log-collect會收集到這條報錯日志，馬上告警。開發同學收到告警通知時，就馬上去處理這個問題，用戶輸入120這個號段時，提示用戶該號段是不被支持的，以后就再也不需要處理這個了，因為這條告警日志，我們是不存的，只存檔15天就丟棄掉。

但是對于eventdb,我們的目標是為了對這些數據做分析，這些行為一般會跟財務相關，比如用戶A通過用戶B分享的鏈接進到了系統，5分鐘之后有戶A購買了商品付款了200元，2天后用戶A退掉了其中的80元。這些數據，會影響到商家給用戶B結算cps款項。類似這些數據，我們是永久存儲的，不會拋棄。同時，這類數據，我們是要在保證準確性的基礎上不斷提高實時性的。所以對這類數據，我們有兩條線來處理，一條是在線實時，一條是離線的一個小時跑一次數據的。

log-Collect

基于這種差異，我們在架構上也有不同。下面是log-collect的架構圖：

https://ylpicture.oss-cn-beij...

我們每一臺服務端機器上都有一個live tail,實時監控日志文件，一旦日志文件有新的寫入，就立刻發送到http的一個日志網關。這個網關就立刻把這條件日志推送給一個廣播服務器，并寫入到一個數據庫（數據庫會清掉7天之前的數據。）這個數據丟給廣播服務器了之后，會在特定的頻道進行廣播。我寫了一些客戶端，訂閱廣播，根據日志內容的不同，將日志發給倍洽上不同的告警頻道。（關于bearychat/中文名倍洽,大家可以自行去其官網上了解）。手機上裝了倍洽，就可以隨時接受告警通知了：

https://ylpicture.oss-cn-beij...

eventDB

下圖是eventDB的架構圖:

https://ylpicture.oss-cn-beij...

與log-collect相同的，收到新的行為事件后，網關也會在一個特定的頻道進行廣播。不同的有兩點，一點是另一條鏈路先把行為事件寫入到阿里云的oss存儲起來，然后寫了crontab每小時、每天定期從oss文件里導入到eventDB這個數據庫；另一點是廣播客戶端工作的事情也變成了實時寫入到eventDB這個數據庫。

在事件收集上，也不一樣，log-collect是在所有的服務器上部署了LiveTail來從日志文件中讀取，而eventDB是需要各個業務系統自己向日志網關來匯報事件的。

存入數據庫之后，后續就是再對這些數據進行分析，查找用戶的來源渠道，計算傭金等等操作了。
【原文鏈接】