監控的主要目的是為了將一些重要指標采樣記錄下來，一旦這些指標發生較大變化，可以配合報警系統將問題反饋到負責人那。監控的點可以很細致，也可以只選主要的指標。

業務邏輯型的監控主要體現在日志上，做足了日志記錄的功夫之后，如何將日志應用起來是個問題。通過監控異常日志文件的變動，將新增的異常按異常類型和數量反映出來。某些異常與具體的某個子系統相關，監控出現的某個異常多半能反映出子系統的狀態。

除了異常日志的監控外，對于訪問日志的監控也能體現出實際的業務QPS值。觀察QPS的表現能夠檢查業務在時間上的分布。

此外，從訪問日志中也能實現PV和UV的監控。同QPS值一樣，通過對PV/UV的監控，可以很好地知道應用的使用者們的習慣、預知訪問高峰等。

響應時間也是一個需要監控的點。一旦系統的某個子系統出現異常或者性能瓶頸，將會導致系統的響應時間變長。響應時間可以在Nginx一類的反向代理上監控，也可以通過應用自行產生的訪問日志來監控。健康的系統響應時間應該是波動較小的、持續均衡的。

監控日志和響應時間都能較好地監控到系統的狀態，但是它們的前提是系統是運行狀態的，所以監控進程是比前兩者更為緊要的任務。監控進程一般是檢查操作系統中運行的應用進程數，比如對于采用多進程架構的Web應用，就需要檢查工作進程的數量，如果低于預估值，就應當發出報警聲。

磁盤監控主要是監控磁盤的用量。由于日志頻繁寫的緣故，磁盤空間漸漸被用光。一旦磁盤不夠用，將會引發系統的各種問題。給磁盤的使用量設置一個上限，一旦磁盤用量超過警戒值，服務器的管理者就應該整理日志或清理磁盤了。

對于Node而言，一旦出現內存泄漏，不是那么容易排查的。監控服務器的內存使用狀況，可以檢查應用中是否存在內存泄漏的狀況。如果內存只升不降，那么鐵定存在內存泄漏問題。健康的內存使用應當是有升有降，在訪問量大的時候上升，在訪問量回落的時候，占用量也隨之回落。

如果進程中存在內存泄漏，又一時沒有排查解決，有一種方案可以解決這種狀況。這種方案應用于多進程架構的服務集群，讓每個工作進程指定服務多少次請求，達到請求數之后進程就不再服務新的連接，主進程啟動新的工作進程來服務客戶，舊的進程等所有連接斷開后就退出。這樣即使存在內存泄漏的風險，也能有效地規避內存泄漏帶來的影響。但這屬于規避問題，只解決了問題的表象，不推薦使用。

總而言之，監控內存并長時間觀察是防止系統出現異常的好方法。如果突然出現內存異常，也能夠追蹤到是近期的哪些代碼改動導致的問題。

服務器的CPU占用監控也是必不可少的項，CPU的使用分為用戶態、內核態、IOWait等。如果用戶態CPU使用率較高，說明服務器上的應用需要大量的CPU開銷；如果內核態CPU使用率較高，說明服務器花費大量時間進行進程調度或者系統調用；IOWait使用率則反應的是CPU等待磁盤I/O操作。

CPU的使用率中，用戶態小于70%、內核態小于35%且整體小于70%時，處于健康狀態。監控CPU占用情況，可以幫助分析應用程序在實際業務中的狀況。合理設置監控閾值能夠很好地預警。

CPU load又稱CPU平均負載，它用來描述操作系統當前的繁忙程度，可以簡單地理解為CPU在單位時間內正在使用和等待使用CPU的平均任務數。它有3個指標，即1分鐘的平均負載、5分鐘的平均負載、15分鐘的平均負載。CPU load過高說明進程數量過多，這在Node中可能體現在用子進程模塊反復啟動新的進程。監控該值可以防止意外產生。

I/O負載指的主要是磁盤I/O。反應的是磁盤上的讀寫情況，對于Node編寫的應用，主要是面向網絡服務，是故不太可能出現I/O負載過高的情況，大多數的I/O壓力自于數據庫。不管Node進程是否與數據庫或其他I/O密集的應用共處相同的服務器，我們都應監控該值以防萬一。

雖然網絡流量監控的優先級沒有上述項目那么高，但還是需要對流量進行監控并設置上限值。即便應用突然受到用戶的青睞，流量暴漲時也能通過數值感知到網站的宣傳是否有效。一旦流量超過警戒值，開發者就應當找出流量增長的原因。對于正常增長，應當評估是否該增加硬件設備來為更多用戶提供服務。網絡流量監控的兩個主要指標是流入流量和流出流量。

除了這些硬性需要檢測的指標外，應用還應當提供一種機制來反饋其自身的狀態信息，外部監控將會持續性地調用應用的反饋接口來檢查它的健康狀態。

最簡單的狀態反饋就是給監控響應一個時間戳，監控方檢查時間戳是否正常即可。

健壯一些的狀態響應則是將應用的依賴項的狀態打印出來，如數據庫連接是否正常、緩存是否正常等。