十二贊日誌收集與報警系統一覽

先快速介紹一下十二讚的日誌收集系統：十二讚的日誌收集系統，分爲兩塊，一塊是線上系統的各類報錯、異常的日誌收集，主要是各類線上代碼運行期間產生，咱們稱之爲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是須要各個業務系統本身向日志網關來彙報事件的。

存入數據庫以後，後續就是再對這些數據進行分析，查找用戶的來源渠道，計算佣金等等操做了。
【原文連接】