好文分享 — 11 essential cloud metrics to monitor for optimal performance
DigitalOcean 近日彙整 1 份針對伺服器效能的 11 項關鍵指標，雖然文章標題寫 cloud metrics, 不過其實 on-premises 也通用。 這些關鍵指標其實也會在後端工程師/DevOps/SRE面試中被詢問到，不過大多數人應該都會回答以下 6 項：
CPU 使用率
一般會保持在 70% 以下，使用率太高代表伺服器相當忙碌，沒有閒暇處理額外的工作
記憶體使用率
一般也會保持在 70% 以下，而且最好設定 90% 時發出警告，因為記憶體不足很容易造成 Out of Memory (OOM)問題，可能會導致 process 被 kill 或者直接無法正常啟動
硬碟容量使用率
通常會看是否使用率太低，可以換成小容量的硬碟以節省營運支出，跟記憶體一樣最好設定 90% 時發出警告，因為有些程式運作需要使用 /tmp 等暫存空間，如果硬碟容量不足也會造成程式無法正常執行
RPS(Requests Per Seconds) 或 RPM(Requests Per Minute)
每秒收到的 requests 數或每分鐘收到的 requests 數，監控此數據對於突然異常增長的 requests 相當有幫助，可以知道現階段的異常是否是因為 requests 量超過伺服器負擔
Latency
數值越低越好，高的話通常代表 network 有問題
Error Rate
公式為
單位時間內發生錯誤的 request 數 / 單位時間內收到的 request 數，發生錯誤的情況越少越好
除此之外，其實還有幾項數值可以觀察：
CPU load average
可以用 top 之類的指令讀取 load1, load5, load15 這 3 個數字，它們分別代表 1 分鐘、 5 分鐘、 15 分鐘內的 CPU 平均負載，合理數字在 0.7 * CPU 核心數以下，如果你的合理值設定為 60% ，則可以改為 0.6 * CPU 核心數
Disk I/O
可以用 iostat 之類的指令，觀察 Disk 讀寫的情況，如果 Disk 是讀的情況遠高於寫，其實可以考慮用 memory cache 之類的技術增加效能，如果 Disk 是寫的情況遠高於讀，則可以考慮使用寫入效率較好的 Disk 改善效能
平均修復時間(Mean Time To Repair, MTTR)
一項產品發生問題從故障狀態轉為正常狀態所花費的平均時間。通常這項指標代表我們可以多快對問題作出反應， MTTR 越高代表我們對突發事故反應能力越低，系統的可靠性(reliability)與可用性(availabity)也越低
平均故障時間間隔(Meat Time Between Failures, MTBF)
這個數值代表發生問題的頻率，如果 MTBF 越小，代表產品越容易故障、不穩定、出包
以上是我個人心得總結，有興趣的話可以進一步閱讀原文。
11 essential cloud metrics to monitor for optimal performance
