[[345029]]

本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。  

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

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

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

前言

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

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

問題

更要命的是你無法掌握主動權，錯誤日志有可能會有人漏記錄，平均修復時間(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 系統等基礎平臺，每季度自動化分析實施運營報表，幫助業務發現更多的問題，提供其特有的價值。

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

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