[[345029]]

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

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

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

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

前言

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

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

問題

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

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

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

監(jiān)控定義

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

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

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

監(jiān)控目標

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

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

因此整體分為上圖四項：

• 預(yù)測故障：故障還沒出現(xiàn)，但存在異常。監(jiān)控系統(tǒng)根據(jù)流量模型、數(shù)據(jù)分析、度量趨勢來推算應(yīng)用程序的異常趨勢，推算可能出現(xiàn)故障的問題點。
• 發(fā)現(xiàn)故障：故障已經(jīng)出現(xiàn)，客戶還沒反饋到一線人員。監(jiān)控系統(tǒng)根據(jù)真實的度量趨勢來計算既有的告警規(guī)則，發(fā)現(xiàn)已經(jīng)出現(xià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)所告警出來的問題作為起始錨點，對其進行有特定方向的分析，再形成 ”線索“ 報告，就可以大力的協(xié)助開發(fā)人員快速的定位問題，發(fā)現(xiàn)故障點。
• 故障恢復：故障已經(jīng)出現(xiàn)，但自動恢復了，又或是通過自動化自愈了。這種情況大多出現(xiàn)在告警規(guī)則的閾值配置的不夠妥當，又或是第三方依賴恰好恢復了的場景。

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

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

4 個黃金指標

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

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

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

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

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

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

實踐案例

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

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

平臺搭建

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

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

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

監(jiān)控指標

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

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

指標落地

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

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

告警體系

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

告警不要太多，否則會導致“狼來了”。

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

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

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

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

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

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

告警給誰?

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

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

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

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

規(guī)范建立

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

與公司內(nèi)部的流程管理的同學或 QA，一起設(shè)立研發(fā)底線的規(guī)范，進行細致的告警分級識別，告警后的匯總運營分析，形成一個真正意義上的故障管理規(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è)務(wù)發(fā)現(xiàn)更多的問題，提供其特有的價值。

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

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