谷歌稱自己對于建立監控告警系統已經形成了一些基本理論，同時也有一些很好的實踐經驗。
一些名詞定義
Monitoring
包含以下幾部分：收集（collecting）處理（processing）聚合（aggregating）展示（displaying）一個系統的實時數值型數據，如請求數與類型，錯誤數與類型，處理時間與服務壽命。
white-box monitoring
白盒監控，根據系統內部暴露的指標進行monitoring，如服務產生的日志，或者JVM的profiling接口
black-box monitoring
dashboard
展示服務核心數據的概覽（summary view）
dashboard可以有過濾器與選擇器，但最核心的是上面的指標一定要和這個系統的直接用戶息息相關
dashboard還可以用于展示ticket queue（這個東西有點類似工單的意思），搞優先級bug的列表，目前處于on-call狀態工程師的信息（谷歌SRE在后面有專門講on-call的章節，由此可以窺探當工具和工作模式相互關聯成網之后的樣貌）
alert
給人讀的提示（關鍵是，有了必須得去讀，如果某類alert沒人關注，那不如沒有）alert會被分成 tickets,emails alerts 以及pages
root cause
node and machine
push
對于系統軟件或配置的一次變更
為啥要Monitoring?
1，分析長期趨勢
其實根據上文的定義，就可以看到，所謂monitoring，并不僅僅是做個花里胡哨的dashboard，而是一個輔助主要業務系統的子系統
monitoring要能幫助分析（這里可能是對于運營人員）我們的數據庫已經多大了，增長的有多快？我們當前的存儲有沒有可能無法滿足30天之后服務需求？
我們服務每天的活躍用戶增長有多少？
從這幾個問題也可以看出，SRE并不是只關心軟件，同樣也關心服務的實際情況（也就是業務）
2，對實驗組進行對比
幫助解決諸如以下問題：我的memcache集群添加一個額外節點之后，緩存命中率有沒有提升？ng代理的版本由1.17升級到1.18后核心性能指標有無變化
個人認為，這里的意思，大致就是制定好架構之后，也可以通過系統的monitoring數據給架構設計以反饋
3，alerting
告警，沒什么好說的，告訴你有東西出問題，需要人給盡快處理好
4，創建dashboard
dashboard是服務的概覽（后面會提到服務的黃金4指標）
5，幫助debug系統問題
對monitoring設置合理的期望
癥狀vs根源
黑盒vs白盒
黃金4指標
簡單說，如果你的monitoring提供不了下面4項數據，那么你在dashboard上設置再多的指標意義也不是很大
latency
服務用于一個請求需要花費的時間，并且應該區分成功請求、異常請求的處理延遲，最好能將不同的異常請求進一步分類與統計
traffic
流量，對于一個流形系統，這項指標會比較關注網絡IO與并發會話的情況。而對于一個key value存儲系統，這項指標會衡量讀寫（transaction and retrive)
errors
錯誤率（也需要精細化，比如HTTP服務的50X錯誤，需要能分開統計）
saturation
服務飽和度，上面幾項都比較好理解
Worrying About Your Tail
這部分的大致意思是選取直方圖(histogram)
