今天我們來(lái)聊聊如何監(jiān)控你的應(yīng)用程序，這里的監(jiān)控說(shuō)的不是讓我們?nèi)ケO(jiān)控用戶，而是監(jiān)控應(yīng)用的健康狀態(tài)，什么是健康狀態(tài)呢？對(duì)于后端的同學(xué)來(lái)說(shuō)，在微服務(wù)的架構(gòu)下，每個(gè)子服務(wù)是否正常工作、返回的結(jié)果是否滿足預(yù)期，這些就算是健康狀態(tài)，再舉個(gè)例子，你的臺(tái)式機(jī)，對(duì)于操作系統(tǒng)來(lái)說(shuō)，每個(gè)硬件是否能正常的工作、工作的穩(wěn)定性，這些都是需要關(guān)注的健康狀態(tài)。

既然我們關(guān)心健康狀態(tài)，那么我們?cè)撊绾魏饬恳粋€(gè)“設(shè)備”的健康狀態(tài)呢？對(duì)于上面的例子，CPU運(yùn)行的溫度、硬盤讀取的速度、子服務(wù)執(zhí)行的效率，這些都可以作為健康狀態(tài)的參考標(biāo)準(zhǔn)。而對(duì)于我們前端來(lái)說(shuō)，一個(gè)服務(wù)的響應(yīng)速度、某個(gè)頁(yè)面渲染的時(shí)間、外接設(shè)備是否正常運(yùn)行、以及正常運(yùn)行的時(shí)間比，這些都可以作為我們衡量一個(gè)“設(shè)備”是否健康的標(biāo)準(zhǔn)。

上面說(shuō)的了要監(jiān)控什么指標(biāo)，那這些指標(biāo)具體的實(shí)例又是什么呢？由于我主要做react-native應(yīng)用的開發(fā)，我今天就基于react-native來(lái)討論一下這件事，而對(duì)于傳統(tǒng)的web，相對(duì)來(lái)說(shuō)就簡(jiǎn)單一些了，但具體的思路不會(huì)差太多。

在我遇到的實(shí)際場(chǎng)景中，我的應(yīng)用程序常常需要鏈接多個(gè)外接設(shè)備，例如：鍵盤、掃碼槍、各種個(gè)感應(yīng)器，所以我需要時(shí)刻關(guān)注這些設(shè)備的健康狀態(tài)，一旦發(fā)現(xiàn)某個(gè)設(shè)備不能正常工作或者在未來(lái)的某個(gè)時(shí)刻不能正常工作，就需要馬上反饋出來(lái)，而這只是一部分，這些物理設(shè)備有著很明確的“指標(biāo)”。

另一方面，諸如網(wǎng)絡(luò)狀態(tài)、電池電量，這些應(yīng)用內(nèi)的“指標(biāo)”也需要我時(shí)刻的關(guān)注，什么時(shí)候處于弱網(wǎng)環(huán)境、什么時(shí)候出現(xiàn)低電量等各種各樣的異常情況都會(huì)讓我們的應(yīng)用程序變得不健康。所以，我們的目標(biāo)就是圍繞著這兩塊展開監(jiān)控，那么接下來(lái)我 們說(shuō)說(shuō)該從什么地方下手。

將所有想要監(jiān)控的服務(wù)收集到一起，作為一個(gè)總控制，然后在總控中對(duì)各個(gè)服務(wù)器的各個(gè)生命周期埋點(diǎn)。
1、主動(dòng)式：手動(dòng)的從各個(gè)生命周期中hook想要的數(shù)據(jù)，然后通過(guò)計(jì)算，收集上報(bào)。
2、被動(dòng)式： 在各個(gè)生命周期中埋點(diǎn)，等待某一類事件的觸發(fā)。

可是這么多設(shè)備，如果我們一個(gè)個(gè)的去監(jiān)控、去適配，那就和給windows系統(tǒng)的硬件寫驅(qū)動(dòng)一樣繁雜了，這對(duì)于我們前端開發(fā)來(lái)說(shuō)工作量實(shí)在是太大了，所以為了方便我們進(jìn)行統(tǒng)一的管理，和復(fù)用統(tǒng)一的代碼，我們需要一個(gè)“模式”去規(guī)范和統(tǒng)一我們的設(shè)備。

現(xiàn)在我們用一個(gè)統(tǒng)一的class去集中監(jiān)控我們的設(shè)備，另外一個(gè)問(wèn)題就是眾多的設(shè)備，無(wú)論是“物理”的設(shè)備還是“虛擬”的設(shè)備，如果我們專門為每一種去寫監(jiān)控代碼，工作量實(shí)在是太大了，所以我們可以讓這些設(shè)備在上層表現(xiàn)的“一致”，為此，我們引入“生命周期”這個(gè)概念，在一個(gè)設(shè)備啟動(dòng)、運(yùn)行、暫停、卸載的各個(gè)階段，我們都可以進(jìn)行監(jiān)控，無(wú)論是掃碼器，還是網(wǎng)絡(luò)請(qǐng)求的發(fā)起，各種各樣的形態(tài)都逃不過(guò)這個(gè)步驟，所以，只要能在這個(gè)上面做好文章，那么監(jiān)控各種數(shù)據(jù)就易如反掌了。

以下我會(huì)從兩個(gè)方面來(lái)介紹一下我總結(jié)的“基礎(chǔ)”的監(jiān)控項(xiàng)，個(gè)人認(rèn)為，無(wú)論你的項(xiàng)目為了應(yīng)對(duì)什么樣的場(chǎng)景，下面的這些例子基本都會(huì)是“必備”的選項(xiàng)了，即便你的項(xiàng)目比我的項(xiàng)目更加精簡(jiǎn)，但是下面介紹的思路也會(huì)是不錯(cuò)的參考。

上面說(shuō)了這么多，那么我們來(lái)具體的看看需要監(jiān)控些什么呢？

在一個(gè)項(xiàng)目剛上線的時(shí)候，存在著很多隱藏的問(wèn)題，所以我們需要更多的日志去監(jiān)控應(yīng)用程序是否正常的運(yùn)行，以及是否按照我們自身設(shè)定的路線去執(zhí)行，一旦項(xiàng)目穩(wěn)定，一些模塊或邏輯被證實(shí)是沒有問(wèn)題的了，那么相應(yīng)的我們也要去移除一些埋點(diǎn)日志，另外一方面，在開始上線的時(shí)候由于用戶量少，一旦出現(xiàn)線上bug，由于缺少案例，導(dǎo)致定位和分析的難度都會(huì)增大，所以，這個(gè)時(shí)候我們就需要主動(dòng)的埋一些監(jiān)控點(diǎn)，來(lái)應(yīng)對(duì)這種情況的發(fā)生，在出現(xiàn)緊急bug的時(shí)候我們可以通過(guò)日志點(diǎn)去推測(cè)和演算用戶的行為，以及當(dāng)時(shí)的情況。

但是，說(shuō)到底這些監(jiān)控都是臨時(shí)的，不一個(gè)長(zhǎng)期的監(jiān)控，所以我的原則也是盡可能的不去侵入到業(yè)務(wù)代碼中，無(wú)論是通過(guò)切面編程還是高階組件封裝，都要保證這些監(jiān)控代碼可以通過(guò)一個(gè)或一組規(guī)則快速的關(guān)閉統(tǒng)計(jì)，解放算力。

因此，凡是主動(dòng)監(jiān)控都要具備自動(dòng)判斷和動(dòng)態(tài)策略這兩個(gè)特點(diǎn)，可以動(dòng)態(tài)的感知到當(dāng)前的狀態(tài)，從而做出對(duì)主業(yè)務(wù)影響最小的行為，即便監(jiān)控再重要，也不能因?yàn)楸O(jiān)控的行為而影響業(yè)務(wù)進(jìn)程的工作，這只能是一個(gè)錦上添花行為。

為什么要有被動(dòng)式的監(jiān)控呢？首先，有些監(jiān)控的相對(duì)“獨(dú)立”的，每一次的監(jiān)控點(diǎn)并不會(huì)100%的觸發(fā)，每次的觸發(fā)并不存在上下文或者前后的必然聯(lián)系。也就是說(shuō)，這些點(diǎn)的觸發(fā)都是多帶帶存在的，所以我們不需要對(duì)其進(jìn)行諸如計(jì)算、格式化等分析操作，也不需要保存它的上下文，比如開始、結(jié)束時(shí)間。

相對(duì)于上面介紹的主動(dòng)式監(jiān)控，被動(dòng)式監(jiān)控的代碼和邏輯都會(huì)長(zhǎng)期的運(yùn)行，因?yàn)樵陧?xiàng)目的中后期，在移除了大多數(shù)異常、性能監(jiān)控后，這些僅存的代碼就成了我們排查問(wèn)題的關(guān)鍵所在了。因此，這些監(jiān)控要保證自身的穩(wěn)定，以及所積累的信息準(zhǔn)確、及時(shí)，誰(shuí)都不希望看到奔潰或者邏輯錯(cuò)誤的警報(bào)在發(fā)生之后很久才上報(bào)出來(lái)。

那么有哪些需要我們做被動(dòng)式的監(jiān)控呢？在我的項(xiàng)目中，一個(gè)外接設(shè)備是否在線，用戶點(diǎn)擊鍵盤上某個(gè)按鈕等行為就是一個(gè)典型的被動(dòng)式監(jiān)控，我不知道用戶什么時(shí)候去點(diǎn)鍵盤，我也不知道我的外接設(shè)備什么時(shí)候斷開，我只是需要捕獲到這個(gè)行為的發(fā)生就可以了。

而且對(duì)于這些監(jiān)控點(diǎn)，我們實(shí)際上是不需要開發(fā)自己去寫代碼的，它應(yīng)該存在于依賴的包中，這就避免了我多次寫重復(fù)代碼的問(wèn)題，舉個(gè)例子，我在A項(xiàng)目中有個(gè)對(duì)掃碼器掃描到內(nèi)容的監(jiān)控，而在B、C項(xiàng)目中我仍舊需要這個(gè)功能，那么我就可以不再反復(fù)的去寫這塊的日志代碼了，因?yàn)樗鼞?yīng)該存在于這個(gè)掃碼器的包中，我要做的，只是提供一個(gè)logger方法而已，返回的格式、內(nèi)容都不需要我去關(guān)心。

而這些通過(guò)埋點(diǎn)、用戶輸入、事件回調(diào)等方式收集上來(lái)的日志，我們都要如實(shí)的上報(bào)到遠(yuǎn)程服務(wù)器（這里和主動(dòng)式監(jiān)控有所區(qū)別，主動(dòng)監(jiān)控的內(nèi)容可以允許我們自己計(jì)算、統(tǒng)計(jì)），因?yàn)檫@些都是真正的異常，以后會(huì)影響我們debug的日志要最大程度的保留現(xiàn)場(chǎng)。

上面說(shuō)了那么多，都是基于客戶端去做的，現(xiàn)在我們?cè)诳蛻舳艘呀?jīng)準(zhǔn)備好了想要的數(shù)據(jù)，那么我們?cè)撊绾稳ナ褂盟麄兡兀?/p>

對(duì)于發(fā)送上來(lái)的日志，我可以做如下三件事：

監(jiān)控24小時(shí)在線狀態(tài)

異常指標(biāo)的快速報(bào)警

可視化的展示監(jiān)控信息

下面我們就圍繞這三點(diǎn)來(lái)設(shè)計(jì)我們的服務(wù)端系統(tǒng)。

對(duì)于第一點(diǎn)，我們可以通過(guò)與客戶端的心跳包來(lái)檢查客戶端是否存活，因?yàn)樵跇I(yè)務(wù)場(chǎng)景中，我們的應(yīng)用為react-native的，所以在檢測(cè)心跳的時(shí)候就要區(qū)分是native模塊還是js的業(yè)務(wù)模塊了，同時(shí)很多場(chǎng)景下存在無(wú)人使用時(shí)js業(yè)務(wù)不會(huì)上傳日志以及在移動(dòng)網(wǎng)絡(luò)下業(yè)務(wù)精簡(jiǎn)日志的情況，因此我們的24小時(shí)監(jiān)控服務(wù)就要足夠靈活、多變。所以在報(bào)警的時(shí)候可以通過(guò)讀取配置的方式在服務(wù)器不重啟的情況下動(dòng)態(tài)的變換監(jiān)控規(guī)則。

例如什么項(xiàng)目需要監(jiān)控native存活，什么項(xiàng)目需要監(jiān)控js環(huán)境存活，什么時(shí)候?qū)?bào)警通知給何人，并且可以通知到是什么地方的什么設(shè)備出了什么故障，這些都是基礎(chǔ)功能。

而第二點(diǎn)，需要我們做的除了包含第一點(diǎn)之外的功能外，還有一個(gè)異常記錄的功能，因?yàn)榈诙c(diǎn)的異常具有偶發(fā)性，并且相對(duì)于心跳包來(lái)說(shuō)，日志內(nèi)容更加豐富，因此我們可以針對(duì)這些日志做更多的事情，但首先就是將這些日志分類的保存起來(lái)。同時(shí)，在第二點(diǎn)中存在不同的應(yīng)用對(duì)不同的異常有不同的定義的情況，比如說(shuō)A應(yīng)用認(rèn)為數(shù)據(jù)初始化的接口超時(shí)就屬于異常，而B應(yīng)用則認(rèn)為即便超時(shí)也不影響，那么就需要為每個(gè)應(yīng)用多帶帶配置異常指標(biāo)，從而做到分項(xiàng)目、分閾值的功能。

還有一些額外的拓展，由于上面做的分項(xiàng)目、分閾值處理，就勢(shì)必存在一些通用異常，那么每個(gè)項(xiàng)目就應(yīng)該具有繼承公共異常的功能，以及一些模板異常的設(shè)定。這些都是這個(gè)服務(wù)所需要的功能。

最后一點(diǎn)，在搜集到異常以及通知到相關(guān)負(fù)責(zé)人之后，這次異常報(bào)警就算結(jié)束了嘛？當(dāng)然沒有這么簡(jiǎn)單了，我們可以基于web服務(wù)來(lái)查看一些日志的基本情況，例如什么項(xiàng)目報(bào)警最多，什么地方報(bào)警最多，什么時(shí)間報(bào)警最多等等圖表提供我們查看和分析。更有甚者我們可以根據(jù)不同的報(bào)警級(jí)別給不同的人發(fā)送不同的報(bào)警內(nèi)容。

最后是這個(gè)服務(wù)端自身的健壯性，由于我們的服務(wù)是基于nodejs來(lái)做的，因此通過(guò)pm2，我可以很方便的在進(jìn)程掛掉之后馬上恢復(fù)服務(wù)，同時(shí)為了服務(wù)相互解耦和最大化cpu效率，通過(guò)pm2啟動(dòng)腳本來(lái)將24小時(shí)離線服務(wù)、異常指標(biāo)報(bào)警、日志分析展示服務(wù)相互獨(dú)立開，并為可以啟動(dòng)多線程的服務(wù)提供cluster模式的支持。并且將共享的數(shù)據(jù)通過(guò)redis緩存，配置通過(guò)數(shù)據(jù)庫(kù)持久化等方式來(lái)備份和保證服務(wù)的健壯與高效。

至此，一個(gè)由客戶端+服務(wù)端的健康監(jiān)控系統(tǒng)初步完成。它們這些服務(wù)看似相互依賴，但又相互解耦，不會(huì)造成一個(gè)環(huán)節(jié)失效導(dǎo)致整個(gè)系統(tǒng)奔潰，同時(shí)又可以做到對(duì)正常業(yè)務(wù)最小化的侵入。

當(dāng)然，這些都只是一個(gè)雛形，一個(gè)全部由js去完成的項(xiàng)目，相對(duì)于大公司那些完整而又系統(tǒng)的監(jiān)控來(lái)說(shuō)，僅僅只能作為開發(fā)業(yè)務(wù)的我們自查的一個(gè)工具。雖然有這些系統(tǒng)來(lái)保證我們的項(xiàng)目正常、健康的運(yùn)行，但是更重要的是我們開發(fā)者自己代碼的健壯和穩(wěn)定。工具做的再好，也不能替代我們自己寫的優(yōu)異的代碼。