第十五篇：穩定性之分布式監控

什麼是黑/白監控

黑盒監控所描述的是監控外部使用者可見的系統行為，主要關注的現象，重點在于對正在發生的故障進行監控告警，例如，某某網站打不開了，或者服務挂掉了，無法為使用者提供服務。

白盒監控所描述的是監控内部暴露出來的關鍵名額，主要關注的原因，重點也是關注其發生的原因，例如服務挂掉了，是什麼原因導緻的呢，是記憶體溢出還是服務過載，這些是導緻服務挂掉的原因。

兩者差別是一個對外，通過外部現象、另一個對内，通過對内究其原因，兩者監控次元也不相同：

• 監控次元不同，黑盒更偏向外側，可以了解通過某個功能或者接口來觀測其SLA，它并清楚其内部實作；而白盒更傾向于從内測監控，可了解從代碼依賴關鍵中間資訊 埋點資訊、關鍵名額的Metrics，它是代碼層面，從内部時間來監控整個系統。
• 面向對象不同，黑盒監控更多面向問題的現象，如某某服務挂了，功能不能用了，頁面打不開了了；而白盒更加傾向于問題的本質，産生問題的原因，例如導緻挂了的原因是記憶體溢出、還是大量Panic等等。

實際場景中的黑盒監控、一般可以細分為如下：

• 證書檢測，檢測證書是否有效、來確定使用者是否可以正常通路。當下多數網站服務基本上都是使用的HTTPS，一旦證書出現了問題，則浏覽器或者網絡請求架構（httpclient）則認定該通路不安全，并組織使用者通路。
• 端到端功能檢測，一般情況下都通過自動化測試工具來進行檢測，進而确認資料格式及資料是否正确。
• 端口探活，端口探活是利用通過看門狗來定期檢測端口是否存活，來标記服務狀态或者告警或挂掉之後的操作。

實際場景中的白盒監控，一般是通過下列資料次元，來進行白盒監控：

• 日志（Log）：通過日志記錄可以了解程式運作的狀态資訊，包括異常資訊等。
• 名額（Metrics）：通過數值名額的形式，可以幫助了解系統的内部資源走向趨勢等情況。
• 鍊路追蹤（Tracing）：通過鍊路追蹤能了解到每一次程式運作的軌道，及軌道上的蛛絲馬迹，便于對軌道行迹分析和優化。

監控的用途

如果我們對監控的使用者，簡簡單單的以為隻是監控有沒有問題，如有問題就告警，說明對監控的了解還不夠深入，這隻是其中一部分，下面來一起看看監控的用途還有哪些。

分析長期趨勢

通過白盒監控的名額（Metrics）收集，能夠分析出去目前的資料量，使用者量等等，及它們的增長趨勢，通過分析長期趨勢，來做出響應的動作，如資料量一旦過大，相比會影響查詢的性能，或者流量的增長趨勢是連續增長的話，那麼需要評估目前的容量是否能夠容納這些流量。

名額對比

通過名額對比，一般是通過不同時間段的對比，實驗組與對照組的對比等，來對比那一組性能更好或更能滿足，如伺服器擴容前或擴容後的對比，緩存的增加前後、優化前後的指令中率是否有更好的提升。

告警

通過發告警及時的講故障通知，需要有人關注，如那個服務挂了，在什麼時間點挂掉了，需要有人及時處理。

監控大盤

通過監控大盤能夠清晰的表明有關服務的問題，通常會包括常見的4個黃金名額，分别是錯誤、延遲、流量和飽和度。如通過大盤可以看到某服務的錯誤率，或者目前服務的流量情況。

回溯分析

通過回溯分析來觀察系統的運作狀态，一般可以通過流量回訪，或者放大來觀測系統的運作狀态，或者通過故障注入的方式來觀測系統的運作狀态。

黃金名額

無論業務系統如何複雜，監控名額如何眼花缭亂，但萬變不離其宗，監控的目的無非是為了解服務運作狀況、發現服務故障和幫助定位故障原因。為了達成這個目的，Google SRE總結的監控四個黃金名額對我們添加監控具有非常重要的指導意義，分别是錯誤、延遲、流量和飽和度。下面我們就這四個黃金名額分别展開說明，并給出一些監控項的采集執行個體。

四個黃金名額的名額資訊基本上都可以分為兩個次元來，一方面是基礎（資源）名額監控，另一方面是業務名額監控。

• 基礎（資源）名額監控：指的伺服器或雲主機的CPU、記憶體、磁盤資源的使用情況，一般情況下都是以叢集方式提供服務，某台伺服器出現該名額故障，并不代表該服務的無法運作。
• 業務名額監控：指的是業務系統内部的運作狀态，或者業務相關名額，多數情況下通過基礎名額監控和業務名額監控結合來看，更全面的了解系統的情況。

延遲（latency）

延遲指的是服務處理請求所需的時間，服務延遲的上升不僅僅展現在使用者體驗的下降，也有可能導緻請求堆積并最終演變為整個業務系統的雪崩。實際場景中，更多關心的接口耗時，如某個由于資料庫連接配接丢失或者其他後端問題造成的 HTTP 500 錯誤可能延遲很低。計算總體延遲時，如果将 500 回複的延遲也計算在内，可能會産生誤導性的結果。但是慢錯誤要比快錯誤更糟，是以監控錯誤的延遲也是非常的重要。

延遲監控名額：

• 基礎監控：IO等待、網絡延遲
• 業務監控：接口、服務的平均耗時如TP90、TP99、TP999等、DB、緩存的慢查詢

延遲在系統中還是非常常見的，另外也是十分關鍵的名額，白盒延遲名額往往真實回報系統内部的延遲，對此建議對核心業務添加黑盒監控，監控該業務延遲名額。

值的注意的是：

• 區分成功請求的延遲和失敗請求的延遲很重要
• 慢錯誤（響應時間長）比快錯誤（響應時間短）更糟糕
• 跟蹤出錯請求的延遲

流量（traffic）

使用系統中的某個高層次的名額對系統負載需求所進行的度量，通過流量來表象系統的負載情況，能夠根據流量來判斷目前服務的承載壓力、請求量。對于 Web 伺服器來說，該名額通常是每秒 HTTP 請求數量，同時可能按請求類型分類(靜态請求與動态請求)；針對音頻流媒體系統來說，這個名額可能是網絡 I/O 速率，或者并發會話數量；針對鍵值對存儲系統來說，名額可能是每秒交易數量，或每秒的讀取操作數量。

流量監控名額：

• 基礎監控：磁盤和網卡IO
• 業務監控：服務層面的QPS、PV和UV、各狀态業務訂單TPM、針對音頻流媒體系統來說，這個名額可能是網絡I/O速率，或者并發會話數量、針對鍵值對存儲系統來說，名額可能是每秒交易數量，或每秒的讀取操作數量

我們常說的容量規劃，其實是流量規劃，通過流量可得知目前系統的運作狀态庫，是否達到了它的負荷上限，通過監控流量相關的名額，可以得知我們業務的高峰期，流量的突增突降的情況，進而可以對系統進一步的了解。

錯誤（error）

錯誤是指目前系統發生的錯誤請求，請求失敗的速率，要麼是顯示錯誤(HTTP 500)，要麼是隐式錯誤(HTTP 200 回複中包含了錯誤内容)。可以通過錯誤請求個數計算出相應的錯誤率，通過錯誤率來回報服務的運作狀态。

錯誤可以分為兩大類錯誤，一類是顯示錯誤、另一類是隐士錯誤：

• 顯示錯誤、指可以立即看出來的錯誤。比如在 HTTP 請求中，響應狀态碼出現 500，則可以認定為是顯示錯誤。
• 隐式錯誤：指表面上顯示完全正确，但是在資料中已經出現異常的錯誤。如 HTTP狀态是200，但是接口内部還有業務本身自定義的狀态碼來判斷是否正确。這類錯誤就是隐士錯誤，屬于業務類。

錯誤監控名額：

• 基礎監控：當機、磁盤（壞盤或檔案系統錯誤）、程序或端口挂掉、網絡丢包
• 業務監控：錯誤日志、業務狀态碼、錯誤碼走勢

錯誤是在添加監控時首要關注的監控名額，更能回報出業務的錯誤率，主要功能或接口、以及内部存在明顯邊界的功能子產品和上遊依賴子產品，都應該添加端到端的監控。

飽和度（saturation）

飽和度通常是指某個資源的使用率。通常指的是我們通過容量的最大值和現在的使用量，來判斷這個容量是否“滿”了。某些程式，如果資源飽和度過高，可能會導緻執行緩慢，甚至無法使用。如 CPU 使用率如果達到 100%，會出現執行緩慢；Dubbo 進行 RPC 調用時，如果線程池沒有可用的線程數，則會使業務受到阻礙。記憶體溢出。

飽和度一般也會配合其他名額一起使用，比如在使用網絡 I/O 時，網卡都是有流量上限的，我們通過流量上限值和目前網絡 I/O 的使用情況，可以得知相應的飽和度。飽和度是衡量我們這個系統是否到達瓶頸的關鍵。如飽和度過高，這時候就需要考慮擴容、減少資料量或是其他降低飽和度的操作了。

飽和度監控名額：

• 基礎監控：CPU使用率、I/O使用率、記憶體使用率、隊列積壓長度
• 業務監控：線程池使用率，連接配接池。

通常通過飽和度來度量服務的資源使用率是否達到極限，及流量增長趨勢來進行容量規劃，一般情況下飽和度不建議将使用率打滿，否則一旦打滿可能導緻服務出現雪崩的情況。

監控名額定義

名額的含義和精度是不同的，不同的名額觀測的精度是不同的，系統應當以不同名額的不同精度進行度量和觀測

• 觀察 1 分鐘内的 CPU 平均值可能會錯失導緻長尾延遲過高的某種較長時間的 CPU 峰值現象。
• 對于一個每年停機時間小于 9 小時的 Web 服務來說(年度可用綠 99.9%)，每分鐘檢測 1 次或 2 次的監控頻率可能過于頻繁。
• 對目标可用率為 99.9%的某個服務每 1 分鐘或者 2 分鐘檢查一次硬碟剩餘空間可能也是沒必要的。
• 觀測近兩周内流量增長趨勢，可能比觀測近一天内的流量增長趨勢，更加明确。

監控系統設計

監控系統是從多個次元，多個視角監控，比如業務資料監控，系統資源監控，中間件監控，資料庫監控等，監控是系統的眼睛，通過加入埋點、名額監控、資料監控，能及時發現系統出現的問題，及時介入處理，及時止損。

監控是在設計階段就必須考慮監控，而不是在實施完畢之後補充。例如在需求階段就要考慮關鍵名額監控項，這就是度量驅動開發 (Metrics Driven Development) 的理念。

監控也是提高整個平台可用性的一個重要手段，多平台進行多個次元的監控；子產品在運作時候是透明的，以達到運作期白盒化。

立體化監控

立體化就是将故障分析和定位時涉及的所有的相關資訊都要監控起來，共分為5層，具體各層和含義如下：

業務層

收集和分析業務層的通路量、成功率等名額。例如當系統被刷的時候，業務層能夠一目了然的看出通路量會增加很多

應用服務層

應用服務層指的是以URI為次元的分析，可以看到某個URI的通路量、HTTP響應碼分布、HTTP響應時間等名額。應用服務層與業務層并不是一 一對應的關系，一個業務可能對應多個應用服務層的URI，一個URI也可能對應多個業務層的業務。

接口調用層

接口調用層指的是系統依賴的外部系統接口，收集的資訊包括通路情況，包括時延、錯誤碼、次數等，當外部系統故障導緻我們的業務故障時，通過接口調用層就能夠快速的定位具體問題。

基礎元件層

基礎元件層指系統依賴的底層元件，例如容器、資料庫、緩存、消息隊列。不同的元件收集的資訊不一樣，例如資料庫MySQL的監控名額包括連接配接數、請求數、查詢行數、更新行數等，而緩存memcached包括使用率、踢出率、命中率等。

基礎設施層

基礎設施層指作業系統狀态、網絡狀态，收集的資訊包括cpu使用率、記憶體使用率、網卡流量、連接配接數等。

告警設計

如果沒有實時報警，系統運作狀态的不确定性會造成無法量化的災難。是以監控系統名額如下：

• 實時性-要能夠實作秒級監控
• 全面性-覆寫所有系統業務，確定無死角覆寫
• 實用性-預警分為多個級别，監控人員可以友善實用地根據預警嚴重程度做出精确的決策
• 多樣性-預警方式提供推拉模式，包括短信，郵件，可視化界面，友善監控人員及時發現問題
• 收斂性-對于同樣的告警，防止告警泛濫，能夠對告警收斂，并根據收斂規則進一步根據告警重要程度更新告警。

監控設計原則

• 挑選最能反映真實故障的告警規則，這些規則應該足夠簡單、可預測性強、非常可靠
• 不常用的資料、聚合和告警規則應定期清理，例如一個季度都沒有用到一次就立即删除
• 已收集但沒有配置任何看闆的名額，應定期清理
• 監控一體化平台，而非監控零散到各個平台
• 監控應是多元度，而不是單一次元
• 不允許沒有監控的系統上線。

小結