最近在團(tuán)隊(duì)中給大家做了一個(gè)分享，泛泛地聊了一些有關(guān)「監(jiān)控」的話題。
其實(shí)做分享對(duì)分享者的作用往往大于參與者。
這是一次將自己知識(shí)的梳理的過程，于是我將這次分享整理成這篇文章。
目的 ??
我們先來聊聊，什么是「監(jiān)控」，以及我們期望通過「監(jiān)控」完成哪些目的？
傳統(tǒng)意義上的監(jiān)控，是指：
通過一些手段和工具，關(guān)注運(yùn)行中的硬件、軟件、用戶體驗(yàn)的關(guān)鍵數(shù)據(jù)，將其暴露出來。
當(dāng)關(guān)鍵數(shù)據(jù)出現(xiàn)異常時(shí)候發(fā)出警告，進(jìn)行人工或者自動(dòng)的響應(yīng)。
我們平時(shí)看到的最常見的監(jiān)控系統(tǒng)，比如 Zabbix，提供了豐富的模板，
可以監(jiān)控服務(wù)器的 Load / CPU Usage / Alive 這些常規(guī)指標(biāo)。
并在出現(xiàn)問題時(shí)候，對(duì)其進(jìn)行報(bào)警通知。
隨后運(yùn)維工程師們會(huì)上線進(jìn)行應(yīng)急操作，case by case 的處理故障。
我將上面的使用目的歸納為：
- 故障發(fā)生時(shí)提供數(shù)據(jù)報(bào)警
- 提供歷史數(shù)據(jù)以供分析
故事到這里似乎可以結(jié)束了，可監(jiān)控真的是這么簡單的么？
當(dāng)然沒，隨著時(shí)代的進(jìn)步，用戶對(duì)服務(wù)提出了更為嚴(yán)苛的要求，
同時(shí)我們也有能力進(jìn)一步控制平均故障修復(fù)時(shí)間
（MTBF），
上述描述的做法已經(jīng)不能滿足我們了。
現(xiàn)在讓我們切換一下視角，從傳統(tǒng)的 OPS 的視角切換到 SRE
（Site Reliability Engineering）的視角。
當(dāng)我們?cè)陉P(guān)注網(wǎng)站整體的可用性時(shí)，我們會(huì)發(fā)現(xiàn)：
故障警報(bào)處理當(dāng)然很重要，但是我們根本上想減少甚至避免 MTBF。
我們有兩種手段：
一種是去除單點(diǎn)故障，讓問題自然發(fā)生，但是不對(duì)線上造成影響；
另一種是在問題出現(xiàn)的早期就發(fā)現(xiàn)并進(jìn)行及時(shí)修復(fù)。
前者是高可用范疇，后者就是我們今天關(guān)注的「監(jiān)控」了。
監(jiān)控的目的是要將災(zāi)難消滅在襁褓里；在災(zāi)難即將出現(xiàn)或者發(fā)生問題時(shí)，給大家展示直接的原因。
那為了達(dá)成這兩個(gè)目標(biāo)，我們需要回到問題的本質(zhì)，重新思考兩個(gè)問題：
- 監(jiān)控哪些對(duì)象？
- 如何識(shí)別故障？
對(duì)象 ????
我們說的監(jiān)控對(duì)象，一般指的都是某個(gè)資源，
資源即持有某種其他方需要的某些屬性的載體，包括硬件、軟件。
除了資源這種類型，還有一種常見的監(jiān)控對(duì)象是「體驗(yàn)」，即終端用戶的訪問感受，
這塊內(nèi)容我們暫時(shí)略去。
讓我們來先看一下常見的資源：
- 硬件
- 服務(wù)器
- 網(wǎng)絡(luò)設(shè)備
- 軟件
- Application
- Infrastructure
這個(gè)分類是粗粒度的描述，為了落地地描述監(jiān)控對(duì)象對(duì)象的健康狀況，
我們還要進(jìn)一步細(xì)化。以「服務(wù)器」為例，我們可以將其監(jiān)控的內(nèi)容細(xì)化為以下監(jiān)控項(xiàng)：
- CPU
- Memory
- Network interface
- Storage devices
- Controllers
如何評(píng)估這些監(jiān)控項(xiàng)的健康狀況？我們使用
SLI（Service Level Indicator）。
比如可用性就是一個(gè)最容易理解的 SLI。
這里我將資源歸為兩類，面向用戶提供服務(wù)的資源和面向存儲(chǔ)的資源，
以下是針對(duì)這兩類資源的常見 SLI：
- User-facing Service
- Availability
- Latency
- Throughput
- Storage System
- Latency
- Throughput
- durability
基于 SLI 建立的數(shù)字關(guān)鍵指標(biāo)，稱之為
Service Level Objective。
SLO 往往是一組數(shù)字范圍，比如 CPU 負(fù)載的 SLO 可以設(shè)置為 0.0-6.0（針對(duì) 8 核 CPU）。
不同的資源、不同的業(yè)務(wù)場(chǎng)景，會(huì)有不一樣的 SLO 設(shè)計(jì)。
看到這里，我們已經(jīng)聊了要監(jiān)控哪些指標(biāo)，那么接下來我們聊聊如何用量化的思想，
幫助指標(biāo)更易于識(shí)別、分析和決策。
量化的思想 ??
剛開始擔(dān)任線上救火隊(duì)成員時(shí)候，當(dāng)有個(gè)系統(tǒng)出現(xiàn)問題時(shí)候，我經(jīng)常聽到這樣的描述：
網(wǎng)站掛了、頁面打不開了，CPU 出問題了，內(nèi)存爆了，線程池炸了等等。
這樣的表述雖然沒錯(cuò)，但帶來的可用價(jià)值太少，信息熵太低。
這樣的說辭多了，就給人產(chǎn)生一種不靠譜，不科學(xué)的感覺。
那怎樣才能成為科學(xué)的描述？
古希臘哲學(xué)家在思考宇宙的時(shí)候，提出了一種心智能力，
從而打開了科學(xué)的窗子，這就是 Reasonable，中文名叫理智，這成為了自然科學(xué)的基石。
使用 Reasonable 探討意味著探討要深入問題的本質(zhì)，不停留在表象，挖掘出真正有價(jià)值的內(nèi)容。
但是光有 Reasonable 還不夠，B站粉絲建了一個(gè)微博，每天會(huì)檢查
今天B站炸了嗎，
他只能告訴我們炸沒炸，不能給工程師帶來實(shí)際的用處。
在科學(xué)的發(fā)展歷史上，我們可以發(fā)現(xiàn)在亞里士多德的著作里沒有任何數(shù)據(jù)公式。
他對(duì)現(xiàn)象只有描述，只是定性分析，通過描述性狀來闡述定理。
這個(gè)定性的研究方式到了伽利略那里才出現(xiàn)了突破。
這里我們可以引入第二個(gè)關(guān)鍵詞是 Quantifier，量化。
伽利略率先使用定量分析的方法，并將其運(yùn)用到動(dòng)力學(xué)和天文學(xué)，從而開創(chuàng)了近代科學(xué)。
如果我們以定量的方式來描述網(wǎng)站掛沒掛，就會(huì)變成：網(wǎng)站的響應(yīng)耗時(shí)在 30s，基本無法使用。
描述線程池出問題，就會(huì)變成：active 線程數(shù)量是 200，已經(jīng)到達(dá) maxCount 數(shù)量，無法進(jìn)行分配。
你看，通過這樣的描述，我們一下子就能發(fā)現(xiàn)問題出在哪里。
USE ??
現(xiàn)在我們已經(jīng)了解了「監(jiān)控哪些對(duì)象？」，以及嘗試用「量化」這個(gè)法寶來「識(shí)別故障」。
那有沒有一些最佳實(shí)踐幫助大家高效的識(shí)別故障呢？這里我推薦 Brend Gregg 大神的 USE 方法。
Brend Gregg 是 Netflix 的首席 SRE，著有 Systems Performance Book，
目前已經(jīng)出版中文版 性能之巔:洞悉系統(tǒng)、企業(yè)與云計(jì)算。
USE 分別是三個(gè)單詞的首字母縮寫：
- Utilization：使用率，CPU running percent，硬盤的 IO
- Saturation：飽和度，一般偏存儲(chǔ)型資源，內(nèi)存使用，硬盤使用
- Error：錯(cuò)誤數(shù)
我們可以為每個(gè)資源找到各自的 USE 度量指標(biāo)，具體的 Check List 清單可以參考
USE Method: Rosetta Stone of Performance Checklists。
這里舉個(gè)例子，前段時(shí)間在設(shè)計(jì) MySQL HA 方案時(shí)候，同時(shí)關(guān)注了 MySQL 的監(jiān)控方案，
那么針對(duì) MySQL，我們要做哪些監(jiān)控呢？下面是使用 USE 方法設(shè)計(jì)出來的 SLI：
- Business
- Questions：語句計(jì)總，Throughput
- Slow_queries：慢查詢計(jì)總，Error
- Com_select：查詢語句計(jì)總，Throughput
- Com_insert：插入語句計(jì)總，Throughput
- Com_update：更新語句計(jì)總，Throughput
- Threads & Connections
- Threads_connected：當(dāng)前連接數(shù)，Utilization
- Threads_running：當(dāng)前使用中連接數(shù)，Utilization
- Aborted_connects：嘗試連接失敗數(shù)，Error
- Connection_errors_max_connections：由于連接數(shù)超標(biāo)從而失敗的連接數(shù)，Error
- Buffer
- Innodb_buffer_pool_pages_total：內(nèi)存使用頁數(shù)，Utilization
- Innodb_buffer_pool_read_requests：讀請(qǐng)求數(shù)計(jì)總，Utilization
完 ??
如果你對(duì)我上面描述的還意猶未盡，建議你可以看 Effective Monitoring and Alerting。
雖然本書沒有中文版，但是關(guān)于監(jiān)控、報(bào)警的原理解析很到位，值得一看。
另外還有一本 SRE: Google運(yùn)維解密，
里面有不少篇幅在講「SLA」，也是和監(jiān)控、報(bào)警息息相關(guān)的。
這次講了一些概念性的內(nèi)容，期望對(duì)大家有幫助，下一次我再分享一篇文章，聊聊 Metrics。
原文鏈接: https://blog.alswl.com/2017/06/monitoring-introducing/
歡迎關(guān)注我的微信公眾號(hào)：窺豹
3a1ff193cee606bd1e2ea554a16353ee
