最近在團隊中給大家做了一個分享，泛泛地聊了一些有關「監控」的話題。
其實做分享對分享者的作用往往大于參與者。
這是一次將自己知識的梳理的過程，于是我將這次分享整理成這篇文章。

201706/stock-exchange.png

目的 ??

我們先來聊聊，什么是「監控」，以及我們期望通過「監控」完成哪些目的？

傳統意義上的監控，是指：

通過一些手段和工具，關注運行中的硬件、軟件、用戶體驗的關鍵數據，將其暴露出來。
當關鍵數據出現異常時候發出警告，進行人工或者自動的響應。

我們平時看到的最常見的監控系統，比如 Zabbix，提供了豐富的模板，
可以監控服務器的 Load / CPU Usage / Alive 這些常規指標。
并在出現問題時候，對其進行報警通知。
隨后運維工程師們會上線進行應急操作，case by case 的處理故障。

我將上面的使用目的歸納為：

• 故障發生時提供數據報警
• 提供歷史數據以供分析

故事到這里似乎可以結束了，可監控真的是這么簡單的么？
當然沒，隨著時代的進步，用戶對服務提出了更為嚴苛的要求，
同時我們也有能力進一步控制平均故障修復時間
（MTBF），
上述描述的做法已經不能滿足我們了。

現在讓我們切換一下視角，從傳統的 OPS 的視角切換到 SRE
（Site Reliability Engineering）的視角。
當我們在關注網站整體的可用性時，我們會發現：
故障警報處理當然很重要，但是我們根本上想減少甚至避免 MTBF。
我們有兩種手段：
一種是去除單點故障，讓問題自然發生，但是不對線上造成影響；
另一種是在問題出現的早期就發現并進行及時修復。
前者是高可用范疇，后者就是我們今天關注的「監控」了。

監控的目的是要將災難消滅在襁褓里；在災難即將出現或者發生問題時，給大家展示直接的原因。

那為了達成這兩個目標，我們需要回到問題的本質，重新思考兩個問題：

1. 監控哪些對象？
2. 如何識別故障？

對象 ????

我們說的監控對象，一般指的都是某個資源，
資源即持有某種其他方需要的某些屬性的載體，包括硬件、軟件。
除了資源這種類型，還有一種常見的監控對象是「體驗」，即終端用戶的訪問感受，
這塊內容我們暫時略去。

讓我們來先看一下常見的資源：

• 硬件
  • 服務器
  • 網絡設備
• 軟件
  • Application
  • Infrastructure

這個分類是粗粒度的描述，為了落地地描述監控對象對象的健康狀況，
我們還要進一步細化。以「服務器」為例，我們可以將其監控的內容細化為以下監控項：

• CPU
• Memory
• Network interface
• Storage devices
• Controllers

如何評估這些監控項的健康狀況？我們使用
SLI（Service Level Indicator）。
比如可用性就是一個最容易理解的 SLI。
這里我將資源歸為兩類，面向用戶提供服務的資源和面向存儲的資源，
以下是針對這兩類資源的常見 SLI：

• User-facing Service
  • Availability
  • Latency
  • Throughput
• Storage System
  • Latency
  • Throughput
  • durability

基于 SLI 建立的數字關鍵指標，稱之為
Service Level Objective。
SLO 往往是一組數字范圍，比如 CPU 負載的 SLO 可以設置為 0.0-6.0（針對 8 核 CPU）。
不同的資源、不同的業務場景，會有不一樣的 SLO 設計。

看到這里，我們已經聊了要監控哪些指標，那么接下來我們聊聊如何用量化的思想，
幫助指標更易于識別、分析和決策。

量化的思想 ??

剛開始擔任線上救火隊成員時候，當有個系統出現問題時候，我經常聽到這樣的描述：
網站掛了、頁面打不開了，CPU 出問題了，內存爆了，線程池炸了等等。
這樣的表述雖然沒錯，但帶來的可用價值太少，信息熵太低。
這樣的說辭多了，就給人產生一種不靠譜，不科學的感覺。

那怎樣才能成為科學的描述？
古希臘哲學家在思考宇宙的時候，提出了一種心智能力，
從而打開了科學的窗子，這就是 Reasonable，中文名叫理智，這成為了自然科學的基石。
使用 Reasonable 探討意味著探討要深入問題的本質，不停留在表象，挖掘出真正有價值的內容。

但是光有 Reasonable 還不夠，B站粉絲建了一個微博，每天會檢查
今天B站炸了嗎，
他只能告訴我們炸沒炸，不能給工程師帶來實際的用處。
在科學的發展歷史上，我們可以發現在亞里士多德的著作里沒有任何數據公式。
他對現象只有描述，只是定性分析，通過描述性狀來闡述定理。
這個定性的研究方式到了伽利略那里才出現了突破。
這里我們可以引入第二個關鍵詞是 Quantifier，量化。
伽利略率先使用定量分析的方法，并將其運用到動力學和天文學，從而開創了近代科學。

如果我們以定量的方式來描述網站掛沒掛，就會變成：網站的響應耗時在 30s，基本無法使用。
描述線程池出問題，就會變成：active 線程數量是 200，已經到達 maxCount 數量，無法進行分配。
你看，通過這樣的描述，我們一下子就能發現問題出在哪里。

USE ??

現在我們已經了解了「監控哪些對象？」，以及嘗試用「量化」這個法寶來「識別故障」。
那有沒有一些最佳實踐幫助大家高效的識別故障呢？這里我推薦 Brend Gregg 大神的 USE 方法。
Brend Gregg 是 Netflix 的首席 SRE，著有 Systems Performance Book，
目前已經出版中文版 性能之巔:洞悉系統、企業與云計算。

USE 分別是三個單詞的首字母縮寫：

• Utilization：使用率，CPU running percent，硬盤的 IO
• Saturation：飽和度，一般偏存儲型資源，內存使用，硬盤使用
• Error：錯誤數

我們可以為每個資源找到各自的 USE 度量指標，具體的 Check List 清單可以參考
USE Method: Rosetta Stone of Performance Checklists。

這里舉個例子，前段時間在設計 MySQL HA 方案時候，同時關注了 MySQL 的監控方案，
那么針對 MySQL，我們要做哪些監控呢？下面是使用 USE 方法設計出來的 SLI：

• Business
  • Questions：語句計總，Throughput
  • Slow_queries：慢查詢計總，Error
  • Com_select：查詢語句計總，Throughput
  • Com_insert：插入語句計總，Throughput
  • Com_update：更新語句計總，Throughput
• Threads & Connections
  • Threads_connected：當前連接數，Utilization
  • Threads_running：當前使用中連接數，Utilization
  • Aborted_connects：嘗試連接失敗數，Error
  • Connection_errors_max_connections：由于連接數超標從而失敗的連接數，Error
• Buffer
  • Innodb_buffer_pool_pages_total：內存使用頁數，Utilization
  • Innodb_buffer_pool_read_requests：讀請求數計總，Utilization

完 ??

如果你對我上面描述的還意猶未盡，建議你可以看 Effective Monitoring and Alerting。
雖然本書沒有中文版，但是關于監控、報警的原理解析很到位，值得一看。
另外還有一本 SRE: Google運維解密，
里面有不少篇幅在講「SLA」，也是和監控、報警息息相關的。

這次講了一些概念性的內容，期望對大家有幫助，下一次我再分享一篇文章，聊聊 Metrics。

原文鏈接: https://blog.alswl.com/2017/06/monitoring-introducing/
歡迎關注我的微信公眾號：窺豹

3a1ff193cee606bd1e2ea554a16353ee