先快速介紹一下十二贊的日志收集系統：十二贊的日志收集系統，分為兩塊，一塊是線上系統的各種報錯、異常的日志收集，主要是各種線上代碼運行期間產生，我們稱之為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是需要各個業務系統自己向日志網關來匯報事件的。

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

總結

以上是生活随笔為你收集整理的十二赞日志收集与报警系统一览的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。