今天我們來聊聊如何監控你的應用程序，這里的監控說的不是讓我們去監控用戶，而是監控應用的健康狀態，什么是健康狀態呢？對于后端的同學來說，在微服務的架構下，每個子服務是否正常工作、返回的結果是否滿足預期，這些就算是健康狀態，再舉個例子，你的臺式機，對于操作系統來說，每個硬件是否能正常的工作、工作的穩定性，這些都是需要關注的健康狀態。

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

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

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

另一方面，諸如網絡狀態、電池電量，這些應用內的“指標”也需要我時刻的關注，什么時候處于弱網環境、什么時候出現低電量等各種各樣的異常情況都會讓我們的應用程序變得不健康。所以，我們的目標就是圍繞著這兩塊展開監控，那么接下來我 們說說該從什么地方下手。

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

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

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

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

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

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

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

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

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

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

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

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

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

上面說了那么多，都是基于客戶端去做的，現在我們在客戶端已經準備好了想要的數據，那么我們該如何去使用他們呢？

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

監控24小時在線狀態

異常指標的快速報警

可視化的展示監控信息

下面我們就圍繞這三點來設計我們的服務端系統。

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

例如什么項目需要監控native存活，什么項目需要監控js環境存活，什么時候將報警通知給何人，并且可以通知到是什么地方的什么設備出了什么故障，這些都是基礎功能。

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

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

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

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

至此，一個由客戶端+服務端的健康監控系統初步完成。它們這些服務看似相互依賴，但又相互解耦，不會造成一個環節失效導致整個系統奔潰，同時又可以做到對正常業務最小化的侵入。

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