當咱們在聊監控，咱們在聊什麼？

最近在團隊中給你們作了一個分享，泛泛地聊了一些有關「監控」的話題。
其實作分享對分享者的做用每每大於參與者。
這是一次將本身知識的梳理的過程，因而我將此次分享整理成這篇文章。

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。

---

原文連接: blog.alswl.com/2017/06/mon…
歡迎關注個人微信公衆號：窺豹

3a1ff193cee606bd1e2ea554a16353ee