1. 從一次“重啟告警”說起現(xiàn)場還原與第一反應(yīng)凌晨一點釘釘群連響三聲告警標(biāo)題寫著“MYSQL_PROD_01 instance restarted”觸發(fā)表達(dá)式是changes(process_start_time_seconds{jobmysql}[5m]) 0。值班同事把截圖丟進(jìn)群里我的第一反應(yīng)是看看數(shù)據(jù)庫內(nèi)部狀態(tài)登錄上去執(zhí)行show status like uptime返回的是一個持續(xù)了兩百多天的運(yùn)行秒數(shù)線程數(shù)、連接數(shù)、慢查詢統(tǒng)計全部正常沒有任何重啟痕跡。群里的對話幾乎可以預(yù)料“數(shù)據(jù)庫沒動Prometheus是不是抽風(fēng)了”這種場景在維護(hù)過 Prometheus 監(jiān)控數(shù)據(jù)庫的人眼里并不陌生監(jiān)控判定數(shù)據(jù)庫重啟了數(shù)據(jù)庫自己卻堅持聲稱根本沒重啟。兩邊掌握的證據(jù)完全沖突而且誰都不是故意說謊。這個問題的核心在于Prometheus 眼里的“重啟”和數(shù)據(jù)庫內(nèi)部的“重啟”是兩個不同維度的事件。這篇文章我會把這類誤報的根因拆開講清楚從 Prometheus 判定重啟的原理、到最常見的幾種“假重啟”信號、再到真實案例復(fù)盤和告警規(guī)則優(yōu)化一次講透。如果你正在寫數(shù)據(jù)庫相關(guān)的 PromQL 告警規(guī)則或者被這類“幽靈重啟”告警折騰過這篇內(nèi)容應(yīng)該能幫你省掉不少凌晨的折騰。1.1 告警長什么樣DBA為什么堅決說沒重啟先還原一下告警本身。這類告警通常由 Alertmanager 聚合后發(fā)出正文里往往只有幾條標(biāo)簽和一個簡短的 PromQL 表達(dá)式。告警屬性示例值告警名稱MySQL process restarted觸發(fā)表達(dá)式changes(process_start_time_seconds{jobmysql}[5m]) 0觸發(fā)時間2025-06-11 23:58:17監(jiān)控目標(biāo)instance10.0.8.15:9104 jobmysql告警級別P1 / Critical收到告警后DBA 的第一反應(yīng)通常是查數(shù)據(jù)庫進(jìn)程到底有沒有重啟show status like uptime看運(yùn)行時長檢查 processlist 里的連接創(chuàng)建時間或者看一眼 binlog 和 relay log 的文件序號。如果這些證據(jù)都指向“進(jìn)程一直在線”DBA 就會理直氣壯地回復(fù)“數(shù)據(jù)庫沒動”。站在他的視角這句話沒有錯因為數(shù)據(jù)庫內(nèi)部確實沒有發(fā)生過重啟事件。但 Prometheus 也不是無中生有。它觀察到的process_start_time_seconds確實在窗口內(nèi)發(fā)生了變化這個值代表著數(shù)據(jù)庫進(jìn)程的啟動時間戳正常情況下恒定不變一旦出現(xiàn)跳變監(jiān)控端有充分的理由判定“進(jìn)程重啟了”。兩邊說的都是各自視角下的客觀事實問題出在“進(jìn)程啟動時間戳變化”這個信號本身能否等價于“數(shù)據(jù)庫重啟”。實際排查中這個等價關(guān)系經(jīng)常不成立也就是我們要聊的“假重啟”。1.2 常規(guī)排查路徑先別改告警規(guī)則先看這五張圖遇到這類告警我的建議是不要急著去修改告警規(guī)則、不要 silence先拉五張圖把證據(jù)鏈補(bǔ)完整。第一張是process_start_time_seconds的曲線重點看它是單點跳變還是持續(xù)變化跳變幅度有多大。第二張是同一臺機(jī)器的node_time_seconds或者系統(tǒng)時間曲線看同一時間窗內(nèi)有沒有出現(xiàn)時間回?fù)芑蛱內(nèi)绻到y(tǒng)時間被 NTP 調(diào)整過進(jìn)程啟動時間戳的計算基準(zhǔn)就會被帶偏。第三張是采集器的up指標(biāo)看數(shù)據(jù)庫 exporter 在告警前有沒有短暫置 0。第四張是數(shù)據(jù)庫內(nèi)部 uptime 指標(biāo)MySQL 對應(yīng)mysql_global_status_uptimePostgreSQL 對應(yīng)pg_postmaster_start_time如果進(jìn)程真的重啟了這個值一定會歸零重新開始累計。第五張要看部署環(huán)境容器場景下查 Pod 重啟次數(shù)和漂移記錄物理機(jī)場景下查 systemd 的服務(wù)狀態(tài)變更和 journalctl 日志時間線。這五張圖拉出來誤報的方向基本就能鎖定。很多人拿到告警的第一反應(yīng)是打開 Alertmanager 把規(guī)則靜默掉這是最危險的操作。因為“謊報重啟”背后往往藏著一個真實問題可能是監(jiān)控采集器不穩(wěn)定、系統(tǒng)時鐘異常也可能是數(shù)據(jù)庫確實發(fā)生了自動恢復(fù)但沒有被業(yè)務(wù)感知。silence 只能讓告警不再打擾你卻無法讓問題消失所以我一直堅持“先看證據(jù)再動規(guī)則”。1.3 數(shù)據(jù)口徑數(shù)據(jù)庫uptime與Prometheus怎么看“重啟”這里需要理清一個基礎(chǔ)概念Prometheus 本身沒有“重啟事件”這種記錄它只保存時間序列。我們判斷一個進(jìn)程是否重啟通常依賴三類信號。第一類是進(jìn)程啟動時間戳也就是process_start_time_seconds一旦變化就說明進(jìn)程的啟動時刻變了。第二類是數(shù)據(jù)庫內(nèi)部的運(yùn)行時長指標(biāo)比如 MySQL 的 uptime 或者pg_postmaster_start_time歸零重計才是真正的進(jìn)程級重啟。第三類是業(yè)務(wù)層面的信號比如連接數(shù)斷崖、線程數(shù)清零、主從延遲突變這些指標(biāo)能反映出服務(wù)可用性的變化。這三類信號在正常運(yùn)行時是同步的進(jìn)程真重啟時啟動時間戳變化、內(nèi)部 uptime 歸零、連接數(shù)重建會在同一時間窗內(nèi)一起出現(xiàn)。但如果只有啟動時間戳變化而內(nèi)部 uptime 連續(xù)說明問題大概率出在采集端或時間基準(zhǔn)上。我在排查中會把這句話當(dāng)作一個基本判斷框架先問自己哪個指標(biāo)變了哪個指標(biāo)沒變變化之間能不能用“數(shù)據(jù)庫進(jìn)程重啟”這一個假設(shè)統(tǒng)一解釋解釋不通就別急著下結(jié)論。2. “假重啟”的機(jī)制解剖毫厘之間藏著哪些變量要理解為什么數(shù)據(jù)庫沒動、Prometheus 卻說重啟了必須先搞清楚 Prometheus 是如何得到進(jìn)程啟動時間戳的。這個過程不算復(fù)雜但里面藏著好幾個容易出問題的細(xì)節(jié)每一個細(xì)節(jié)都可能讓一個本來穩(wěn)穩(wěn)當(dāng)當(dāng)?shù)谋O(jiān)控項變得敏感異常。2.1 Prometheus判定重啟的核心依據(jù)process_start_time_seconds與changes()在 Linux 環(huán)境下process_start_time_seconds通常由 node_exporter 或 mysqld_exporter 暴露。它的計算方式是讀取/proc/[pid]/stat中的 starttime 字段這個字段記錄的是進(jìn)程自系統(tǒng)啟動以來經(jīng)過的時鐘 tick 數(shù)再結(jié)合系統(tǒng)啟動時間換算成 Unix 時間戳。對 mysqld 這類常駐進(jìn)程來說這個值從進(jìn)程創(chuàng)建那一刻起就固定了無論系統(tǒng)運(yùn)行多久都不會改變所以它成了判斷重啟的天然錨點。PromQL 里有一個專門配合它使用的函數(shù)changes()作用是統(tǒng)計一個時間序列在指定時間窗口內(nèi)發(fā)生變化的次數(shù)。changes(process_start_time_seconds[5m]) 0表達(dá)的就是“在最近 5 分鐘內(nèi)進(jìn)程啟動時間戳發(fā)生過變化”。這個判斷邏輯本身是合理的一旦這個值變了說明被監(jiān)控對象確實重新創(chuàng)建過。但它隱含了兩個前提假設(shè)第一這個時間戳完全來自進(jìn)程本身第二系統(tǒng)時間軸是穩(wěn)定的。實際運(yùn)維中這兩個前提都可能被打破。Prometheus 默認(rèn)的抓取間隔通常是 15 秒如果某個 target 在超過 5 分鐘沒有上報數(shù)據(jù)這個時間序列會被標(biāo)記為 stale也就是過期。過期之后再恢復(fù)上報某些聚合函數(shù)的計算結(jié)果會出現(xiàn)波動這也是很多“假重啟”告警在查詢層面被放大的原因。你看到的可能不是進(jìn)程真的重啟了而是時間序列的新鮮度發(fā)生變化導(dǎo)致 changes 的計算結(jié)果出現(xiàn)了非預(yù)期跳變。2.2 四種典型的“類重啟”信號根據(jù)我這幾年排查監(jiān)控誤報的經(jīng)驗所謂“假重啟”基本逃不出下面四類原因每一類背后的機(jī)制都不一樣特征曲線也各不相同。類型表面現(xiàn)象根因特征曲線驗證方法采集器自身重啟start_time 變化internal uptime 連續(xù)mysqld_exporter / node_exporter 被 OOM 或手動拉起up 指標(biāo)短暫置 0restart 計數(shù)增加查看 systemd 狀態(tài)與 journalctl 日志系統(tǒng)時間跳變start_time 小幅突變NTP 回?fù)芑蚴謩诱{(diào)整系統(tǒng)時間node_time_seconds 同時出現(xiàn)臺階對比 node_time_seconds查系統(tǒng)日志PID 復(fù)用start_time 變化但進(jìn)程其實沒重啟采集目標(biāo) PID 被新進(jìn)程復(fù)用指標(biāo)值和 /proc 實際信息不一致執(zhí)行 cat /proc/[pid]/stat 對比容器漂移或高可用切換start_time 變化業(yè)務(wù)側(cè)無感知調(diào)度器重排 Pod、VIP 切換后端實例連接數(shù)、線程數(shù)等曲線同時跳變查容器事件、VIP 變動記錄第一種采集器自身重啟非常常見尤其是內(nèi)存比較緊張的機(jī)器上mysqld_exporter 這類小進(jìn)程很容易被內(nèi)核 OOM Killer 選中隨后被 systemd 自動拉起來。數(shù)據(jù)庫沒動但它的“眼睛”眨了一下Prometheus 就把這次眨眼當(dāng)成了數(shù)據(jù)庫重啟。第二種系統(tǒng)時間跳變是最隱蔽的因為調(diào)整的往往是毫秒級或秒級的偏移肉眼根本察覺不到但在計算啟動時間戳?xí)r會留下清晰的痕跡。第三種 PID 復(fù)用主要影響 exporter 這類生命周期短的進(jìn)程數(shù)據(jù)庫主進(jìn)程上概率較低。第四種容器漂移和高可用切換在云原生環(huán)境里越來越常見數(shù)據(jù)庫數(shù)據(jù)沒丟、業(yè)務(wù)無感但監(jiān)控視角的實例已經(jīng)換了一個。2.3 你的告警規(guī)則為什么這么容易被觸發(fā)很多時候誤報頻發(fā)不是因為監(jiān)控工具不行而是告警規(guī)則本身寫得太粗糙。我自己早期也踩過不少坑總結(jié)下來最容易觸發(fā)誤報的寫法有這么幾種。第一是時間窗口設(shè)得太短。changes(process_start_time_seconds[1m]) 0這種規(guī)則只要采集端一個抓取周期內(nèi)出現(xiàn)抖動就會命中Prometheus 的抓取偶爾延遲個一兩秒或者網(wǎng)絡(luò)產(chǎn)生瞬時擁塞都會造成指標(biāo)值的異常波動被誤認(rèn)為重啟。第二是忽略了時間基準(zhǔn)變化。規(guī)則里只判斷啟動時間戳變化沒有同時判斷node_time_seconds是否變化于是 NTP 回?fù)芫捅划?dāng)成了一次重啟。第三是不區(qū)分“數(shù)據(jù)庫進(jìn)程重啟”和“采集器重啟”只要 start_time 變化就觸發(fā) Critical 級告警把監(jiān)控鏈路的脆弱性放大成了業(yè)務(wù)故障。第四是for子句缺失或過短導(dǎo)致一次瞬時毛刺直接升級到最高級別通知。我后來在寫告警規(guī)則時都會過一遍自檢清單這個規(guī)則的判斷窗口能不能覆蓋至少兩到三個抓取周期有沒有結(jié)合其他指標(biāo)共同確認(rèn)變化幅度是否需要設(shè)置一個閾值如果這些問題回答不上來規(guī)則仍然處于“看見影子就開槍”的狀態(tài)。2.4 疑似誤報速查表排查過程中我習(xí)慣把判斷口訣壓縮成一張速查表遇到告警先對照一遍往往能在十分鐘內(nèi)定位方向。檢查項正常情況異常含義process_start_time_seconds 是否跳變恒定進(jìn)程創(chuàng)建時間發(fā)生變化同節(jié)點 node_time_seconds 是否跳變平穩(wěn)遞增系統(tǒng)時間被調(diào)整可能導(dǎo)致假重啟up 指標(biāo)是否連續(xù)為 1連續(xù)出現(xiàn) 0 說明采集器中斷過mysql_global_status_uptime 是否連續(xù)單調(diào)遞增歸零重啟才是數(shù)據(jù)庫進(jìn)程級重啟容器場景 Pod 重啟次數(shù)無變化發(fā)生變化說明運(yùn)行時重建數(shù)據(jù)庫連接數(shù)是否有斷崖平穩(wěn)波動整體歸零可能意味著實例不可用這個表格的價值在于幫你快速區(qū)分“該處理的”和“該忽略的”。如果只有第一項變化其余全正常那大概率是時間或采集層面的問題如果多項同時異常就可能是數(shù)據(jù)庫真的發(fā)生了一次無人察覺的自動恢復(fù)需要進(jìn)一步追查原因。3. 三個真實案例復(fù)盤從“謊報”到“實錘”理論講再多不如實際復(fù)盤幾個案例有說服力。下面這三個案例都是我在日常維護(hù)中真實遇到過的每個的根因都不一樣但它們的共同點是數(shù)據(jù)庫進(jìn)程本身都沒有主動重啟監(jiān)控卻給出了重啟告警。3.1 案例一NTP回?fù)軒资撩氡O(jiān)控自證“重啟”第一個案例發(fā)生在一套測試環(huán)境的 MySQL 實例上。凌晨四點告警觸發(fā)process_start_time_seconds從 1738496000 變成 1738496032變化了 32 秒。從數(shù)字上看這不像一個大跨度的時間跳變更像是進(jìn)程在 32 秒前被重新創(chuàng)建。但我登錄數(shù)據(jù)庫后uptime 顯示實例已經(jīng)運(yùn)行了 18 天完全沒有中斷跡象。我把 Grafana 時間軸拉近疊加了node_time_seconds曲線發(fā)現(xiàn)在同一時刻節(jié)點系統(tǒng)時間出現(xiàn)了一個明顯的回跳臺階幅度大約也是 32 秒和進(jìn)程啟動時間的變化完全吻合。再查系統(tǒng)日志確認(rèn)是 NTP 服務(wù)在同步時對系統(tǒng)時間進(jìn)行了一次回?fù)?。原理上并不?fù)雜node_exporter 計算進(jìn)程啟動時間時要結(jié)合當(dāng)前系統(tǒng)時間做換算墻上時鐘被回?fù)芎蟮雇瞥鰜淼倪M(jìn)程啟動時間就會向后偏移于是在 Prometheus 眼里一個已經(jīng)跑了 18 天的進(jìn)程突然變成了“32 秒前才啟動”。這個案例的教訓(xùn)有兩層。第一層是系統(tǒng)級對運(yùn)行監(jiān)控 agent 的機(jī)器要謹(jǐn)慎配置 NTP 同步策略避免出現(xiàn)大步回?fù)苋绻粋€節(jié)點上同時跑著大量被監(jiān)控進(jìn)程主機(jī)時間任何一次微小調(diào)整都可能在監(jiān)控端造成連鎖誤報。第二層是規(guī)則級判斷重啟時不能只盯著啟動時間戳還要把節(jié)點時間變化作為排除項否則 NTP 的毫厘之誤就會升級成一次數(shù)據(jù)庫“重啟故障”。3.2 案例二exporter被systemd靜默拉起數(shù)據(jù)庫毫發(fā)無損第二個案例更具迷惑性。告警顯示 MySQL 進(jìn)程重啟但數(shù)據(jù)庫的 uptime 連續(xù)我知道問題多半出在采集鏈路。打開 Prometheus 的 Target 頁面up指標(biāo)在告警前出現(xiàn)過一次 0 值持續(xù)時間大約 40 秒隨后恢復(fù)為 1。這個細(xì)節(jié)說明數(shù)據(jù)庫 exporter 在那段時間里不可達(dá)。再去被監(jiān)控節(jié)點上執(zhí)行systemctl status mysqld_exporter進(jìn)程狀態(tài)顯示 active但 restart 計數(shù)已經(jīng)增加了 1。翻看 journalctl發(fā)現(xiàn)了 OOM Killer 的行內(nèi)存壓力導(dǎo)致 mysqld_exporter 被殺systemd 隨即把它從一堆日志里默默拉了起來。為什么 Prometheus 會把這次 exporter 重啟當(dāng)成數(shù)據(jù)庫重啟因為process_start_time_seconds本來抓取的就是 exporter 視角下 mysqld 進(jìn)程的信息而 exporter 自己重啟后它重新采集、重新上報的進(jìn)程啟動時間戳依然是從 mysqld 的/proc里讀到的理論上不會變。真正變化的是 exporter 和 Prometheus 之間的通信上下文發(fā)生了變化up短暫置 0 后恢復(fù)配合抓取端對時間序列新鮮度的判斷最終在查詢層形成了一個“進(jìn)程重啟過”的假象。這個案例的啟示是數(shù)據(jù)庫雖然是核心服務(wù)但監(jiān)控鏈路本身的穩(wěn)定性同樣重要。mysqld_exporter 這類小進(jìn)程往往被忽視內(nèi)存限制沒配、資源爭搶時第一個被犧牲結(jié)果就是數(shù)據(jù)庫還穩(wěn)穩(wěn)跑著報警卻已經(jīng)打到值班電話上了。我后來把所有 exporter 都納入統(tǒng)一資源限制管理并為 exporter 自身重建設(shè)立了單獨的、低等級的告警和數(shù)據(jù)庫重啟告警區(qū)分開。3.3 案例三數(shù)據(jù)庫節(jié)點漂移業(yè)務(wù)無感但監(jiān)控“眼尖”第三個案例放在容器和主備切換的場景下。業(yè)務(wù)端通過一套 VIP 訪問 MySQL 主庫Prometheus 采集的也是這個 VIP 對應(yīng)的 mysqld_exporter 端口一切看起來都很正常。某天告警觸發(fā)說數(shù)據(jù)庫重啟但這次連數(shù)據(jù)庫內(nèi)部 uptime 都出現(xiàn)了歸零重計的跡象看起來像是實錘。然而 DBA 再次堅持?jǐn)?shù)據(jù)庫沒動因為兩個數(shù)據(jù)庫節(jié)點各自都運(yùn)行正常沒有主動重啟記錄。真相是 Keepalived 的 VIP 發(fā)生了漂移主庫所在節(jié)點出現(xiàn)短暫的心跳超時VIP 被切換到備庫Prometheus 依然對著 VIP 采集采集到的卻是備庫實例的指標(biāo)。備庫的process_start_time_seconds在 Prometheus 看來是一個“新的”時間戳內(nèi)部 uptime 也是從另一個起點開始累計于是一組合計下來一個完整的“重啟證據(jù)鏈”就拼出來了。但對業(yè)務(wù)來說VIP 切換過程中的連接重試讓服務(wù)幾乎沒有中斷應(yīng)用日志里也沒有出現(xiàn)大規(guī)模斷連。這個案例說明在數(shù)據(jù)庫主備切換或容器漂移場景下監(jiān)控對象已經(jīng)從“某一個具體進(jìn)程”變成了“某一個服務(wù)入口”。如果還固執(zhí)地用進(jìn)程啟動時間戳去判斷服務(wù)是否重啟必然會出現(xiàn)誤報。正確的做法是區(qū)分實例監(jiān)控和服務(wù)監(jiān)控進(jìn)程級重啟看內(nèi)部 uptime 和 start_time服務(wù)級可用性則要結(jié)合 VIP 探活、連接數(shù)、查詢成功率和主從狀態(tài)來判斷。4. 把誤報扼殺在規(guī)則層告警優(yōu)化與監(jiān)控架構(gòu)加固排查根因的過程固然有意思但真正讓運(yùn)維省心的還是把規(guī)則改成“不輕易說謊”的狀態(tài)。我見過很多團(tuán)隊被誤報折磨到把所有重啟告警全部靜默這等于把監(jiān)控的雙眼蒙上反而危險。更好的路徑是在規(guī)則層面加入多重確認(rèn)邏輯讓監(jiān)控在報警之前先自己排除常見干擾。4.1 單一changes()為什么不夠組合判斷怎么落單一的changes(process_start_time_seconds[5m]) 0有太多誤報空間把它作為唯一判據(jù)本質(zhì)上就是在用“猜”代替“確認(rèn)”。我的做法是把規(guī)則拆成兩層判斷先確認(rèn)啟動時間戳確實變化了再確認(rèn)這個變化不是一個已知干擾源導(dǎo)致的。第一類干擾排除是系統(tǒng)時間跳變。如果節(jié)點時間在同一個窗口內(nèi)發(fā)生了變化那么啟動時間戳的變化就不可信可以這樣抑制( changes(process_start_time_seconds{jobmysql}[15m]) 0 ) and on(instance) ( changes(node_time_seconds{jobnode}[15m]) 0 )這段表達(dá)式的含義是只有在節(jié)點時間保持穩(wěn)定的前提下啟動時間戳變化才被認(rèn)定為可疑事件。如果系統(tǒng)時間自己也跳了那我暫時不認(rèn)為數(shù)據(jù)庫發(fā)生了重啟。這個規(guī)則能過濾掉案例一里的 NTP 誤報。第二類干擾排除是采集器自身重啟。要確認(rèn)數(shù)據(jù)庫進(jìn)程真正重啟最好的證據(jù)來自數(shù)據(jù)庫內(nèi)部MySQL 的mysql_global_status_uptime是一個單調(diào)遞增的運(yùn)行秒數(shù)進(jìn)程重啟會讓它瞬間歸零重新累加而 exporter 重啟不會影響它的值。所以可以加一個內(nèi)部 uptime 下降判斷( changes(process_start_time_seconds{jobmysql}[15m]) 0 and delta(mysql_global_status_uptime{jobmysql}[15m]) 0 )如果啟動時間戳變了但數(shù)據(jù)庫內(nèi)部 uptime 在窗口內(nèi)始終保持單調(diào)遞增說明 mysqld 從來沒有重啟過問題出在采集端或者環(huán)境層。這套組合規(guī)則雖然多寫了幾行 PromQL但能過濾掉絕大部分誤報值得為每個核心數(shù)據(jù)庫單獨配置一套。4.2 外部探針與服務(wù)視角讓監(jiān)控自己排除干擾白盒指標(biāo)只能告訴我們“進(jìn)程視角發(fā)生了什么”要判斷一個數(shù)據(jù)庫服務(wù)是否真正可用還需要黑盒探針來補(bǔ)位。我通常會給核心數(shù)據(jù)庫配置兩個額外的監(jiān)控維度TCP 層面的撥測探針和 SQL 層面的執(zhí)行探針。TCP 探針可以用 blackbox_exporter 來做定期嘗試連接數(shù)據(jù)庫端口只要端口能連通、握手成功就證明服務(wù)入口是活的。SQL 探針則需要一個很小的探活腳本定時執(zhí)行select 1把返回結(jié)果作為指標(biāo)上報。這樣即使 Prometheus 從白盒指標(biāo)上看到了“重啟”的信號只要黑盒探針連續(xù)正常我們就有足夠的底氣判斷這是誤報而不是數(shù)據(jù)庫真的不可用。從監(jiān)控架構(gòu)設(shè)計上我更建議把數(shù)據(jù)庫監(jiān)控分成三層節(jié)點層負(fù)責(zé)主機(jī)資源與系統(tǒng)時間進(jìn)程層負(fù)責(zé) mysqld 或 postgres 進(jìn)程本身服務(wù)層負(fù)責(zé)客戶端視角的可用性。三層指標(biāo)互相印證單一層級的異常就不會輕易升級成高等級告警。關(guān)鍵數(shù)據(jù)庫實例的告警配置也應(yīng)該符合這個分層邏輯而不是把所有指標(biāo)塞進(jìn)同一條規(guī)則里讓一個采集器的抖動引發(fā)全局紅色警報。4.3 告警設(shè)計上的幾個務(wù)實建議最后聊幾個告警設(shè)計的務(wù)實原則。第一不要把“可能重啟”和“確認(rèn)重啟”混在同一級別只有擁有了數(shù)據(jù)庫內(nèi)部證據(jù)的告警才值得走 Critical 路由只有啟動時間戳變化的告警可以先走 Warning人工看一眼再決定是否升級。第二給每套 exporter 單獨建一條“exporter 進(jìn)程重啟”的規(guī)則。這條規(guī)則的指標(biāo)也是process_start_time_seconds但監(jiān)控對象要明確指向 exporter 自身。這樣數(shù)據(jù)庫重啟和采集器重啟可以被一眼區(qū)分不需要每次誤報的時候人工去翻日志。第三所有涉及重啟判斷的規(guī)則for子句至少設(shè)置 5 分鐘也就是至少覆蓋 15 到 20 個抓取周期。時有時無的抖動不值得觸發(fā)告警持續(xù)翻轉(zhuǎn)才值得關(guān)注。第四關(guān)于目標(biāo)實例的標(biāo)簽體系要規(guī)范。同一個數(shù)據(jù)庫的 node_exporter 和 mysqld_exporter 最好帶上相同的 instance 標(biāo)識這樣 PromQL 里做多指標(biāo)組合判斷時才能正確對齊。我見過不少規(guī)則因為 instance 標(biāo)簽不一致而無法生效明明該被抑制的誤報硬是漏了出來。還有一點容易被忽略數(shù)據(jù)庫的自動恢復(fù)能力越來越強(qiáng)很多數(shù)據(jù)庫在主進(jìn)程異常退出后會被守護(hù)進(jìn)程快速拉起業(yè)務(wù)無感但進(jìn)程啟動時間戳確實變了。這種時候監(jiān)控報一聲“重啟”其實是合理的信息不該被當(dāng)作誤報完全抹掉。所以我的建議是把這類告警降級為一個需要次日確認(rèn)的事件而不是直接 silence畢竟一次無人知曉的自動重啟往往意味著系統(tǒng)層或者數(shù)據(jù)庫層存在隱患值得花時間查明。我把上面這些規(guī)則在測試環(huán)境里模擬驗證過人為調(diào)時間不會觸發(fā)人為 kill exporter 不會觸發(fā)真正重啟 mysqld 會立刻報警能達(dá)到“謊報變少實報更準(zhǔn)”的效果。再遇到“數(shù)據(jù)庫沒動Prometheus 卻說起重啟了”我建議你先看一眼節(jié)點時間、再看一眼 up 指標(biāo)、最后看一眼數(shù)據(jù)庫內(nèi)部 uptime三個證據(jù)對不上就千萬別急著去重啟數(shù)據(jù)庫先把問題定位到采集鏈路和時間基準(zhǔn)上。這套排查順序幫我避免了好幾次對健康數(shù)據(jù)庫的“暴力修復(fù)”算是這條路上最值得分享的一點經(jīng)驗。