Monitoring
監控的目的
警報
有東西故障了，需要有人修復。這當然要隨時監控服務的狀態才可以做到。
檢測效能改善
當今天對系統做了某些更新，或許是改變了使用的資料庫，加上了一些快取，更改了一些流程等等...有時候我們或許可以透過數學的方法證明它會比較快（e.g. 時間複雜度明顯低一個數量級），然而更多時候是需要實際運行過後才能確定前後的差別。若是可以收集一些運行時的數據，像是使用者等待的時間，便可以有充分的證據證明。
尋找效能瓶頸
有時候我們可能會遇到一些效能的問題，可是卻沒辦法直接指出是服務中的哪個元件拖慢了效能，若有統計一些效能相關的數據，可能可以幫我們找出效能的瓶頸在哪。
容量規劃
當服務需要提供給更多人使用的時候，該如何確定當前的硬體設備是否足夠？需要更換更好的機器嗎？就算服務有自動擴展的能力，那也需要確定流量上升之後是否會超出預算，畢竟機器也是要錢的。若平時就有監測相關的硬體數據，就能有足夠的信心去規劃。
現象與原因
監控系統需要指出兩個問題：誰壞了，以及為什麼。這兩件事情分別對應到了現象 (symptom) 以及原因 (cause)，一個現象背後可能會有多個原因。舉例來說今天使用者連不上網頁，可能是因為 DNS 出了問題、實體機器故障，server 的 process 沒有成功跑起來、防火牆設定失誤。
理解這點對於降低警報的雜訊很有幫助，一個可能的策略是僅在確定使用者會受到影響的時候發出警報，並把已知的潛在原因列出來，這樣在處理問題的時候會更有效率。
現象容易從外部觀測，也就是說不必知道系統內部的架構，就可以確定現在「發生了一個問題」，所以會讓警報的規則較容易維護，而不會隨著系統的迭代而需要時常修改。
四個黃金訊號 (Four Golden Signals)
那麼我們應該監控哪些東西呢？在 SRE books 裡面，Google 提出了「四個黃金訊號」：
延遲 (Latency)
延遲表示處理某個請求所花的時間，這項指標會直接影響使用者的體驗，畢竟我們都不喜歡等待。所以當延遲開始異常的升高，那麼就是一個發出警報的合理時機。然而需要注意的是，在統計延遲的時候把成功跟失敗的請求分開會比較好，因為失敗的請求通常會因為不需進行後續處理而有偏低的延遲。
流量 (Traffic)
流量通常直接代表系統承受了多大的壓力，像是以一個網路服務來說，它可能是單位時間的 HTTP 請求數量，紀錄流量並配合其他指標可以幫助我們判斷系統具體的承受能力。
錯誤 (Errors)
服務產生的錯誤，又會被分類為顯示錯誤，例如一個 HTTP 500 的回覆；或是隱式的錯誤，例如內容錯誤的 HTTP 400 回覆，雖然後者通常較難統計（因為可能含有一些複雜的規則），但若是可以把這些類型的錯誤都記錄下來的話可以更好的監測到服務中的錯誤。
另外一點是，比起錯誤的數量，比例可能更為重要，因為數量會隨著收到請求數量上升，例如說今天在十萬筆請求中含有一千筆錯誤，跟在一萬筆請求中含有一千筆錯誤是不同的意義，後者對於使用者的影響顯然更為嚴重。
飽和度 (Saturation)
飽和度直接地指出了服務現在有多「滿」，通常會是 CPU、記憶體或是硬碟等用量資訊，監控這些指標可以幫助我們即早準備處理接下來即將發生的問題，或是透過自動化的手段去處理他們。
長尾問題
收集到數據之後，我們應該如何去理解它呢？有些人或許會選擇觀察平均值，然而這不是一個好主意，因為離群值可能會對它造成嚴重的波動，舉 HTTP 請求的延遲來當例子，若是有 1% 的請求花了十倍於平均值的時間，那麼剩下的請求只需要花平均時間的一半。
考慮使用百分位數 (percentile) 可能是個比較好的選擇，在看人家設計監控的指標時會聽到的那些 p99、p95 之類的術語，指的就是這個概念。也就是說統計時我們只看比較快的那部分資料，因為這可以有效反應出「大部分」使用者的體驗。