線上bug日志監(jiān)控，主動(dòng)運(yùn)維平臺(tái)搭建

在快速迭代的業(yè)務(wù)需求下，難免會(huì)出現(xiàn)一些線上 bug ，特別是在 SaaS 業(yè)務(wù)領(lǐng)域，線上 bug 對于商家來說大概率會(huì)影響經(jīng)營，嚴(yán)重的話很可能引發(fā)故障。所以，我們對線上質(zhì)量要求很高。針對線上 bug ，除了商家主動(dòng)上報(bào)問題，后端還有自己的天網(wǎng)監(jiān)控體系，進(jìn)行主動(dòng)發(fā)現(xiàn)問題，那移動(dòng)端如何進(jìn)行主動(dòng)防控呢？所以我們也需要自己的主動(dòng)防控平臺(tái)。

為什么不可以直接使用后端的天網(wǎng)系統(tǒng)？

• 需求功能對比

從功能來看，后端的天網(wǎng)更像一個(gè)線上接口日志存儲(chǔ)，結(jié)合監(jiān)控配置能力進(jìn)行預(yù)警處理。經(jīng)過分析，后端天網(wǎng)無法滿足移動(dòng)端的使用場景。

• 核心價(jià)值

提高客戶端線上質(zhì)量，減少線上問題，主動(dòng)發(fā)現(xiàn)與預(yù)防線上問題，及時(shí)報(bào)警與處理，降低線上問題的影響面。做到防患于未然。

二、整體設(shè)計(jì)

根據(jù)以上背景，可以得知，移動(dòng)端天網(wǎng)平臺(tái)相對于后端天網(wǎng)平臺(tái)更復(fù)雜，涉及的技術(shù)點(diǎn)也比較多，主要有客戶端、 PC 后臺(tái)管理（下面內(nèi)容簡稱 mpaas ）、后端服務(wù)、數(shù)據(jù)存儲(chǔ)等。

• 系統(tǒng)架構(gòu)圖

整體流程是可以區(qū)分兩部分，一部分為日志上報(bào)流程，數(shù)據(jù)來源是業(yè)務(wù)方客戶端，另一部分為日志操作流程，操作方是 mpaas 后臺(tái)。這兩者的區(qū)別，主要是一個(gè)是數(shù)據(jù)的來源方，另一個(gè)是數(shù)據(jù)的使用方。

• 日志上報(bào)流程

客戶端上處理流程相對來說沒有那么復(fù)雜，主要就是數(shù)據(jù)的采集與上報(bào)。其中核心邏輯都在業(yè)務(wù)服務(wù)中進(jìn)行，比如日志內(nèi)容整合，觸發(fā)通知邏輯等。

• 日志操作流程

mpaas 平臺(tái)，是整個(gè)處理和報(bào)警的核心。提供問題查看、分配人員、狀態(tài)變更、問題備注、通知策略等功能。

• 后端天網(wǎng)系統(tǒng)（ skyLog ）

為什么我們自己做了數(shù)據(jù)存儲(chǔ)以及移動(dòng)天網(wǎng)平臺(tái)，為什么還會(huì)依賴 skyLog 呢？

主要原因是，我們天網(wǎng)上報(bào)數(shù)據(jù)是區(qū)分等級，存在 info 、warning 、error 三個(gè)等級，對應(yīng)上報(bào)問題等級不同，通知策略與處理流程也會(huì)有區(qū)別，但都是需要記錄到 skyLog 日志平臺(tái)上，類似打 log 日志。目前 info 級別的數(shù)據(jù)是不會(huì)存儲(chǔ)到移動(dòng)天網(wǎng)服務(wù)中，因?yàn)榇蛉罩緝?nèi)容不在報(bào)警范圍內(nèi)，所以查詢打的日志內(nèi)容就需要到 skyLog 平臺(tái)上查詢。具體兩者區(qū)別參考前面第一部分背景介紹。

• 企業(yè)微信服務(wù)

公司內(nèi)部使用企業(yè)微信，針對企業(yè)微信可以自定義消息通知以及群機(jī)器人功能，可以使用企微提供的公開接口進(jìn)行調(diào)用，很方便的實(shí)現(xiàn)通知報(bào)警能力，可針對不同業(yè)務(wù)場景，定制不同消息通知。針對本平臺(tái)，當(dāng)觸發(fā)報(bào)警，比如 error 級別問題上報(bào)（后面會(huì)有具體通知策略分析），則會(huì)通過消息給負(fù)責(zé)人推送系統(tǒng)消息，以及群機(jī)器人觸發(fā)報(bào)警。

例：零售移動(dòng)天網(wǎng)報(bào)警群機(jī)器人

具體使用參考企業(yè)微信官網(wǎng) api：https://work.weixin.qq.com/api/doc/90000/90135/90235

三、日志采集和上報(bào)

目前該平臺(tái)對接的業(yè)務(wù)方，主要是針對的是公司各業(yè)務(wù)團(tuán)隊(duì)的移動(dòng)端業(yè)務(wù)，日志的上報(bào)基礎(chǔ)能力集中 Zanlogger 日志二方庫。同時(shí)基于目前混合開發(fā)的現(xiàn)狀，開發(fā)了 ZanlogWeex 和 ZanlogFlutterPlugin 來實(shí)現(xiàn) Flutter 和 Weex 頁面的日志需求。

1、日志信息采集

首先看下日志內(nèi)容的組成：

其中，基礎(chǔ)信息由 Zanlogger 自主收集，業(yè)務(wù)方使用的時(shí)候，只需關(guān)注相關(guān)業(yè)務(wù)信息。

//天網(wǎng)日志上報(bào)
Log.sky("info", "sale", "startPay", "goods is xxxxx")
Log.sky("warn", "sale", "changePriceFailed", "goods is xxxxx")
Log.sky("error", "sale", "db can not open", "error:xxxx")

設(shè)備型號，系統(tǒng) os 版本，應(yīng)用版本，用戶 id ，店鋪 id 等基礎(chǔ)信息，在同個(gè)設(shè)備的大部分時(shí)間段內(nèi)，都是相同的。考慮到流量和效率問題，沒必要每條日志都上傳。

Zanlogger 的實(shí)現(xiàn)方式是，應(yīng)用啟動(dòng)時(shí)，獲取設(shè)備唯一標(biāo)識(shí)，上傳一次基礎(chǔ)信息。業(yè)務(wù)日志上報(bào)時(shí)，只需上傳設(shè)備唯一標(biāo)識(shí)。后端服務(wù)收到消息時(shí)，通過唯一標(biāo)識(shí)獲取基礎(chǔ)信息，組合成完整的日志。

2、按級別策略上報(bào)

移動(dòng)天網(wǎng)平臺(tái)支持 error，warning，info 三種級別的日志上報(bào)，針對不同級別的上報(bào)信息，觸發(fā)接口上報(bào)的時(shí)機(jī)也不同。

• error : 最高等級問題，如果發(fā)生，則會(huì)引發(fā)線上 bug ，客戶端會(huì)立即上報(bào)。

• warning : 該級別我們定義為警告，針對一些業(yè)務(wù)場景，可能是異?；蚱渌到y(tǒng)錯(cuò)誤，發(fā)生并不一定是線上 bug ，然而當(dāng)短時(shí)間內(nèi)發(fā)生次數(shù)過多，則可能演變成線上 bug，所以該問題不會(huì)立即上報(bào)，而是存在一定 buffer ，當(dāng)發(fā)生次數(shù)到達(dá) buffer 量級后客戶端進(jìn)行上報(bào)。

• info : 低等級問題。該級別我們認(rèn)為是基礎(chǔ)日志信息，并不認(rèn)為是問題，基本是業(yè)務(wù)人員進(jìn)行埋點(diǎn)數(shù)據(jù)進(jìn)行線上邏輯排查與跟蹤使用，客戶端上報(bào)策略和 warning 類似，也存在 buffer ，達(dá)到量級后進(jìn)行上報(bào)。該級不會(huì)進(jìn)行通知，相關(guān)人員自行去天網(wǎng)日志平臺(tái)中查詢信息。

為了擔(dān)心數(shù)據(jù)量太小，buffer 一直未達(dá)到上報(bào)的條件，或者網(wǎng)絡(luò)原因，但是一直上傳失敗，同時(shí)會(huì)設(shè)置指定時(shí)間（例如 30s ）的輪詢機(jī)制，一旦發(fā)現(xiàn)有未上傳的日志，立即上報(bào)。

四、日志存儲(chǔ)和報(bào)警設(shè)計(jì)

1、日志存儲(chǔ)

實(shí)際場景中，日志的上報(bào)頻率，和日志的內(nèi)容大小是不確定的，基于性能考慮，后端的數(shù)據(jù)存儲(chǔ)流程如下：

原因是，相較于 RDS ，HBase 更適合適合大數(shù)量的存儲(chǔ)，于是日志完整內(nèi)容存放在 HBase，兩者通過每條日志存儲(chǔ)時(shí)，生成的 uuid 關(guān)聯(lián)。日志的頻繁上報(bào)，使用 kafka ，保證峰值處理能力。

存儲(chǔ)位置的問題解決后，接下來思考的是日志該以什么維度進(jìn)行分組？

移動(dòng)日志的解決方案是聚合 biz + sign + type + level + os ，取其 hashcode 。

這里為什么會(huì)將系統(tǒng) os 作為分組因子呢？這里的原因是，基于現(xiàn)有場景分析，存在 pad 和 phone 同一個(gè) sign 的報(bào)警，大概率是不同的代碼流程導(dǎo)致的，應(yīng)該視為不同問題去排查和分析。

2、報(bào)警策略設(shè)計(jì)

當(dāng) error 日志上報(bào)后，后端會(huì)通過企業(yè)微信服務(wù)，向指定的群發(fā)送消息，并且 @指定的人，影響范圍大的問題甚至需要 @所有人。信息論中有個(gè)定律：“信息量越大，信息熵越小”，所以為了保證群消息的關(guān)注度，在保證關(guān)鍵信息觸達(dá)的前提下，對群內(nèi)成員減少不必要的打擾。

因此不是所有信息都需要發(fā)送到群消息，比較建議群通知的場景如下：

1. 新問題出現(xiàn)。

2. 已解決問題新版本再次出現(xiàn)。

3. 閾值范圍報(bào)警。

以上是我們提供的默認(rèn)配置，也支持讓業(yè)務(wù)方自定義。下一章節(jié)中會(huì)講到相關(guān)自定義配置功能。

報(bào)警策略流程中需要用到以下概念：

• 問題狀態(tài)：上報(bào)問題處理的狀態(tài)，分為待處理、處理中、待發(fā)版、已上線。

• 問題解決版本：當(dāng)問題狀態(tài)變更到待發(fā)版或已上線時(shí)，需要填寫解決版本號，比如 6.5.0 ，代表該問題在該版本已解決。

完整的報(bào)警策略流程如下：

五、移動(dòng)天網(wǎng)平臺(tái)可視化介紹

該平臺(tái)的核心功能就是對于上報(bào)問題的報(bào)警通知能力與處理能力，以及相關(guān)報(bào)警配置策略。這里對于客戶端的上報(bào)相關(guān)沒有什么可講的，相關(guān)的數(shù)據(jù)上報(bào)策略前面也有講。這里主要針對 mpaas 平臺(tái)進(jìn)行功能與策略介紹。

1、問題查看

問題列表頁面：

問題列表主要展示上報(bào)的所有問題，上報(bào)時(shí)相同的問題會(huì)進(jìn)行聚合，列表中每一條數(shù)據(jù)，代表相同一類問題。同時(shí)支持多種篩選條件進(jìn)行快速查找。

• 業(yè)務(wù)：針對不同客戶端的業(yè)務(wù)方

• 平臺(tái)：iOS、Android、PC 等

• 版本：上報(bào)問題的 app 版本信息

• 類型：各業(yè)務(wù)方定義自己的問題分類 type ，比如零售定義為業(yè)務(wù)模塊

• sign：上報(bào)問題的 key ，用來標(biāo)識(shí)問題名稱

• 等級：前面也有講到，分為三個(gè)等級，error、warning、info

• 時(shí)間：進(jìn)行時(shí)間段篩選

• 處理狀態(tài)：用于篩選具體問題狀態(tài)，多選

• 處理人：問題相關(guān)處理人

• 關(guān)聯(lián)問題文檔：用來快速篩選出帶有關(guān)聯(lián)問題鏈接的問題

問題詳情頁面：

針對每一類問題，點(diǎn)擊詳情進(jìn)行查看上報(bào)的具體信息。詳情中，會(huì)包含該類問題的所有上報(bào)信息，每次上報(bào)問題都可以查看具體上報(bào)內(nèi)容信息，然后進(jìn)行問題分析。

• 拉取設(shè)備離線日志：可以快速拉取上報(bào)問題設(shè)備的本地離線日志

• 操作記錄：記錄該問題的操作情況，以及該問題解決過程中的備注

2、問題處理

當(dāng)問題上報(bào)上來時(shí)，會(huì)默認(rèn)進(jìn)行分配給上一次處理該問題的人員，如果是新問題則會(huì)分配給對應(yīng)業(yè)務(wù) owner 進(jìn)行處理。當(dāng)問題在解決時(shí)，需要對問題人員及狀態(tài)等進(jìn)行變更。

針對問題處理的操作，主要有狀態(tài)、人員、備注信息。如果狀態(tài)為待發(fā)版或者已上線，則需要填寫修復(fù)版本，用來保證該問題在低版本的誤報(bào)情況，如果問題存在問題鏈接，則需要填寫關(guān)聯(lián)問題文檔，方便后續(xù)查看與統(tǒng)計(jì)使用。

• 狀態(tài)：分為四個(gè)狀態(tài)，待處理、處理中、待發(fā)版、已上線

• 處理人：根據(jù)公司內(nèi)部員工信息，對應(yīng)到內(nèi)部人員信息

• 備注：操作該問題時(shí)，需要填寫備注信息，以便后者人員進(jìn)行查看

• 修復(fù)版本：該問題的解決版本，當(dāng)狀態(tài)為待發(fā)版或已上線時(shí)需要填寫

• 問題文檔：該問題關(guān)聯(lián)的問題鏈接，非必填

• 2h 內(nèi)免打擾：當(dāng)有人在處理時(shí)，為了專心解決問題，可以設(shè)置 2h 免打擾

3、報(bào)警策略相關(guān)配置

前面有講到，報(bào)警能力主要依賴企業(yè)微信進(jìn)行通知到相關(guān)的人和群。實(shí)現(xiàn)自定義報(bào)警策略，那就需要相關(guān)策略配置功能頁面。

3.1 配置后臺(tái)頁面

報(bào)警策略列表頁面：

報(bào)警策略配置頁面：

配置頁面可以根據(jù)業(yè)務(wù)方需求，自行添加應(yīng)用配置策略，可根據(jù) error 和 warning 級別分別設(shè)置配置策略信息。在問題上報(bào)后，會(huì)根據(jù)不用業(yè)務(wù)方應(yīng)用（ biz ）進(jìn)行識(shí)別，采用對應(yīng)的配置信息進(jìn)行報(bào)警。

3.2 通知模板

通知模板主要分為三類，個(gè)人及群消息通知，日報(bào)和周報(bào)。

• 問題消息通知

• 日報(bào)和周報(bào)

個(gè)人及群消息通知，主要是針對新問題及操作變更時(shí)進(jìn)行通知。日報(bào)和周報(bào)更多的是關(guān)注統(tǒng)計(jì)相關(guān)的數(shù)據(jù)，針對上報(bào)問題日報(bào)情況，可以看出當(dāng)日問題的處理情況，周報(bào)數(shù)量統(tǒng)計(jì)，可以看出本周的概要情況。

四、總結(jié)

對于移動(dòng)端來說，線上問題的發(fā)生是比較嚴(yán)重的問題，特別是在零售這種線下場景，很可能一個(gè)問題會(huì)給商家?guī)碣Y損的問題，所以對于移動(dòng)端的質(zhì)量問題要有高標(biāo)準(zhǔn)。除了開發(fā)階段的 code review 和自測，測試階段的自動(dòng)化測試和人工測試，我們?nèi)绾沃鲃?dòng)監(jiān)控線上問題的發(fā)生就成了關(guān)鍵，移動(dòng)天網(wǎng)平臺(tái)的搭建就是解決線上主動(dòng)監(jiān)控的空缺。

目前移動(dòng)天網(wǎng)平臺(tái)在線上已經(jīng)跑了近半年時(shí)間，其中有效幫助移動(dòng)端主動(dòng)發(fā)現(xiàn)線上問題數(shù)量占比已經(jīng)達(dá)到 20% 。對于主動(dòng)發(fā)現(xiàn)的問題，我們快速響應(yīng)進(jìn)行解決，目前主動(dòng)發(fā)現(xiàn)的問題商家沒有再進(jìn)行上報(bào)。這對于商家和服務(wù)同學(xué)，以及開發(fā)都是一種效率和質(zhì)量的提升。