前言
監(jiān)控數(shù)據(jù)有多種形式--有些系統(tǒng)會持續(xù)地輸出數(shù)據(jù)，而其他系統(tǒng)只會在發(fā)生罕見事件時生成數(shù)據(jù)。有些數(shù)據(jù)能夠直接定位問題，有些數(shù)據(jù)能幫助調(diào)查問題。更寬泛的說，擁有監(jiān)控數(shù)據(jù)是觀察系統(tǒng)工作狀況的必要條件。
無論采集什么形式的監(jiān)控數(shù)據(jù)，核心要點都是一樣的：
采集數(shù)據(jù)的開銷很小，但是如果在需要的時候沒有數(shù)據(jù)，代價可就大了。所以有必要檢測所有內(nèi)容，并且合理地收集所有有用的數(shù)據(jù)。
指標(biāo)
指標(biāo)是在特定時間捕獲的與系統(tǒng)相關(guān)的值 -- 比如當(dāng)前登陸到Web應(yīng)用程序的用戶數(shù)量。因此，通常以固定時間間隔收集指標(biāo)，比如每秒采集一次，每分鐘采集一次。
我們把指標(biāo)主要分成兩類：工作指標(biāo)和資源指標(biāo)。對于軟件依賴的每個系統(tǒng)，應(yīng)該考慮哪些工作指標(biāo)和資源指標(biāo)是合理的，并且將其全部收集。
工作指標(biāo)
工作指標(biāo)通過系統(tǒng)的輸出來獲取系統(tǒng)的運行狀況。在考慮采集工作指標(biāo)時，通?？梢詫⑦@些指標(biāo)分成四類：
- 吞吐量：系統(tǒng)在單位時間內(nèi)完成的工作量。吞吐量通常用絕對數(shù)值（非百分比這樣的相對數(shù)）記錄。
- 成功率：成功執(zhí)行的工作占總工作量的百分比
- 錯誤率：產(chǎn)生錯誤結(jié)果的工作，通常表示為每單位時間內(nèi)的錯誤率?？梢杂?減去成功率得到錯誤率，但是在實際操作中，錯誤率和成功率通常分開采集；尤其當(dāng)存在多個潛在的錯誤來源，并且有些來源比其他其他來源更重要時，分開采集更是必要的。
- 性能：軟件的工作效率。最常見的性能指標(biāo)是延遲，延遲表示一個工作單元所需的時間。延遲可以表示為平均值或百分比，例如，“99%的請求在0.1秒內(nèi)返回”。
上面講的指標(biāo)對于觀察系統(tǒng)的運行狀況非常重要。采集到了這些數(shù)據(jù)可以快速回答關(guān)于系統(tǒng)內(nèi)部健康和性能最緊迫的問題：系統(tǒng)現(xiàn)在可用嗎？系統(tǒng)現(xiàn)在性能如何？
以下是兩種常見系統(tǒng)的所有四種子類型的工作指標(biāo)示例。
Web服務(wù)器
| 子類型 | 描述 | 值 |
|---|---|---|
| 吞吐量 | 每秒請求數(shù) | 312 |
| 成功率 | 兩次測量間2xx的響應(yīng)百分比 | 99.1 |
| 錯誤率 | 兩次測量間5xx的響應(yīng)百分比 | 0.1 |
| 性能 | 百分之90的請求的響應(yīng)時間（秒） | 0.4 |
數(shù)據(jù)存儲服務(wù)
| 子類型 | 描述 | 值 |
|---|---|---|
| 吞吐量 | 每秒查詢次數(shù) | 949 |
| 成功率 | 兩次測量間成功執(zhí)行的查詢百分比 | 100 |
| 失敗率 | 兩次測量間成功執(zhí)行的查詢百分比 | 0 |
| 失敗率 | 兩次測量見返回過時數(shù)據(jù)的查詢百分比 | 4.2 |
| 性能 | 百分之90的查詢時間（秒） | 0.02 |
資源指標(biāo)
軟件基礎(chǔ)架構(gòu)的大多數(shù)組件都成為其他系統(tǒng)的資源。有一些資源是底層的，比如CPU，內(nèi)存，磁盤和網(wǎng)絡(luò)接口之類的物理組件。如果另外一些組件，比如數(shù)據(jù)庫或者地理定位微服務(wù)也可以被看成是資源，因為其他的系統(tǒng)需要這些組件來完成工作。
資源指標(biāo)有助于了解系統(tǒng)的詳細(xì)狀態(tài)，這在調(diào)查問題和診斷問題的時候是特別有價值的。資源指標(biāo)可以分為四類：
- 利用率：資源繁忙時間的百分比，或者資源容量正在使用的百分比
- 飽和度：當(dāng)前系統(tǒng)無法提供服務(wù)的請求的數(shù)量，通常會把這些請求存在隊列中后續(xù)處理
- 錯誤：在工作過程中資源產(chǎn)生的內(nèi)部錯誤
- 可用性：資源響應(yīng)請求的時間百分比。僅對可以主動和定期檢查的資源可以定義可用性
下面是幾種常見的資源類型的指標(biāo)示例
| 資源 | 利用率 | 飽和度 | 錯誤 | 可用性 |
|---|---|---|---|---|
| 磁盤 IO | 設(shè)備繁忙時間的百分比 | 等待隊列長度 | 設(shè)備錯誤 | 可寫的時間的百分比 |
| 內(nèi)存 | 已使用的內(nèi)存百分比 | swap使用率 | （通常觀測不到） | 通常觀測不到 |
| 微服務(wù) | 每個請求服務(wù)線程忙的平均時間百分比 | 請求數(shù)量 | 服務(wù)拋出異常 | 服務(wù)可用時間的百分比 |
| 數(shù)據(jù)庫 | 每個連接繁忙的平均時間百分比 | 排隊中的查詢 | 內(nèi)部錯誤，比如復(fù)制錯誤 | 服務(wù)可訪問的時間百分比 |
其他指標(biāo)
還有一些指標(biāo)，既不是工作指標(biāo)，也不是資源指標(biāo)，但這些指標(biāo)同樣有助于觀察復(fù)雜的系統(tǒng)。比較常見的例子是緩存命中數(shù)或者數(shù)據(jù)庫鎖。
事件
除了可以連續(xù)收集的指標(biāo)外，一些監(jiān)控系統(tǒng)還可以捕獲事件，這些事件往往是頻繁的，離散的，但對整個系統(tǒng)的理解是有幫助的。比如：
- 變更：代碼的發(fā)布，構(gòu)建和構(gòu)建失敗
- 告警：內(nèi)部或第三方的通知
- scale事件：增減或減少主機(jī)
事件通常帶有足夠的信息，可以單獨解釋，而不像單個數(shù)據(jù)點通常只有在上下文中才有意義。
事件會記錄在特定時間點發(fā)生的事情，比如
| 時間 | 時間 | 附加信息 |
|---|---|---|
| Hotfix f464bfe發(fā)布到生產(chǎn)環(huán)境了 | 2015-05-15 04:13:25 UTC | 時間：1.2秒 |
| Pull request 1630被合并了 | 2015–05–19 14:22:20 UTC | commit：ea720d6 |
| 每夜數(shù)據(jù)匯總失敗 | 2015–05–27 00:03:18 UTC | 失敗任務(wù)的鏈接 |
事件有時候用來生成告警--通知負(fù)責(zé)人事情的發(fā)生，比如上面的第三個例子。不過這些事件更常用的用法是調(diào)查問題。一般來說，最好像指標(biāo)一樣考慮這樣的事件--盡可能地收集它們。
收集正確的數(shù)據(jù)
需要收集的數(shù)據(jù)應(yīng)該有四個特征：
- 好理解，并且能快速確定其含義和收集方式。盡量讓指標(biāo)和事件保持簡單。
- 采集粒度。如果采集指標(biāo)的周期過長，得到的數(shù)據(jù)可能無法正確衡量系統(tǒng)的狀況。比如，對低使用率的時段和高使用率的時段進(jìn)行平均，則這些時段的利用率就估計錯了。因此采集的頻率不能太低；當(dāng)然也不能太高以至于降低系統(tǒng)的性能。
- 按范圍標(biāo)記。每個主機(jī)在多個范圍內(nèi)同時運行，可能需要檢查這些范圍或其組合的總體運行狀況。比如：服務(wù)總體狀況如何？美國東北地區(qū)的服務(wù)狀況如何？某單個服務(wù)狀況怎么樣呢？保留與數(shù)據(jù)關(guān)聯(lián)的多個范圍非常重要，這樣就可以對任何范圍的問題發(fā)出告警，并快速調(diào)查中斷，且不受主機(jī)層次結(jié)構(gòu)的限制。
- 長時間存儲。如果過早丟棄數(shù)據(jù)，或者在一段時間后匯總指標(biāo)以降低存儲成本，那么將會丟失有關(guān)過去發(fā)生事情的重要信息。保留一年或更長時間的原始數(shù)據(jù)可以更容易地了解“正?！笔鞘裁?，特別是指標(biāo)會隨著月度，季度或年度變化的時候。
結(jié)論
- 盡可能多地收集工作指標(biāo)，資源指標(biāo)和事件。觀測復(fù)雜系統(tǒng)需要全面指標(biāo)
- 收集具有足夠粒度的指標(biāo)，以顯示重要的峰值和下降。具體的粒度和監(jiān)控的系統(tǒng)，采集的成本和指標(biāo)變化之間的持續(xù)時間有關(guān)。不同的指標(biāo)可能有不同的采集粒度，內(nèi)存或CPU可以以秒為粒度統(tǒng)計，能耗可以用分鐘為粒度統(tǒng)計。
- 要最大化數(shù)據(jù)的價值，需要標(biāo)記具有多個范圍的指標(biāo)和事件，并將其保留至少15個月
