建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「腦子進(jìn)煎魚(yú)了」，作者陳煎魚(yú)。轉(zhuǎn)載本文請(qǐng)聯(lián)系腦子進(jìn)煎魚(yú)了公眾號(hào)。
“你說(shuō)說(shuō)，沒(méi)有儀表盤(pán)的車(chē)，你敢開(kāi)嗎?”
“沒(méi)有儀表盤(pán)的車(chē)開(kāi)在路上，你怎么知道現(xiàn)在是什么情況?”
“客戶(hù)說(shuō)你這車(chē)又崩了，咋知道什么時(shí)候好的?啥時(shí)候出的問(wèn)題?”
前言
將思考轉(zhuǎn)換到現(xiàn)實(shí)的軟件系統(tǒng)中，可想而知沒(méi)有監(jiān)控系統(tǒng)的情況下，也就是沒(méi)有 ”儀表盤(pán)“ 的情況下實(shí)在是太可怕了。
你的故障永遠(yuǎn)都是你的客戶(hù)告訴你的，而...在什么時(shí)候發(fā)生的，你也無(wú)法確定，只能通過(guò)客戶(hù)的反饋倒推時(shí)間節(jié)點(diǎn)，最后從錯(cuò)誤日志中得到相對(duì)完整的日志信息。
問(wèn)題
更要命的是你無(wú)法掌握主動(dòng)權(quán)，錯(cuò)誤日志有可能會(huì)有人漏記錄，平均修復(fù)時(shí)間(MTTR)更不用想了，需要從 0.1 開(kāi)始定位，先看 APP 是哪個(gè)模塊報(bào)錯(cuò)，再猜測(cè)是哪個(gè)服務(wù)導(dǎo)致，再打開(kāi)鏈路追蹤系統(tǒng)，或是日志平臺(tái)等。
稍微復(fù)雜些的，排查來(lái)來(lái)往往基本都是半小時(shí)、一小時(shí)以上，那 4 個(gè) 9 肯定是達(dá)不到的了，以此幾次 P0 幾小時(shí)怕不是業(yè)務(wù)績(jī)效也涼涼，因?yàn)楣收闲迯?fù)的速度實(shí)在是太慢了。
那歸根到底，想破局怎么辦，核心第一步就是要把監(jiān)控告警的整個(gè)生態(tài)圈給建設(shè)好。
監(jiān)控定義
常說(shuō)監(jiān)控監(jiān)控，監(jiān)控的定義就是監(jiān)測(cè)和控制，檢測(cè)某些事物的變化，以便于進(jìn)行控制。在常見(jiàn)的軟件系統(tǒng)中，大多分為三大觀察類(lèi)別：
- 業(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)來(lái)講，監(jiān)控的定義就是收集、處理、匯總，顯示關(guān)于某個(gè)系統(tǒng)的實(shí)時(shí)量化數(shù)據(jù)，例如：請(qǐng)求的數(shù)量和類(lèi)型，錯(cuò)誤的數(shù)量和類(lèi)型，以及各類(lèi)調(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)線(xiàn)上環(huán)境的各種各樣奇奇怪怪的問(wèn)題，為業(yè)務(wù)的正常運(yùn)轉(zhuǎn)保駕護(hù)航。
因此整體分為上圖四項(xiàng)：
- 預(yù)測(cè)故障：故障還沒(méi)出現(xiàn)，但存在異常。監(jiān)控系統(tǒng)根據(jù)流量模型、數(shù)據(jù)分析、度量趨勢(shì)來(lái)推算應(yīng)用程序的異常趨勢(shì)，推算可能出現(xiàn)故障的問(wèn)題點(diǎn)。
- 發(fā)現(xiàn)故障：故障已經(jīng)出現(xiàn)，客戶(hù)還沒(méi)反饋到一線(xiàn)人員。監(jiān)控系統(tǒng)根據(jù)真實(shí)的度量趨勢(shì)來(lái)計(jì)算既有的告警規(guī)則，發(fā)現(xiàn)已經(jīng)出現(xiàn)故障的問(wèn)題點(diǎn)。
- 定位故障：故障已經(jīng)出現(xiàn)，需要監(jiān)控系統(tǒng)協(xié)助快速定位問(wèn)題，也就是根因定位(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)所告警出來(lái)的問(wèn)題作為起始錨點(diǎn)，對(duì)其進(jìn)行有特定方向的分析，再形成 ”線(xiàn)索“ 報(bào)告，就可以大力的協(xié)助開(kāi)發(fā)人員快速的定位問(wèn)題，發(fā)現(xiàn)故障點(diǎn)。
- 故障恢復(fù)：故障已經(jīng)出現(xiàn)，但自動(dòng)恢復(fù)了，又或是通過(guò)自動(dòng)化自愈了。這種情況大多出現(xiàn)在告警規(guī)則的閾值配置的不夠妥當(dāng)，又或是第三方依賴(lài)恰好恢復(fù)了的場(chǎng)景。
而更值得探討的的是監(jiān)控告警的后半段閉環(huán)，故障自愈，通過(guò)上述三點(diǎn) “預(yù)測(cè)故障、發(fā)現(xiàn)故障、定位故障”，已經(jīng)定位到故障了，就可以配合內(nèi)部組件，實(shí)現(xiàn)自動(dòng)化的 ”自愈“，減少人工介入，提高 MTTR。
因此做監(jiān)控系統(tǒng)的目標(biāo)很明確，就是發(fā)現(xiàn)問(wèn)題，解決問(wè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)控場(chǎng)景都可以歸類(lèi)進(jìn)來(lái)。
針對(duì)這三大項(xiàng)，《Google SRE 運(yùn)維解密》 也總結(jié)出了 4 個(gè)黃金指標(biāo)，在業(yè)界廣為流傳和借鑒：
- 延遲：服務(wù)處理某個(gè)請(qǐng)求所需要的時(shí)間。
- 區(qū)分成功和失敗請(qǐng)求很重要，例如：某個(gè)由于數(shù)據(jù)庫(kù)連接丟失或者其他后端問(wèn)題造成的 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ù)器來(lái)講，該指標(biāo)通常是每秒 HTTP 請(qǐng)求數(shù)量，同時(shí)可能按請(qǐng)求類(lèi)型分類(lèi)(靜態(tài)請(qǐng)求與動(dòng)態(tài)請(qǐng)求)。
- 針對(duì)音頻流媒體系統(tǒng)來(lái)說(shuō)，指標(biāo)可能是網(wǎng)絡(luò) I/O 速率，或者并發(fā)會(huì)話(huà)數(shù)量。
- 針對(duì)鍵值對(duì)存儲(chǔ)系統(tǒng)來(lái)說(shuō)，指標(biāo)可能是每秒交易數(shù)量，或每秒的讀者操作數(shù)量。
- 錯(cuò)誤：請(qǐng)求失敗的速率。
- 顯式失敗(例如：HTTP 500)。
- 隱式失敗(例如：HTTP 200 回復(fù)中包含了錯(cuò)誤內(nèi)容)。
- 策略原因?qū)е碌氖?例如：如果要求回復(fù)在 1s 內(nèi)發(fā)出，任何超過(guò) 1s 的請(qǐng)求就都是失敗請(qǐng)求)。
- 飽和度：服務(wù)容量有多 “滿(mǎn)”，通常是系統(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% 的請(qǐng)求延遲(在某一個(gè)小的時(shí)間范圍內(nèi)，例如一分鐘)可以作為一個(gè)飽和度早期預(yù)警的指標(biāo)。
- 飽和度需要進(jìn)行預(yù)測(cè)，例如 “看起來(lái)數(shù)據(jù)庫(kù)會(huì)在 4 小時(shí)內(nèi)填滿(mǎn)硬盤(pán)”。
如果已經(jīng)成功度量了這四個(gè)黃金指標(biāo)，且在某個(gè)指標(biāo)出現(xiàn)故障時(shí)能夠發(fā)出告警(或者快要發(fā)生故障)，那么在服務(wù)的監(jiān)控層面來(lái)講，基本也就滿(mǎn)足了初步的監(jiān)控訴求。
也就是可以做到知道了是什么出問(wèn)題，問(wèn)題出在哪里，單這一步就已經(jīng)提高了不少定位問(wèn)題的時(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)占比也越來(lái)越高，其基本架構(gòu)如下：
- Prometheus Server：用于收集指標(biāo)和存儲(chǔ)時(shí)間序列數(shù)據(jù)，并提供一系列的查詢(xún)和設(shè)置接口。
- Grafana：用于展示各類(lèi)趨勢(shì)圖，通過(guò) PromQL 從 Prometheus 服務(wù)端查詢(xún)并構(gòu)建圖表。
- Alertmanager：用于處理告警事件，從 Prometheus 服務(wù)端接收到 alerts 后，會(huì)進(jìn)行去重，分組，然后路由到對(duì)應(yīng)的Receiver，發(fā)出報(bào)警。
這塊具體的基本知識(shí)學(xué)習(xí)和搭建可詳見(jiàn)我寫(xiě)的 Prometheus 系列，本文不再贅述。
監(jiān)控指標(biāo)
在平臺(tái)搭建完畢后，常要做的第一步，那就是規(guī)劃你整個(gè)系統(tǒng)的度量指標(biāo)，結(jié)合 Google SRE 的 4 個(gè)黃金指標(biāo)，可以初步劃分出如下幾種常用類(lèi)型：
- 系統(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ù)測(cè)/預(yù)警的一系列動(dòng)作，面對(duì)突發(fā)性流量的自動(dòng)化擴(kuò)縮容有一定的參考意義。
- 業(yè)務(wù)服務(wù)：RPC 方法等的錯(cuò)誤情況。能夠發(fā)現(xiàn)應(yīng)用程序、業(yè)務(wù)的常見(jiàn)異常情況，但需要在狀態(tài)/錯(cuò)誤碼規(guī)劃合理的情況下，能夠起到較大的作用，有一定困難，要在一開(kāi)始就做對(duì)，否則后面很難扭轉(zhuǎn)。
- 應(yīng)用程序：各類(lèi)遠(yuǎn)程調(diào)用(例如：RPC、SQL、HTTP、Redis)的調(diào)用開(kāi)銷(xiāo)記錄。最萬(wàn)金油的度量指標(biāo)之一，能夠在很多方面提供精確的定位和分析，Web 應(yīng)用程序標(biāo)配。常見(jiàn)于使用 P99/95/90。
- 語(yǔ)言級(jí)別：內(nèi)部分析記錄，例如：Goroutines 數(shù)量、Panic 情況等，常常能發(fā)現(xiàn)一些意想不到的泄露情況和空指針調(diào)用。沒(méi)有這類(lèi)監(jiān)控的話(huà)，很有可能一直都不會(huì)被發(fā)現(xiàn)。
指標(biāo)落地
第一步完成了整個(gè)系統(tǒng)的度量指標(biāo)規(guī)劃后，第二步就是需要確確實(shí)實(shí)的把指標(biāo)落地了。
無(wú)論是統(tǒng)一基礎(chǔ)框架的打點(diǎn)，系統(tǒng)組件的 exporter，大多涉及了公司級(jí)的跨多部門(mén)協(xié)作，這時(shí)候需要更多的耐心和長(zhǎng)期主義和不斷地對(duì)方向糾錯(cuò)，才能?chē)L到體系建設(shè)后的果實(shí)。
告警體系
在完成監(jiān)控指標(biāo)和體系的建設(shè)后，告警如何做，成為了一大難題，再好的監(jiān)控體系，閉環(huán)做不好，就無(wú)法發(fā)揮出很大的作用。因此我們給告警定義一些準(zhǔn)則：
告警不要太多，否則會(huì)導(dǎo)致“狼來(lái)了”。
告警出現(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)足夠的簡(jiǎn)單，直觀，不需要猜。
簡(jiǎn)單來(lái)講就是告警要少，事件需要解決，處理要人工介入。否則右拐自動(dòng)化自愈恢復(fù)可能更香。
告警給誰(shuí)?
另外一個(gè)難題就是：誰(shuí)誘發(fā)處理的告警，要通知給誰(shuí)?
這是一個(gè)很需要斟酌的問(wèn)題，在告警的規(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)即跟蹤，明確問(wèn)題點(diǎn)的責(zé)任人。而逐級(jí)上報(bào)的數(shù)據(jù)來(lái)源，可通過(guò)員工管理系統(tǒng)來(lái)獲取，在員工管理系統(tǒng)中有完整的上下級(jí)關(guān)系(類(lèi)似 OA 審批上看到的流程節(jié)點(diǎn))，但如果該系統(tǒng)沒(méi)有開(kāi)放 API 之類(lèi)的，那可能你只能通過(guò)其他方式來(lái)獲取了。
例如像是通過(guò)企業(yè)微信獲取部門(mén)關(guān)系和人員列表，再手動(dòng)設(shè)置上下級(jí)關(guān)聯(lián)關(guān)系，也可以達(dá)到目的，且在現(xiàn)實(shí)世界中，有可能存在定制化的訴求。
規(guī)范建立
即使所以監(jiān)控體系、指標(biāo)落地、告警體系都建立起來(lái)了，也不能掉以輕心。實(shí)際上在成為事實(shí)標(biāo)準(zhǔn)后，你仍然需要盡快為告警后奔跑，將整個(gè)閉環(huán)搭建起來(lái)，也就是故障管理。
與公司內(nèi)部的流程管理的同學(xué)或 QA，一起設(shè)立研發(fā)底線(xiàn)的規(guī)范，進(jìn)行細(xì)致的告警分級(jí)識(shí)別，告警后的匯總運(yùn)營(yíng)分析，形成一個(gè)真正意義上的故障管理規(guī)范。
否則最后可能會(huì)疲于奔命，人的時(shí)間精力總是有限的，而面對(duì)整個(gè)公司的監(jiān)控告警的搭建，體系上與業(yè)務(wù)組的共建，督促告警響應(yīng)，極有可能最后會(huì)疲于奔命，即使真的有一定用處，在雜亂無(wú)人收斂的告警中最后流于形式。
總結(jié)
監(jiān)控告警的體系生態(tài)做來(lái)有意義嗎?
這是必然的，成熟且規(guī)范的監(jiān)控告警的體系生態(tài)是具有極大意義，可以提前發(fā)現(xiàn)問(wèn)題，定位問(wèn)題，解決問(wèn)題。甚至這個(gè)問(wèn)題的說(shuō)不定還不需要你自己處理，做多組件的閉環(huán)后，直接實(shí)施自動(dòng)化的服務(wù)自愈就可以了，安心又快快樂(lè)樂(lè)的過(guò)國(guó)慶節(jié)，是很香的。
而故障管理的閉環(huán)實(shí)施后，就可以分析業(yè)務(wù)服務(wù)的告警情況，結(jié)合 CI/CD 系統(tǒng)等基礎(chǔ)平臺(tái)，每季度自動(dòng)化分析實(shí)施運(yùn)營(yíng)報(bào)表，幫助業(yè)務(wù)發(fā)現(xiàn)更多的問(wèn)題，提供其特有的價(jià)值。
但，想真正做到上述所說(shuō)的成熟且規(guī)范，業(yè)務(wù)共建，有難度，需要多方面認(rèn)同和公司規(guī)范支撐才能最佳實(shí)現(xiàn)。因此共同認(rèn)可，求同存異，多做用戶(hù)反饋分析也非常重要。
分享名稱(chēng)：想要4個(gè)9？本文告訴你監(jiān)控告警如何做
文章鏈接：http://fisionsoft.com.cn/article/dpodcdd.html
