監控數據的採集

前言

監控數據有多種形式--有些系統會持續地輸出數據，而其餘系統只會在發生罕見事件時生成數據。有些數據可以直接定位問題，有些數據能幫助調查問題。更寬泛的說，擁有監控數據是觀察系統工做情況的必要條件。

不管採集什麼形式的監控數據，核心要點都是同樣的：

採集數據的開銷很小，可是若是在須要的時候沒有數據，代價可就大了。因此有必要檢測全部內容，而且合理地收集全部有用的數據。

指標

指標是在特定時間捕獲的與系統相關的值 -- 好比當前登錄到Web應用程序的用戶數量。所以，一般以固定時間間隔收集指標，好比每秒採集一次，每分鐘採集一次。

咱們把指標主要分紅兩類：工做指標和資源指標。對於軟件依賴的每一個系統，應該考慮哪些工做指標和資源指標是合理的，而且將其所有收集。

工做指標

工做指標經過系統的輸出來獲取系統的運行情況。在考慮採集工做指標時，一般能夠將這些指標分紅四類：

• 吞吐量：系統在單位時間內完成的工做量。吞吐量一般用絕對數值（非百分比這樣的相對數）記錄。
• 成功率：成功執行的工做佔總工做量的百分比
• 錯誤率：產生錯誤結果的工做，一般表示爲每單位時間內的錯誤率。能夠用1減去成功率獲得錯誤率，可是在實際操做中，錯誤率和成功率一般分開採集；尤爲當存在多個潛在的錯誤來源，而且有些來源比其餘其餘來源更重要時，分開採集更是必要的。
• 性能：軟件的工做效率。最多見的性能指標是延遲，延遲表示一個工做單元所需的時間。延遲能夠表示爲平均值或百分比，例如，「99%的請求在0.1秒內返回」。

上面講的指標對於觀察系統的運行情況很是重要。採集到了這些數據能夠快速回答關於系統內部健康和性能最緊迫的問題：系統如今可用嗎？系統如今性能如何？

如下是兩種常見系統的全部四種子類型的工做指標示例。

Web服務器

子類型	描述	值
吞吐量	每秒請求數	312
成功率	兩次測量間2xx的響應百分比	99.1
錯誤率	兩次測量間5xx的響應百分比	0.1
性能	百分之90的請求的響應時間（秒）	0.4

數據存儲服務

子類型	描述	值
吞吐量	每秒查詢次數	949
成功率	兩次測量間成功執行的查詢百分比	100
失敗率	兩次測量間成功執行的查詢百分比	0
失敗率	兩次測量見返回過期數據的查詢百分比	4.2
性能	百分之90的查詢時間（秒）	0.02

資源指標

軟件基礎架構的大多數組件都成爲其餘系統的資源。有一些資源是底層的，好比CPU，內存，磁盤和網絡接口之類的物理組件。若是另一些組件，好比數據庫或者地理定位微服務也能夠被當作是資源，由於其餘的系統須要這些組件來完成工做。

資源指標有助於瞭解系統的詳細狀態，這在調查問題和診斷問題的時候是特別有價值的。資源指標能夠分爲四類：

1. 利用率：資源繁忙時間的百分比，或者資源容量正在使用的百分比
2. 飽和度：當前系統沒法提供服務的請求的數量，一般會把這些請求存在隊列中後續處理
3. 錯誤：在工做過程當中資源產生的內部錯誤
4. 可用性：資源響應請求的時間百分比。僅對能夠主動和按期檢查的資源能夠定義可用性

下面是幾種常見的資源類型的指標示例

資源	利用率	飽和度	錯誤	可用性
磁盤 IO	設備繁忙時間的百分比	等待隊列長度	設備錯誤	可寫的時間的百分比
內存	已使用的內存百分比	swap使用率	（一般觀測不到）	一般觀測不到
微服務	每一個請求服務線程忙的平均時間百分比	請求數量	服務拋出異常	服務可用時間的百分比
數據庫	每一個鏈接繁忙的平均時間百分比	排隊中的查詢	內部錯誤，好比複製錯誤	服務可訪問的時間百分比

其餘指標

還有一些指標，既不是工做指標，也不是資源指標，但這些指標一樣有助於觀察複雜的系統。比較常見的例子是緩存命中數或者數據庫鎖。

事件

除了能夠連續收集的指標外，一些監控系統還能夠捕獲事件，這些事件每每是頻繁的，離散的，但對整個系統的理解是有幫助的。好比：

• 變動：代碼的發佈，構建和構建失敗
• 告警：內部或第三方的通知
• scale事件：增減或減小主機

事件一般帶有足夠的信息，能夠單獨解釋，而不像單個數據點一般只有在上下文中才有意義。

事件會記錄在特定時間點發生的事情，好比

時間	時間	附加信息
Hotfix f464bfe發佈到生產環境了	2015-05-15 04:13:25 UTC	時間：1.2秒
Pull request 1630被合併了	2015–05–19 14:22:20 UTC	commit：ea720d6
每夜數據彙總失敗	2015–05–27 00:03:18 UTC	失敗任務的連接

事件有時候用來生成告警--通知負責人事情的發生，好比上面的第三個例子。不過這些事件更經常使用的用法是調查問題。通常來講，最好像指標同樣考慮這樣的事件--儘量地收集它們。

收集正確的數據

須要收集的數據應該有四個特徵：

• 好理解，而且能快速肯定其含義和收集方式。儘可能讓指標和事件保持簡單。
• 採集粒度。若是採集指標的週期過長，獲得的數據可能沒法正確衡量系統的情況。好比，對低使用率的時段和高使用率的時段進行平均，則這些時段的利用率就估計錯了。所以採集的頻率不能過低；固然也不能過高以致於下降系統的性能。
• 按範圍標記。每一個主機在多個範圍內同時運行，可能須要檢查這些範圍或其組合的整體運行情況。好比：服務整體情況如何？美國東北地區的服務情況如何？某單個服務情況怎麼樣呢？保留與數據關聯的多個範圍很是重要，這樣就能夠對任何範圍的問題發出告警，並快速調查中斷，且不受主機層次結構的限制。
• 長時間存儲。若是過早丟棄數據，或者在一段時間後彙總指標以下降存儲成本，那麼將會丟失有關過去發生事情的重要信息。保留一年或更長時間的原始數據能夠更容易地瞭解「正常」是什麼，特別是指標會隨着月度，季度或年度變化的時候。

結論

• 儘量多地收集工做指標，資源指標和事件。觀測複雜系統須要全面指標
• 收集具備足夠粒度的指標，以顯示重要的峯值和降低。具體的粒度和監控的系統，採集的成本和指標變化之間的持續時間有關。不一樣的指標可能有不一樣的採集粒度，內存或CPU能夠以秒爲粒度統計，能耗能夠用分鐘爲粒度統計。
• 要最大化數據的價值，須要標記具備多個範圍的指標和事件，並將其保留至少15個月