[[345029]]

本文轉(zhuǎn)載自微信公眾號(hào)「腦子進(jìn)煎魚了」，作者陳煎魚。轉(zhuǎn)載本文請聯(lián)系腦子進(jìn)煎魚了公眾號(hào)。  

“你說說，沒有儀表盤的車，你敢開嗎?”

“沒有儀表盤的車開在路上，你怎么知道現(xiàn)在是什么情況?”

“客戶說你這車又崩了，咋知道什么時(shí)候好的?啥時(shí)候出的問題?”

前言

將思考轉(zhuǎn)換到現(xiàn)實(shí)的軟件系統(tǒng)中，可想而知沒有監(jiān)控系統(tǒng)的情況下，也就是沒有 ”儀表盤“ 的情況下實(shí)在是太可怕了。

你的故障永遠(yuǎn)都是你的客戶告訴你的，而...在什么時(shí)候發(fā)生的，你也無法確定，只能通過客戶的反饋倒推時(shí)間節(jié)點(diǎn)，最后從錯(cuò)誤日志中得到相對(duì)完整的日志信息。

問題

更要命的是你無法掌握主動(dòng)權(quán)，錯(cuò)誤日志有可能會(huì)有人漏記錄，平均修復(fù)時(shí)間(MTTR)更不用想了，需要從 0.1 開始定位，先看 APP 是哪個(gè)模塊報(bào)錯(cuò)，再猜測是哪個(gè)服務(wù)導(dǎo)致，再打開鏈路追蹤系統(tǒng)，或是日志平臺(tái)等。

稍微復(fù)雜些的，排查來來往往基本都是半小時(shí)、一小時(shí)以上，那 4 個(gè) 9 肯定是達(dá)不到的了，以此幾次 P0 幾小時(shí)怕不是業(yè)務(wù)績效也涼涼，因?yàn)楣收闲迯?fù)的速度實(shí)在是太慢了。

那歸根到底，想破局怎么辦，核心第一步就是要把監(jiān)控告警的整個(gè)生態(tài)圈給建設(shè)好。

監(jiān)控定義

常說監(jiān)控監(jiān)控，監(jiān)控的定義就是監(jiān)測和控制，檢測某些事物的變化，以便于進(jìn)行控制。在常見的軟件系統(tǒng)中，大多分為三大觀察類別：

• 業(yè)務(wù)邏輯：項(xiàng)目所對(duì)應(yīng)的服務(wù)其承擔(dān)的業(yè)務(wù)邏輯，通常需要對(duì)其進(jìn)行度量。例如：每秒的下單數(shù)等。
• 應(yīng)用程序：應(yīng)用程序。例如：統(tǒng)一的基礎(chǔ)框架。
• 硬件資源：服務(wù)器資源情況等。例如：Kubernetes 中的 Cadvisor 組件便會(huì)提供大量的資源指標(biāo)。

從軟件系統(tǒng)來講，監(jiān)控的定義就是收集、處理、匯總，顯示關(guān)于某個(gè)系統(tǒng)的實(shí)時(shí)量化數(shù)據(jù)，例如：請求的數(shù)量和類型，錯(cuò)誤的數(shù)量和類型，以及各類調(diào)用/處理的耗時(shí)，應(yīng)用服務(wù)的存活時(shí)間等。

監(jiān)控目標(biāo)

知道了監(jiān)控的定義，了解了監(jiān)控的作用和具體的實(shí)施指標(biāo)后。我們需要明確的知道，做監(jiān)控的目標(biāo)是什么：

從現(xiàn)實(shí)層面出發(fā)，做監(jiān)控的初衷，就是希望能夠及時(shí)的發(fā)現(xiàn)線上環(huán)境的各種各樣奇奇怪怪的問題，為業(yè)務(wù)的正常運(yùn)轉(zhuǎn)保駕護(hù)航。

因此整體分為上圖四項(xiàng)：

• 預(yù)測故障：故障還沒出現(xiàn)，但存在異常。監(jiān)控系統(tǒng)根據(jù)流量模型、數(shù)據(jù)分析、度量趨勢來推算應(yīng)用程序的異常趨勢，推算可能出現(xiàn)故障的問題點(diǎn)。
• 發(fā)現(xiàn)故障：故障已經(jīng)出現(xiàn)，客戶還沒反饋到一線人員。監(jiān)控系統(tǒng)根據(jù)真實(shí)的度量趨勢來計(jì)算既有的告警規(guī)則，發(fā)現(xiàn)已經(jīng)出現(xiàn)故障的問題點(diǎn)。
• 定位故障：故障已經(jīng)出現(xiàn)，需要監(jiān)控系統(tǒng)協(xié)助快速定位問題，也就是根因定位(root cause)。此時(shí)是需要協(xié)調(diào)公司內(nèi)生態(tài)圈的多個(gè)組件的，例如：鏈路追蹤系統(tǒng)、日志平臺(tái)、監(jiān)控系統(tǒng)、治理平臺(tái)(限流熔斷等)，根據(jù)監(jiān)控系統(tǒng)所告警出來的問題作為起始錨點(diǎn)，對(duì)其進(jìn)行有特定方向的分析，再形成 ”線索“ 報(bào)告，就可以大力的協(xié)助開發(fā)人員快速的定位問題，發(fā)現(xiàn)故障點(diǎn)。
• 故障恢復(fù)：故障已經(jīng)出現(xiàn)，但自動(dòng)恢復(fù)了，又或是通過自動(dòng)化自愈了。這種情況大多出現(xiàn)在告警規(guī)則的閾值配置的不夠妥當(dāng)，又或是第三方依賴恰好恢復(fù)了的場景。

而更值得探討的的是監(jiān)控告警的后半段閉環(huán)，故障自愈，通過上述三點(diǎn) “預(yù)測故障、發(fā)現(xiàn)故障、定位故障”，已經(jīng)定位到故障了，就可以配合內(nèi)部組件，實(shí)現(xiàn)自動(dòng)化的 ”自愈“，減少人工介入，提高 MTTR。

因此做監(jiān)控系統(tǒng)的目標(biāo)很明確，就是發(fā)現(xiàn)問題，解決問題，最好自愈，達(dá)到愉快休假，業(yè)務(wù)安心的目的。

4 個(gè)黃金指標(biāo)

有定義，有目標(biāo)，那指導(dǎo)呢?

實(shí)際上 “業(yè)務(wù)邏輯、應(yīng)用程序、硬件資源” 已經(jīng)成為了一個(gè)監(jiān)控系統(tǒng)所要監(jiān)控構(gòu)建的首要目標(biāo)，絕大部分的監(jiān)控場景都可以歸類進(jìn)來。

針對(duì)這三大項(xiàng)，《Google SRE 運(yùn)維解密》 也總結(jié)出了 4 個(gè)黃金指標(biāo)，在業(yè)界廣為流傳和借鑒：

• 延遲：服務(wù)處理某個(gè)請求所需要的時(shí)間。
  • 區(qū)分成功和失敗請求很重要，例如：某個(gè)由于數(shù)據(jù)庫連接丟失或者其他后端問題造成的 HTTP 500 錯(cuò)誤可能延遲很低。因此在計(jì)算整體延遲時(shí)，如果將 500 回復(fù)的延遲也計(jì)算在內(nèi)，可能會(huì)產(chǎn)生誤導(dǎo)性的結(jié)果。
  • “慢” 錯(cuò)誤要比 “快” 錯(cuò)誤更糟糕。
• 流量：使用系統(tǒng)中的某個(gè)高層次的指標(biāo)針對(duì)系統(tǒng)負(fù)載需求所進(jìn)行的度量。
  • 對(duì) Web 服務(wù)器來講，該指標(biāo)通常是每秒 HTTP 請求數(shù)量，同時(shí)可能按請求類型分類(靜態(tài)請求與動(dòng)態(tài)請求)。
  • 針對(duì)音頻流媒體系統(tǒng)來說，指標(biāo)可能是網(wǎng)絡(luò) I/O 速率，或者并發(fā)會(huì)話數(shù)量。
  • 針對(duì)鍵值對(duì)存儲(chǔ)系統(tǒng)來說，指標(biāo)可能是每秒交易數(shù)量，或每秒的讀者操作數(shù)量。
• 錯(cuò)誤：請求失敗的速率。
  • 顯式失敗(例如：HTTP 500)。
  • 隱式失敗(例如：HTTP 200 回復(fù)中包含了錯(cuò)誤內(nèi)容)。
  • 策略原因?qū)е碌氖?例如：如果要求回復(fù)在 1s 內(nèi)發(fā)出，任何超過 1s 的請求就都是失敗請求)。
• 飽和度：服務(wù)容量有多 “滿”，通常是系統(tǒng)中目前最為受限的某種資源的某個(gè)具體指標(biāo)的度量，例如：在內(nèi)存受限的系統(tǒng)中，即為內(nèi)存;在 I/O 受限的系統(tǒng)中，即為 I/O。
  • 很多系統(tǒng)在達(dá)到 100% 利用率之前性能會(huì)嚴(yán)重下降，因此可以考慮增加一個(gè)利用率目標(biāo)。
  • 延遲增加是飽和度的前導(dǎo)現(xiàn)象，99% 的請求延遲(在某一個(gè)小的時(shí)間范圍內(nèi)，例如一分鐘)可以作為一個(gè)飽和度早期預(yù)警的指標(biāo)。
  • 飽和度需要進(jìn)行預(yù)測，例如 “看起來數(shù)據(jù)庫會(huì)在 4 小時(shí)內(nèi)填滿硬盤”。

如果已經(jīng)成功度量了這四個(gè)黃金指標(biāo)，且在某個(gè)指標(biāo)出現(xiàn)故障時(shí)能夠發(fā)出告警(或者快要發(fā)生故障)，那么在服務(wù)的監(jiān)控層面來講，基本也就滿足了初步的監(jiān)控訴求。

也就是可以做到知道了是什么出問題，問題出在哪里，單這一步就已經(jīng)提高了不少定位問題的時(shí)間效率，是一個(gè)從 0 到 1 的起步階段。

實(shí)踐案例

知道是什么(定義)，為什么要做(目標(biāo))，做的時(shí)候需要什么(4 個(gè)黃金指標(biāo))后，還缺乏的是一個(gè)承載這些基礎(chǔ)應(yīng)用、業(yè)務(wù)思考的平臺(tái)，讓架構(gòu)+運(yùn)維+業(yè)務(wù)共同在上面施展拳腳。

公司內(nèi)部至少需要有一個(gè)監(jiān)控告警管理平臺(tái)。

平臺(tái)搭建

在目前云原生火熱的情況下，Kubernetes 生態(tài)中大多慣用 Prometheus，因此 Prometheus+Grafana+AlertManger 成為了一大首選，業(yè)內(nèi)占比也越來越高，其基本架構(gòu)如下：

• Prometheus Server：用于收集指標(biāo)和存儲(chǔ)時(shí)間序列數(shù)據(jù)，并提供一系列的查詢和設(shè)置接口。
• Grafana：用于展示各類趨勢圖，通過 PromQL 從 Prometheus 服務(wù)端查詢并構(gòu)建圖表。
• Alertmanager：用于處理告警事件，從 Prometheus 服務(wù)端接收到 alerts 后，會(huì)進(jìn)行去重，分組，然后路由到對(duì)應(yīng)的Receiver，發(fā)出報(bào)警。

這塊具體的基本知識(shí)學(xué)習(xí)和搭建可詳見我寫的 Prometheus 系列，本文不再贅述。

監(jiān)控指標(biāo)

在平臺(tái)搭建完畢后，常要做的第一步，那就是規(guī)劃你整個(gè)系統(tǒng)的度量指標(biāo)，結(jié)合 Google SRE 的 4 個(gè)黃金指標(biāo)，可以初步劃分出如下幾種常用類型：

• 系統(tǒng)層面：Kubernetes Node、Container 等指標(biāo)，這塊大多 Cadvisor 已采集上報(bào)，也可以安裝 kube-state-metrics 加強(qiáng)，這樣子就能夠?qū)?Kubernetes 和應(yīng)用程序的運(yùn)行情況有一個(gè)較好的觀察和告警。
• 系統(tǒng)層面：針對(duì)全鏈路上的所有基礎(chǔ)組件(例如：MySQL、Redis 等)安裝 exporter，進(jìn)行采集，對(duì)相關(guān)基礎(chǔ)組件進(jìn)行監(jiān)控和告警。
• 業(yè)務(wù)服務(wù)：RPC 方法等的 QPS 記錄。可以保證對(duì)業(yè)務(wù)服務(wù)的流量情況把控，且后續(xù)可以做預(yù)測/預(yù)警的一系列動(dòng)作，面對(duì)突發(fā)性流量的自動(dòng)化擴(kuò)縮容有一定的參考意義。
• 業(yè)務(wù)服務(wù)：RPC 方法等的錯(cuò)誤情況。能夠發(fā)現(xiàn)應(yīng)用程序、業(yè)務(wù)的常見異常情況，但需要在狀態(tài)/錯(cuò)誤碼規(guī)劃合理的情況下，能夠起到較大的作用，有一定困難，要在一開始就做對(duì)，否則后面很難扭轉(zhuǎn)。
• 應(yīng)用程序：各類遠(yuǎn)程調(diào)用(例如：RPC、SQL、HTTP、Redis)的調(diào)用開銷記錄。最萬金油的度量指標(biāo)之一，能夠在很多方面提供精確的定位和分析，Web 應(yīng)用程序標(biāo)配。常見于使用 P99/95/90。
• 語言級(jí)別：內(nèi)部分析記錄，例如：Goroutines 數(shù)量、Panic 情況等，常常能發(fā)現(xiàn)一些意想不到的泄露情況和空指針調(diào)用。沒有這類監(jiān)控的話，很有可能一直都不會(huì)被發(fā)現(xiàn)。

指標(biāo)落地

第一步完成了整個(gè)系統(tǒng)的度量指標(biāo)規(guī)劃后，第二步就是需要確確實(shí)實(shí)的把指標(biāo)落地了。

無論是統(tǒng)一基礎(chǔ)框架的打點(diǎn)，系統(tǒng)組件的 exporter，大多涉及了公司級(jí)的跨多部門協(xié)作，這時(shí)候需要更多的耐心和長期主義和不斷地對(duì)方向糾錯(cuò)，才能嘗到體系建設(shè)后的果實(shí)。

告警體系

在完成監(jiān)控指標(biāo)和體系的建設(shè)后，告警如何做，成為了一大難題，再好的監(jiān)控體系，閉環(huán)做不好，就無法發(fā)揮出很大的作用。因此我們給告警定義一些準(zhǔn)則：

告警不要太多，否則會(huì)導(dǎo)致“狼來了”。

告警出現(xiàn)時(shí)，應(yīng)當(dāng)要具體操作某些事情，是亟待解決的。

告警出現(xiàn)時(shí)，應(yīng)當(dāng)要進(jìn)行某些智力分析，不應(yīng)該是機(jī)械行為。

不需要人工響應(yīng)/處理的告警規(guī)則，應(yīng)當(dāng)直接刪除。

告警出現(xiàn)時(shí)，你下意識(shí)要再觀察觀察的告警，要直接進(jìn)行調(diào)整。

告警應(yīng)當(dāng)足夠的簡單，直觀，不需要猜。

簡單來講就是告警要少，事件需要解決，處理要人工介入。否則右拐自動(dòng)化自愈恢復(fù)可能更香。

告警給誰?

另外一個(gè)難題就是：誰誘發(fā)處理的告警，要通知給誰?

這是一個(gè)很需要斟酌的問題，在告警的規(guī)范上，盡可能遵循最小原則，再逐級(jí)上報(bào)。也就是先告警給 on-call 人，若超出 X 分鐘，再逐級(jí)上報(bào)到全業(yè)務(wù)組，再及其負(fù)責(zé)人，一級(jí)級(jí)跟蹤，實(shí)現(xiàn)漸進(jìn)式告警。

逐級(jí)上報(bào)，響應(yīng)即跟蹤，明確問題點(diǎn)的責(zé)任人。而逐級(jí)上報(bào)的數(shù)據(jù)來源，可通過員工管理系統(tǒng)來獲取，在員工管理系統(tǒng)中有完整的上下級(jí)關(guān)系(類似 OA 審批上看到的流程節(jié)點(diǎn))，但如果該系統(tǒng)沒有開放 API 之類的，那可能你只能通過其他方式來獲取了。

例如像是通過企業(yè)微信獲取部門關(guān)系和人員列表，再手動(dòng)設(shè)置上下級(jí)關(guān)聯(lián)關(guān)系，也可以達(dá)到目的，且在現(xiàn)實(shí)世界中，有可能存在定制化的訴求。

規(guī)范建立

即使所以監(jiān)控體系、指標(biāo)落地、告警體系都建立起來了，也不能掉以輕心。實(shí)際上在成為事實(shí)標(biāo)準(zhǔn)后，你仍然需要盡快為告警后奔跑，將整個(gè)閉環(huán)搭建起來，也就是故障管理。

與公司內(nèi)部的流程管理的同學(xué)或 QA，一起設(shè)立研發(fā)底線的規(guī)范，進(jìn)行細(xì)致的告警分級(jí)識(shí)別，告警后的匯總運(yùn)營分析，形成一個(gè)真正意義上的故障管理規(guī)范。

否則最后可能會(huì)疲于奔命，人的時(shí)間精力總是有限的，而面對(duì)整個(gè)公司的監(jiān)控告警的搭建，體系上與業(yè)務(wù)組的共建，督促告警響應(yīng)，極有可能最后會(huì)疲于奔命，即使真的有一定用處，在雜亂無人收斂的告警中最后流于形式。

總結(jié)

監(jiān)控告警的體系生態(tài)做來有意義嗎?

這是必然的，成熟且規(guī)范的監(jiān)控告警的體系生態(tài)是具有極大意義，可以提前發(fā)現(xiàn)問題，定位問題，解決問題。甚至這個(gè)問題的說不定還不需要你自己處理，做多組件的閉環(huán)后，直接實(shí)施自動(dòng)化的服務(wù)自愈就可以了，安心又快快樂樂的過國慶節(jié)，是很香的。

而故障管理的閉環(huán)實(shí)施后，就可以分析業(yè)務(wù)服務(wù)的告警情況，結(jié)合 CI/CD 系統(tǒng)等基礎(chǔ)平臺(tái)，每季度自動(dòng)化分析實(shí)施運(yùn)營報(bào)表，幫助業(yè)務(wù)發(fā)現(xiàn)更多的問題，提供其特有的價(jià)值。

但，想真正做到上述所說的成熟且規(guī)范，業(yè)務(wù)共建，有難度，需要多方面認(rèn)同和公司規(guī)范支撐才能最佳實(shí)現(xiàn)。因此共同認(rèn)可，求同存異，多做用戶反饋分析也非常重要。

原文鏈接：https://mp.weixin.qq.com/s/qaNWBlDGgE2hNnu6SV4EBg