想要4個9？本文告訴你監控告警如何作

「你說說，沒有儀表盤的車，你敢開嗎？」web

「沒有儀表盤的車開在路上，你怎麼知道如今是什麼狀況？」數據庫

「客戶說你這車又崩了，咋知道何時好的？啥時候出的問題？」後端

前言

將思考轉換到現實的軟件系統中，可想而知沒有監控系統的狀況下，也就是沒有」儀表盤「的狀況下實在是太可怕了。服務器

你的故障永遠都是你的客戶告訴你的，而...在何時發生的，你也沒法肯定，只能經過客戶的反饋倒推時間節點，最後從錯誤日誌中獲得相對完整的日誌信息。微信

問題

更要命的是你沒法掌握主動權，錯誤日誌有可能會有人漏記錄，平均修復時間（MTTR）更不用想了，須要從 0.1 開始定位，先看 APP 是哪一個模塊報錯，再猜想是哪一個服務致使，再打開鏈路追蹤系統，或是日誌平臺等。網絡

稍微複雜些的，排查來來每每基本都是半小時、一小時以上，那 4 個 9 確定是達不到的了，以此幾回 P0 幾小時怕不是業務績效也涼涼，由於故障修復的速度實在是太慢了。架構

那歸根到底，想破局怎麼辦，核心第一步就是要把監控告警的整個生態圈給建設好。併發

監控定義

常說監控監控，監控的定義就是監測和控制，檢測某些事物的變化，以便於進行控制。在常見的軟件系統中，大多分爲三大觀察類別：框架

業務邏輯：項目所對應的服務其承擔的業務邏輯，一般須要對其進行度量。例如：每秒的下單數等。運維
應用程序：應用程序。例如：統一的基礎框架。
硬件資源：服務器資源狀況等。例如：Kubernetes 中的 Cadvisor 組件便會提供大量的資源指標。

從軟件系統來說，監控的定義就是收集、處理、彙總，顯示關於某個系統的實時量化數據，例如：請求的數量和類型，錯誤的數量和類型，以及各種調用/處理的耗時，應用服務的存活時間等。

監控目標

知道了監控的定義，瞭解了監控的做用和具體的實施指標後。咱們須要明確的知道，作監控的目標是什麼：

從現實層面出發，作監控的初衷，就是但願可以及時的發現線上環境的各類各樣奇奇怪怪的問題，爲業務的正常運轉保駕護航。

所以總體分爲上圖四項：

預測故障：故障還沒出現，但存在異常。監控系統根據流量模型、數據分析、度量趨勢來推算應用程序的異常趨勢，推算可能出現故障的問題點。
發現故障：故障已經出現，客戶還沒反饋到一線人員。監控系統根據真實的度量趨勢來計算既有的告警規則，發現已經出現故障的問題點。
定位故障：故障已經出現，須要監控系統協助快速定位問題，也就是根因定位（root cause）。此時是須要協調公司內生態圈的多個組件的，例如：鏈路追蹤系統、日誌平臺、監控系統、治理平臺（限流熔斷等），根據監控系統所告警出來的問題做爲起始錨點，對其進行有特定方向的分析，再造成」線索「報告，就能夠大力的協助開發人員快速的定位問題，發現故障點。
故障恢復：故障已經出現，但自動恢復了，又或是經過自動化自愈了。這種狀況大多出如今告警規則的閾值配置的不夠穩當，又或是第三方依賴剛好恢復了的場景。

而更值得探討的的是監控告警的後半段閉環，故障自愈，經過上述三點「預測故障、發現故障、定位故障」，已經定位到故障了，就能夠配合內部組件，實現自動化的」自愈「，減小人工介入，提升 MTTR。

所以作監控系統的目標很明確，就是發現問題，解決問題，最好自愈，達到愉快休假，業務安心的目的。

4 個黃金指標

有定義，有目標，那指導呢？

實際上「業務邏輯、應用程序、硬件資源」已經成爲了一個監控系統所要監控構建的首要目標，絕大部分的監控場景均可以歸類進來。

針對這三大項，《Google SRE 運維解密》也總結出了 4 個黃金指標，在業界廣爲流傳和借鑑：

延遲：服務處理某個請求所須要的時間。

區分紅功和失敗請求很重要，例如：某個因爲數據庫鏈接丟失或者其餘後端問題形成的 HTTP 500 錯誤可能延遲很低。所以在計算總體延遲時，若是將 500 回覆的延遲也計算在內，可能會產生誤導性的結果。
「慢」錯誤要比「快」錯誤更糟糕。

流量：使用系統中的某個高層次的指標針對系統負載需求所進行的度量。

對 Web 服務器來說，該指標一般是每秒 HTTP 請求數量，同時可能按請求類型分類（靜態請求與動態請求）。
針對音頻流媒體系統來講，指標多是網絡 I/O 速率，或者併發會話數量。
針對鍵值對存儲系統來講，指標多是每秒交易數量，或每秒的讀者操做數量。

錯誤：請求失敗的速率。

顯式失敗（例如：HTTP 500）。
隱式失敗（例如：HTTP 200 回覆中包含了錯誤內容）。
策略緣由致使的失敗（例如：若是要求回覆在 1s 內發出，任何超過 1s 的請求就都是失敗請求）。

飽和度：服務容量有多「滿」，一般是系統中目前最爲受限的某種資源的某個具體指標的度量，例如：在內存受限的系統中，即爲內存；在 I/O 受限的系統中，即爲 I/O。

不少系統在達到 100% 利用率以前性能會嚴重降低，所以能夠考慮增長一個利用率目標。
延遲增長是飽和度的前導現象，99% 的請求延遲（在某一個小的時間範圍內，例如一分鐘）能夠做爲一個飽和度早期預警的指標。
飽和度須要進行預測，例如「看起來數據庫會在 4 小時內填滿硬盤」。

若是已經成功度量了這四個黃金指標，且在某個指標出現故障時可以發出告警（或者快要發生故障），那麼在服務的監控層面來說，基本也就知足了初步的監控訴求。

也就是能夠作到知道了是什麼出問題，問題出在哪裏，單這一步就已經提升了很多定位問題的時間效率，是一個從 0 到 1 的起步階段。

實踐案例

知道是什麼（定義），爲何要作（目標），作的時候須要什麼（4 個黃金指標）後，還缺少的是一個承載這些基礎應用、業務思考的平臺，讓架構+運維+業務共同在上面施展拳腳。

公司內部至少須要有一個監控告警管理平臺。

平臺搭建

在目前雲原生火熱的狀況下，Kubernetes 生態中大多慣用 Prometheus，所以 Prometheus+Grafana+AlertManger 成爲了一大首選，業內佔比也愈來愈高，其基本架構以下：

Prometheus Server：用於收集指標和存儲時間序列數據，並提供一系列的查詢和設置接口。
Grafana：用於展現各種趨勢圖，經過 PromQL 從 Prometheus 服務端查詢並構建圖表。
Alertmanager：用於處理告警事件，從 Prometheus 服務端接收到 alerts 後，會進行去重，分組，而後路由到對應的Receiver，發出報警。

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

監控指標

在平臺搭建完畢後，常要作的第一步，那就是規劃你整個系統的度量指標，結合 Google SRE 的 4 個黃金指標，能夠初步劃分出以下幾種經常使用類型：

系統層面：Kubernetes Node、Container 等指標，這塊大多 Cadvisor 已採集上報，也能夠安裝 kube-state-metrics 增強，這樣子就可以對 Kubernetes 和應用程序的運行狀況有一個較好的觀察和告警。
系統層面：針對全鏈路上的全部基礎組件（例如：MySQL、Redis 等）安裝 exporter，進行採集，對相關基礎組件進行監控和告警。
業務服務：RPC 方法等的 QPS 記錄。能夠保證對業務服務的流量狀況把控，且後續能夠作預測/預警的一系列動做，面對突發性流量的自動化擴縮容有必定的參考意義。
業務服務：RPC 方法等的錯誤狀況。可以發現應用程序、業務的常見異常狀況，但須要在狀態/錯誤碼規劃合理的狀況下，可以起到較大的做用，有必定困難，要在一開始就作對，不然後面很難扭轉。
應用程序：各種遠程調用（例如：RPC、SQL、HTTP、Redis）的調用開銷記錄。最萬金油的度量指標之一，可以在不少方面提供精確的定位和分析，Web 應用程序標配。常見於使用 P99/95/90。
語言級別：內部分析記錄，例如：Goroutines 數量、Panic 狀況等，經常能發現一些意想不到的泄露狀況和空指針調用。沒有這類監控的話，頗有可能一直都不會被發現。

指標落地

第一步完成了整個系統的度量指標規劃後，第二步就是須要確確實實的把指標落地了。

不管是統一基礎框架的打點，系統組件的 exporter，大多涉及了公司級的跨多部門協做，這時候須要更多的耐心和長期主義和不斷地對方向糾錯，才能嚐到體系建設後的果實。

告警體系

在完成監控指標和體系的建設後，告警如何作，成爲了一大難題，再好的監控體系，閉環作很差，就沒法發揮出很大的做用。所以咱們給告警定義一些準則：

告警不要太多，不然會致使「狼來了」。
告警出現時，應當要具體操做某些事情，是亟待解決的。
告警出現時，應當要進行某些智力分析，不該該是機械行爲。
不須要人工響應/處理的告警規則，應當直接刪除。
告警出現時，你下意識要再觀察觀察的告警，要直接進行調整。
告警應當足夠的簡單，直觀，不須要猜。

簡單來說就是告警要少，事件須要解決，處理要人工介入。不然右拐自動化自愈恢復可能更香。

告警給誰？

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

這是一個很須要斟酌的問題，在告警的規範上，儘量遵循最小原則，再逐級上報。也就是先告警給 on-call 人，若超出 X 分鐘，再逐級上報到全業務組，再及其負責人，一級級跟蹤，實現漸進式告警。

逐級上報，響應即跟蹤，明確問題點的責任人。而逐級上報的數據來源，可經過員工管理系統來獲取，在員工管理系統中有完整的上下級關係（相似 OA 審批上看到的流程節點），但若是該系統沒有開放 API 之類的，那可能你只能經過其餘方式來獲取了。

例如像是經過企業微信獲取部門關係和人員列表，再手動設置上下級關聯關係，也能夠達到目的，且在現實世界中，有可能存在定製化的訴求。

規範創建

即便因此監控體系、指標落地、告警體系都創建起來了，也不能掉以輕心。實際上在成爲事實標準後，你仍然須要儘快爲告警後奔跑，將整個閉環搭建起來，也就是故障管理。

與公司內部的流程管理的同窗或 QA，一塊兒設立研發底線的規範，進行細緻的告警分級識別，告警後的彙總運營分析，造成一個真正意義上的故障管理規範。

不然最後可能會疲於奔命，人的時間精力老是有限的，而面對整個公司的監控告警的搭建，體系上與業務組的共建，督促告警響應，極有可能最後會疲於奔命，即便真的有必定用處，在雜亂無人收斂的告警中最後流於形式。

總結

監控告警的體系生態作來有意義嗎？

這是必然的，成熟且規範的監控告警的體系生態是具備極大意義，能夠提早發現問題，定位問題，解決問題。甚至這個問題的說不定還不須要你本身處理，作多組件的閉環後，直接實施自動化的服務自愈就能夠了，安心又快快樂樂的過國慶節，是很香的。

而故障管理的閉環實施後，就能夠分析業務服務的告警狀況，結合 CI/CD 系統等基礎平臺，每季度自動化分析實施運營報表，幫助業務發現更多的問題，提供其特有的價值。

但，想真正作到上述所說的成熟且規範，業務共建，有難度，須要多方面認同和公司規範支撐才能最佳實現。所以共同承認，求同存異，多作用戶反饋分析也很是重要。

分享 Go 語言、微服務架構和奇怪的系統設計

👆 長按關注煎魚，在知識的海洋裏遨遊

本文分享自微信公衆號 - 腦子進煎魚了（eddycjy）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。