好文分享 — 11 essential cloud metrics to monitor for optimal performance

DigitalOcean 近日彙整 1 份針對伺服器效能的 11 項關鍵指標,雖然文章標題寫 cloud metrics, 不過其實 on-premises 也通用。 這些關鍵指標其實也會在後端工程師/DevOps/SRE面試中被詢問到,不過大多數人應該都會回答以下 6 項:

  1. CPU 使用率

    一般會保持在 70% 以下,使用率太高代表伺服器相當忙碌,沒有閒暇處理額外的工作

  2. 記憶體使用率

    一般也會保持在 70% 以下,而且最好設定 90% 時發出警告,因為記憶體不足很容易造成 Out of Memory (OOM)問題,可能會導致 process 被 kill 或者直接無法正常啟動

  3. 硬碟容量使用率

    通常會看是否使用率太低,可以換成小容量的硬碟以節省營運支出,跟記憶體一樣最好設定 90% 時發出警告,因為有些程式運作需要使用 /tmp 等暫存空間,如果硬碟容量不足也會造成程式無法正常執行

  4. RPS(Requests Per Seconds) 或 RPM(Requests Per Minute)

    每秒收到的 requests 數或每分鐘收到的 requests 數,監控此數據對於突然異常增長的 requests 相當有幫助,可以知道現階段的異常是否是因為 requests 量超過伺服器負擔

  5. Latency

    數值越低越好,高的話通常代表 network 有問題

  6. Error Rate

    公式為 單位時間內發生錯誤的 request 數 / 單位時間內收到的 request 數 ,發生錯誤的情況越少越好

除此之外,其實還有幾項數值可以觀察:

  1. CPU load average

    可以用 top 之類的指令讀取 load1, load5, load15 這 3 個數字,它們分別代表 1 分鐘、 5 分鐘、 15 分鐘內的 CPU 平均負載,合理數字在 0.7 * CPU 核心數以下,如果你的合理值設定為 60% ,則可以改為 0.6 * CPU 核心數

  2. Disk I/O

    可以用 iostat 之類的指令,觀察 Disk 讀寫的情況,如果 Disk 是讀的情況遠高於寫,其實可以考慮用 memory cache 之類的技術增加效能,如果 Disk 是寫的情況遠高於讀,則可以考慮使用寫入效率較好的 Disk 改善效能

  3. 平均修復時間(Mean Time To Repair, MTTR)

    一項產品發生問題從故障狀態轉為正常狀態所花費的平均時間。通常這項指標代表我們可以多快對問題作出反應, MTTR 越高代表我們對突發事故反應能力越低,系統的可靠性(reliability)與可用性(availabity)也越低

  4. 平均故障時間間隔(Meat Time Between Failures, MTBF)

    這個數值代表發生問題的頻率,如果 MTBF 越小,代表產品越容易故障、不穩定、出包

以上是我個人心得總結,有興趣的話可以進一步閱讀原文。

11 essential cloud metrics to monitor for optimal performance

Facebook Threads X

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!