上一講聊過了在系統上線後的維護中，怎麼透過日誌來找到系統問題的所在。延續日誌，我們今天來聊聊如何監控整個系統，讓我們獲取更多資訊以便 Debug，甚至是得到幫助我們做商業決策的一些統計數據。

系統監控

如果我們的服務是建立在自己管理的機器上，可以管理、分配硬體的資源，系統的監控就是相當重要的。

所監控的目標我們稱作指標（Metric），是一種用來衡量系統或服務狀態、行為的量化標準。例如當前的 CPU 使用率為 80% 就是一種指標、現在機器上線與否的 Boolean Value 也能算是一種指標。

四大指標

在搭建一台電腦、設定一座 VM 時，我們通常要指定 CPU 的核心數量、RAM 和 Disk 的大小以及 Network 的頻寬。

在系統的監控中，CPU、RAM、Disk 和 Network 也是最基本的項目。我們基於時間取樣，看每顆 CPU 核心的使用率、RAM 和 Disk 的使用率或者剩餘量，以及 Network 進與出的流量。

當我們使用產品時發現有延遲、卡頓的情況時，第一步就是查看這段時間內的這四個指標。例如 CPU 和 RAM 的使用率很高，有可能是當時有大量的計算任務，也可能是大量的 Requests 需要處理，又或者程式的 Bug 導致卡在無窮迴圈之類的情況。

假如當時的狀況是 Network 的進入流量很高，我們就比較可以推測是大量的 Requests，但若是流量沒有明顯變化，就可能是其他原因。

另外一種情況是 Disk 使用量快滿的情況，通常使用者所造成的資料會線性的增長，不會造成 Disk 突然就變滿。但是當我們的程式發生錯誤，就可能狂打 Log 塞滿 Disk，此時有這個指標監控，並且送出告警訊息就會很有幫助。

透過這些基本的指標，可以給我們初步的訊息來做進一步的推理。

其他常見指標

除了上述四種基本的指標之外，有些資源也蠻值得監控的。

例如 Response Time，當我們收到 API Request 時，多久會將 Response 回覆給 Client。這個指標可以看出平均來說，我們系統花了多久時間來處理請求。

再來是 Error Rate，常見的框架和套件都有提供 Error Rate 的監控，主要聚焦在 HTTP Respond 的 Error Code，例如 4xx 的使用者錯誤，5xx 的系統錯誤等等。而如果我們有實作上一講詳細定義的 Error Codes，就可以在此發揮更多作用，針對不同錯誤的類別來統計。

最後則是 QPS（Query Per Second），這個指標能讓我們對於系統的被使用量有多高，透過這個資訊，也可以搭配產品的需求推算出系統的硬體配置，例如超過 1000 QPS，我們的 CPU Cores、RAM 就至少要配備 2 核心、4 GB RAM。

自定義指標

除了以上指標，也有一些是和商業邏輯有關的自定義指標。

像是不同的 API 呼叫次數，有了這些統計，我們便可以知道開發和維護哪些 API 可以多投入一些資源。反過來說，如果有些 API 幾乎沒有什麼在被使用，有一些不太重要的優化甚至是 Bug 可能都不必花太多時間處理。

另外一些像是 Request 的來源分析，譬如我們的使用者用的都是什麼瀏覽器，可以從 Header 中撈出來；或是根據 IP 位置推測出 Request 是從什麼地區發送的，藉此來對用我們產品的使用者進行初步的分析。

其他的又例如在線使用的人數，可細分成 DAU（Daily Activated Users，日活躍用戶）和 MAU（Monthly Activated Users）。

這些指標在一般我們 Monitor 整個系統上，其實並不會特別去處理，因為我們做監控的目的主要還是聚焦在系統的健康程度上。但若是我們沒有特別的一個團隊來關心這些商業分析的資訊，其實整合在監控的系統也會是不錯的選擇。