公司樓下的咖啡機(jī)壞了，沒(méi)人發(fā)現(xiàn)，直到連續(xù)三天沒(méi)人喝上咖啡。系統(tǒng)出問(wèn)題也一樣，等用戶反饋才去查，早就晚了。與其被動(dòng)救火，不如提前設(shè)好監(jiān)控告警配置，讓異常自動(dòng)跳到你眼前。
告警不是越多越好
剛接手運(yùn)維時(shí)，總想著把所有指標(biāo)都加上告警，CPU、內(nèi)存、磁盤、接口響應(yīng)時(shí)間……結(jié)果半夜手機(jī)狂響，90%是誤報(bào)。后來(lái)才明白，有效的監(jiān)控告警配置，關(guān)鍵不在“全”，而在“準(zhǔn)”。
比如一個(gè)服務(wù)的CPU使用率突然飆到85%，看起來(lái)挺嚇人，但如果歷史數(shù)據(jù)顯示它日常就在75%-80%之間波動(dòng)，那這個(gè)值其實(shí)正常。反而是一個(gè)平時(shí)只用20%的后臺(tái)任務(wù)，某天突然持續(xù)占用50%，更值得警惕。
從場(chǎng)景出發(fā)設(shè)置閾值
別照搬網(wǎng)上的“最佳實(shí)踐”。每個(gè)系統(tǒng)的負(fù)載模式不同，告警閾值得結(jié)合業(yè)務(wù)來(lái)定。電商系統(tǒng)在大促前一周，流量翻倍是常態(tài)，這時(shí)候還按平時(shí)的QPS閾值告警，只會(huì)讓自己神經(jīng)衰弱。
可以這樣操作：先觀察一周的運(yùn)行數(shù)據(jù)，找出正常波動(dòng)范圍，再在這個(gè)基礎(chǔ)上加個(gè)安全邊際。比如平均響應(yīng)時(shí)間是200ms，偶爾沖到400ms，那就把告警閾值設(shè)在600ms，持續(xù)超過(guò)3分鐘再觸發(fā)。
告警信息要能直接干活
收到一條告警：“服務(wù)器192.168.3.11 CPU過(guò)高”。然后呢？還得登錄系統(tǒng)查進(jìn)程、看日志，等搞清楚原因，十分鐘過(guò)去了。好的告警配置，應(yīng)該讓你一眼就知道下一步動(dòng)作。
比如改成：“【高優(yōu)先級(jí)】訂單服務(wù)節(jié)點(diǎn) 192.168.3.11 CPU 持續(xù)高于80%，最近5分鐘有大量慢查詢，建議檢查數(shù)據(jù)庫(kù)連接池”。信息明確，處理路徑清晰，節(jié)省的是實(shí)實(shí)在在的時(shí)間。
用代碼管理告警規(guī)則
在Web界面點(diǎn)點(diǎn)點(diǎn)配置告警，改幾次就亂了?，F(xiàn)在主流的做法是把告警規(guī)則寫(xiě)成代碼，放在Git里統(tǒng)一管理。
以Prometheus為例，可以把告警規(guī)則定義在YAML文件中：
groups:
- name: example-alerts
rules:
- alert: HighCpuUsage
expr: rate(node_cpu_seconds_total{mode!="idle"}[5m]) > 0.8
for: 3m
labels:
severity: warning
annotations:
summary: "{{ $labels.instance }} CPU 使用過(guò)高"
description: "{{ $labels.instance }} 連續(xù)3分鐘CPU使用率超過(guò)80%，請(qǐng)檢查是否有異常進(jìn)程。"
這樣一來(lái)，誰(shuí)改了規(guī)則、什么時(shí)候改的、為什么改，全部可追溯。新成員接手也方便，不用靠口頭交代。
別忘了測(cè)試和靜默
上線新告警前，先在測(cè)試環(huán)境模擬觸發(fā)一次，看看通知能不能順利到達(dá)手機(jī)。有時(shí)候配置寫(xiě)對(duì)了，但通知渠道沒(méi)通，等于白搭。
還有就是維護(hù)窗口。計(jì)劃內(nèi)重啟服務(wù)前，記得給相關(guān)告警加個(gè)靜默（silence），避免凌晨三點(diǎn)被自己嚇醒。很多團(tuán)隊(duì)都有過(guò)這種經(jīng)歷：明明知道要升級(jí)，還是被自己的告警吵起來(lái)，體驗(yàn)極差。
監(jiān)控告警配置不是一勞永逸的事。業(yè)務(wù)在變，系統(tǒng)在長(zhǎng)，每隔一段時(shí)間就得回頭看看，哪些告警已經(jīng)失效，哪些需要調(diào)整。把它當(dāng)成日常巡檢的一部分，比出事后再補(bǔ)強(qiáng)得多。