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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面說了那么多，都是基于客戶端去做的，現(xiàn)在我們在客戶端已經(jīng)準(zhǔn)備好了想要的數(shù)據(jù)，那么我們該如何去使用他們呢？

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

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

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

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

下面我們就圍繞這三點來設(shè)計我們的服務(wù)端系統(tǒng)。

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

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

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

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

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

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

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

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