想要4個9？本文告訴你監(jiān)控告警如何做

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

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

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

前言

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

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

問題

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

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

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

監(jiān)控定義

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

• 業(yè)務(wù)邏輯：項目所對應(yīng)的服務(wù)其承擔(dān)的業(yè)務(wù)邏輯，通常需要對其進(jìn)行度量。例如：每秒的下單數(shù)等。

• 應(yīng)用程序：應(yīng)用程序。例如：統(tǒng)一的基礎(chǔ)框架。

• 硬件資源：服務(wù)器資源情況等。例如：Kubernetes 中的 Cadvisor 組件便會提供大量的資源指標(biāo)。

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

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

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

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

因此整體分為上圖四項：

• 預(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ù)真實的度量趨勢來計算既有的告警規(guī)則，發(fā)現(xiàn)已經(jīng)出現(xiàn)故障的問題點(diǎn)。

• 定位故障：故障已經(jīng)出現(xiàn)，需要監(jiān)控系統(tǒng)協(xié)助快速定位問題，也就是根因定位（root cause）。此時是需要協(xié)調(diào)公司內(nèi)生態(tài)圈的多個組件的，例如：鏈路追蹤系統(tǒng)、日志平臺、監(jiān)控系統(tǒng)、治理平臺（限流熔斷等），根據(jù)監(jiān)控系統(tǒng)所告警出來的問題作為起始錨點(diǎn)，對其進(jìn)行有特定方向的分析，再形成 ”線索“ 報告，就可以大力的協(xié)助開發(fā)人員快速的定位問題，發(fā)現(xiàn)故障點(diǎn)。

• 故障恢復(fù)：故障已經(jīng)出現(xiàn)，但自動恢復(fù)了，又或是通過自動化自愈了。這種情況大多出現(xiàn)在告警規(guī)則的閾值配置的不夠妥當(dāng)，又或是第三方依賴恰好恢復(fù)了的場景。

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

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

4 個黃金指標(biāo)

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

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

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

• 延遲：服務(wù)處理某個請求所需要的時間。

• 區(qū)分成功和失敗請求很重要，例如：某個由于數(shù)據(jù)庫連接丟失或者其他后端問題造成的 HTTP 500 錯誤可能延遲很低。因此在計算整體延遲時，如果將 500 回復(fù)的延遲也計算在內(nèi)，可能會產(chǎn)生誤導(dǎo)性的結(jié)果。
• “慢” 錯誤要比 “快” 錯誤更糟糕。

• 流量：使用系統(tǒng)中的某個高層次的指標(biāo)針對系統(tǒng)負(fù)載需求所進(jìn)行的度量。

• 對 Web 服務(wù)器來講，該指標(biāo)通常是每秒 HTTP 請求數(shù)量，同時可能按請求類型分類（靜態(tài)請求與動態(tài)請求）。
• 針對音頻流媒體系統(tǒng)來說，指標(biāo)可能是網(wǎng)絡(luò) I/O 速率，或者并發(fā)會話數(shù)量。
• 針對鍵值對存儲系統(tǒng)來說，指標(biāo)可能是每秒交易數(shù)量，或每秒的讀者操作數(shù)量。

• 錯誤：請求失敗的速率。

• 顯式失敗（例如：HTTP 500）。
• 隱式失?。ɡ纾篐TTP 200 回復(fù)中包含了錯誤內(nèi)容）。
• 策略原因?qū)е碌氖。ɡ纾喝绻蠡貜?fù)在 1s 內(nèi)發(fā)出，任何超過 1s 的請求就都是失敗請求）。

• 飽和度：服務(wù)容量有多 “滿”，通常是系統(tǒng)中目前最為受限的某種資源的某個具體指標(biāo)的度量，例如：在內(nèi)存受限的系統(tǒng)中，即為內(nèi)存；在 I/O 受限的系統(tǒng)中，即為 I/O。

• 很多系統(tǒng)在達(dá)到 100% 利用率之前性能會嚴(yán)重下降，因此可以考慮增加一個利用率目標(biāo)。
• 延遲增加是飽和度的前導(dǎo)現(xiàn)象，99% 的請求延遲（在某一個小的時間范圍內(nèi)，例如一分鐘）可以作為一個飽和度早期預(yù)警的指標(biāo)。
• 飽和度需要進(jìn)行預(yù)測，例如 “看起來數(shù)據(jù)庫會在 4 小時內(nèi)填滿硬盤”。

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

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

實踐案例

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

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

平臺搭建

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

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

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

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

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

• 系統(tǒng)層面：Kubernetes Node、Container 等指標(biāo)，這塊大多 Cadvisor 已采集上報，也可以安裝 kube-state-metrics 加強(qiáng)，這樣子就能夠?qū)?Kubernetes 和應(yīng)用程序的運(yùn)行情況有一個較好的觀察和告警。

• 系統(tǒng)層面：針對全鏈路上的所有基礎(chǔ)組件（例如：MySQL、Redis 等）安裝 exporter，進(jìn)行采集，對相關(guān)基礎(chǔ)組件進(jìn)行監(jiān)控和告警。

• 業(yè)務(wù)服務(wù)：RPC 方法等的 QPS 記錄?？梢员ＷC對業(yè)務(wù)服務(wù)的流量情況把控，且后續(xù)可以做預(yù)測/預(yù)警的一系列動作，面對突發(fā)性流量的自動化擴(kuò)縮容有一定的參考意義。

• 業(yè)務(wù)服務(wù)：RPC 方法等的錯誤情況。能夠發(fā)現(xiàn)應(yīng)用程序、業(yè)務(wù)的常見異常情況，但需要在狀態(tài)/錯誤碼規(guī)劃合理的情況下，能夠起到較大的作用，有一定困難，要在一開始就做對，否則后面很難扭轉(zhuǎn)。

• 應(yīng)用程序：各類遠(yuǎn)程調(diào)用（例如：RPC、SQL、HTTP、Redis）的調(diào)用開銷記錄。最萬金油的度量指標(biāo)之一，能夠在很多方面提供精確的定位和分析，Web 應(yīng)用程序標(biāo)配。常見于使用 P99/95/90。

• 語言級別：內(nèi)部分析記錄，例如：Goroutines 數(shù)量、Panic 情況等，常常能發(fā)現(xiàn)一些意想不到的泄露情況和空指針調(diào)用。沒有這類監(jiān)控的話，很有可能一直都不會被發(fā)現(xiàn)。

指標(biāo)落地

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

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

告警體系

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

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

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

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

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

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

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

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

告警給誰？

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

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

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

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

規(guī)范建立

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

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

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

總結(jié)

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

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

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

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