SRE Google運維解密——第10章 基於時間序列數據進行有效報警

第10章 基於時間序列數據進行有效報警

• 一個大型的系統不應該要求運維人員持續關注其中使用的無數個小組件，而是應該彙總所有的信息，自動拋棄其中的異常情況。
• 監控系統應該從高級服務質量目標層次進行報警，但是也應該保持足夠的力度，可以追蹤到某個具體組件

Borgmon 的起源

1. 依靠一種標準數據分析模型進行報警。使得批量，大規模，低成本的數據收集變得可能 ，成爲白盒監控
2. 報警規則使用簡單的數學表達式形式表達，所有歷史數據可以用來作爲報警規則計算元素
3. 使用一次對/varz http請求，可以收集到一個監控對象的所有監控指標
4. 可以從其他Borgmon 實例上收集信息，可以建立層級體系，主機彙總監控指標，拋棄無用信息。一般來說每個集羣運行一個Borgmon 實例，在全球範圍內在運行兩個對等的實例。
5. 部署非常的服務集羣內部部署專門收集信息的Borgmon實例，集羣實例用於彙總

應用軟件的監控埋點

1. /varz http 接口 ，文本方式列出監控變量值 如 ： http_response map:code 200:25 404:0 500:12 。定義爲25 個http200響應， 12個http500相應

• 維護起來十分麻煩，Google開發了一個工具來自動校驗Borgmon 規則的正確性

監控指標的收集

1. Borgmon實例配置可自動擴展的需要收集的目標列表，目標位置可以使用各種地址解析服務支持的格式
2. Borgmo按照配置規定的週期，定時抓取/var URL，得到的信息解碼存儲內存中
3. Borgmon 將每個目標收集工作均勻分散在整個週期內，避免Borgmon 多層任務堆積
4. Borgmon同時爲每個監控目標記錄自動生成的合成指標，用在檢測監控任務不可用狀態的規則編寫中
   4.1. 目標是否成功解析成IP和端口
   4.2. 目標是否相應了一次收集請求
   4.3. 目標是否響應了一次健康檢查請求
   4.4. 數據收集成功結束的時間點
   varz 和SNMP(簡單網絡監控協議)非常不同，SNMP協議在設計中需要最簡單的傳輸協議支持，保障其他網絡應用失敗的時候也能正常運行，利用http協議收集監控信息設計理念正好相反

時間序列數據的存儲

1. Borgmon將多軟件服務器指標數據整理統一存儲，也可以靈活查看數據
2. 每份數據按< 時間戳 , value>值進行存儲，值是多標籤的單維矩陣
3. 垃圾回收期定時將過期數據從內存清除，Borgmon 定時將內存狀態歸檔外部數據庫，一般從內存查，或者從外部數據庫(TSDB)查

標籤與向量

1. 某一列（同一類型）的成爲向量，標籤集合指向具體的值
2. 標識一個time-series 標籤必須有以下幾個標籤
   2.1. var : 代表變量名稱
   2.2. job : 被監控軟件服務器類型名
   2.3. service ： 一個鬆散定義的服務器類型組名，可以對外名稱分類，也可以對內名稱分類
3. 標籤的來源
   3.1. 監控目標的名稱，如job 和instance 來源於任務名與實例地址
   3.2. 監控目標自行提供，如提供的Map類型變量
   3.3. Borgmon配置文件，其中可以添加和替換標籤
   3.4. Borgon 規則

Borg 規則計算

1. Borgmon 編程語言，由簡單的代數計算表達式組成，使用一個time-series 作爲輸入，計算另外一個time-series
2. Borgmon 規則一般運行在一個線程池中，受限於規則定義的輸入是否包含謙虛規則輸出。由查詢結果向量大小決定執行速度
3. 彙總計算是分佈式環境中不可缺失的一環，將一個任務中所有實例中某個timeseries 相加，通過計算總數，計算整體速率
4. 彙總舉例 – 非HTTP200 回覆報警
   4.1. 彙總所有實例HTTP回夫的速率，按回復代碼分類得到一個向量
   4.2. 計算所有的“錯誤服務”的速率總和，得到單值，作爲整體集羣的錯誤速率
   4.3. 計算整個集羣的錯誤速率比例，用錯誤回覆速率初一所有請求的速率總和
5. 將有用的結果作爲控制檯的永久圖表

報警

1. 每條報警規則都指定一個最小的持續時間週期，當報警持續時間超過這個值時纔會報警（一般兩個計算週期）
2. Borgmon 連接到全局共享服務，Alertmanager。報警管理服務接收報警進入等待狀態和出發狀態時產生的Alert RPC ，並轉發到合適的通知渠道，配置如下
   1. 當有其他報警出發的時候，一直某些報警
   2. 將多個Borgmon發來的報警信息進行整合排重
   3. 根據標籤信息將收到的報警信息展開或者將多個報警信息整合一個
      詳細的報警策略見第四章

監控系統的分片機制

1. 節約成本設計一種流式傳輸協議，用於Borgmon 之間傳輸timeseries 數據
2. 標準部署模型運行多個Borgmon 負責全局彙總，每個數據中心運行一個Borgmon 負責彙總所在數據中心運行的實例。
3. 更復雜的部署模型中，進一步將數據中心Borgmon 劃分爲一個收集層一個彙總層
   1. 數據收集層主要負責規則運算和彙總
   2. 全局層也會劃分爲計算層和展示層
   3. 上游的Borgmon 可以過濾從下游Borgmon 收集來的信息，全局Borgmon 就不需要保留所有任務實例層的time-series信息

黑盒監控

1. Borgmon是白盒監控系統並不能監控系統所有狀態
   1. 例 白盒監控系統只能看到已經接受的請求，並不能看到由DNS故障導致沒有發送成功的請求
2. 探針程序（黑盒）使用應用級別的自動請求探測目標是否成功返回
3. 探針程序可以直接探測前端，也可以探測負載均衡服務後面的服務

配置文件的維護

1. 配置文件中規則定義與具體目標分開組織，一套規則可以應用到許多不同的收集目標上
2. Borgmon 提供針對Borgmon 規則的單元測試和迴歸測試工具
3. Google內部Borgmon 通用模板庫最大兩類：
   1. 將某一個代碼類庫保羅所有監控系統模板化
   2. 如何將單實例監控數據按級彙總到全局範圍的模型
4. 通過Borgmon標籤機制，可以針對任務進行區分，Borgmon給每個目標添加對應實例名稱，分頁，以及所在的數據中心，可以分組彙總對應的timeseries。標籤作用如下
   1. 標籤可以標記數據維度
   2. 標籤可以標記數據來源
   3. 標籤可以標記局部分組信息和彙總信息

十年之後

1. 保證監控系統維護成本與服務的部署模型呈線性相關增長是非常關鍵的