昨天稍微談到了一些有關警報的設計，然而，警報的發出與否，應是建立在我們觀測到的一些系統的行為，例如說在 Day 3 架設的 status page，就是基於「是否可以連上網頁」這個條件來判斷。但是像昨天提到的硬碟使用率，就不是一個可以透過客戶端觀測到的數值，既然觀測不到，那麼就更無從談起如何做警報。
為什麼要監控？軟體開發完部署上去不是就跑得好好的了嗎？在我當初修軟體工程的時候，完全沒有考慮到相關的問題。直到 NOJ 真的上線跑了一陣子之後，才發現有些問題，是必須得要在服務運行時，收集一些數據後才能處理的，舉幾個例子來說：
監控系統需要指出兩個問題：誰壞了，以及為什麼。這兩件事情分別對應到了現象 (symptom) 以及原因 (cause)，一個現象背後可能會有多個原因。舉例來說今天使用者連不上網頁，可能是因為 DNS 出了問題、實體機器故障，server 的 process 沒有成功跑起來、防火牆設定失誤等等，族繁不及備載。
理解這點對於降低警報的雜訊很有幫助，一個可能的策略是僅在確定使用者會受到影響的時候發出警報，並把已知的潛在原因列出來，這樣在處理問題的時候會更有效率。
而且另外一點，現象容易從外部觀測，也就是說我不必知道系統內部的架構，就可以確定現在「發生了一個問題」，所以會讓警報的規則較容易維護，而不會隨著系統的迭代需要時常修改。
那麼，我們應該監控哪些東西呢，在 SRE books 裡面，google 提出了「四個黃金訊號」：
延遲表示處理某個請求所花的時間，這項指標會直接的影響使用者的體驗，畢竟我們都不喜歡等待。所以當延遲開始異常的升高，那麼就是一個發出警報的合理時機。然而需要注意的是，在統計延遲的時候把成功跟失敗的請求分開會比較好，因為失敗的請求通常會因為不需進行後續處理而有偏低的延遲。
流量通常直接代表系統承受了多大的壓力，像是以一個網路服務來說，它可能是單位時間的 HTTP 請求數量，紀錄流量並配合其他指標可以幫助我們判斷系統具體的承受能力。
服務產生的錯誤，又會被分類為顯示錯誤，例如一個 HTTP 500 的回覆；或是隱式的錯誤，例如內容錯誤的 HTTP 200 回覆，雖然後者通常較難統計（因為可能含有一些複雜的規則），但若是可以把這些類型的錯誤都記錄下來的話可以更好的監測到服務中的錯誤。
另外一點是，比起錯誤的數量，比例可能更為重要，因為數量會隨著收到請求數量上升，例如說今天在十萬筆請求中含有一千筆錯誤，跟在一萬筆請求中含有一千筆錯誤是不同的意義，後者對於使用者的影響顯然更為嚴重。
飽和度直接地指出了服務現在有多「滿」，通常會是 CPU、記憶體或是硬碟等用量資訊，監控這些指標可以幫助我們即早準備處理接下來即將發生的問題，或是透過自動化的手段去處理他們。
收集到了數據之後，我們應該如何去理解它呢？有些人或許會選擇觀察平均值，然而這不是一個好主意，因為離群值可能會對它造成嚴重的波動，舉 HTTP 請求的延遲來當例子，若是有 1% 的請求花了十倍於平均值的時間，那麼剩下的請求只需要花平均時間的一半。
所以考慮使用百分位數 (percentile) 可能是個比較好的選擇，在看人家設計監控的指標時會聽到的那些 p99、p95 之類的術語，指得就是這個概念。也就是說統計時我們只看比較快的那部分資料，因為這可以有效反應出「大部分」使用者的體驗。
今天討論了監控系統以及指標的設計有哪些相關概念，老實說在看這一部份的時候對我來說真的是像在看天書，有不少概念都難以理解，需要自己額外查不少補充資料，都沒時間做迷因圖了。接下來的幾天，就來紀錄架設監控系統的過程吧。
iThome鐵人賽
看影片追技術