簡介Prometheus作為開源監(jiān)控與報警系統(tǒng)是運維和DevOps工程師常用的時序數(shù)據(jù)監(jiān)控方案。這份學習資料面向具備基礎Linux操作能力的技術人員系統(tǒng)講解時間序列數(shù)據(jù)模型、PromQL查詢語法、Prometheus架構組成以及它與傳統(tǒng)數(shù)據(jù)庫和其他監(jiān)控系統(tǒng)的適用場景對比。內容從環(huán)境準備入手完整演示Prometheus服務安裝、配置prometheus.yml再通過node_exporter監(jiān)控遠程Linux主機通過mysqld_exporter采集MySQL性能指標并進一步集成Grafana繪制CPU負載、MySQL監(jiān)控圖表最后使用Alertmanager配置報警規(guī)則和通知策略形成一套可落地的監(jiān)控全鏈路。資源以單個PDF形式提供壓縮包僅2.95MB適合按章節(jié)循序漸進學習目前已吸引633人學習下載。學完可獨立完成監(jiān)控平臺部署、自定義指標定義、報警規(guī)則設置與儀表盤構建達成實時監(jiān)控和故障排查的目標。1. Prometheus 從入門到精通這套監(jiān)控體系到底在解決什么問題凌晨三點某公司 A 同學被電話叫醒線上接口超時率飆到 40%。打開監(jiān)控看板CPU 沒滿、內存沒滿、磁盤沒滿滿屏的綠色曲線就是找不到問題在哪——排查到天亮才發(fā)現(xiàn)是下游第三方 API 的 P99 延遲翻了一倍。這類“什么都正常但業(yè)務不正?！钡暮谙蛔訒r刻就是監(jiān)控體系的真正價值所在。Prometheus 是當前云原生場景下最被廣泛接受的監(jiān)控方案它以拉取方式采集指標把數(shù)據(jù)存成帶標簽的時間序列再用 PromQL 這套查詢語言把運行狀態(tài)變成可追溯的曲線和可觸發(fā)的告警。這篇文章適合運維、后端開發(fā)以及任何想用數(shù)據(jù)而不是直覺來定位故障的人。無論你是在容器環(huán)境還是傳統(tǒng)虛擬機讀完你都能獨立搭一套能用的監(jiān)控體系。2. 玩轉 Prometheus 先吃透數(shù)據(jù)模型從計數(shù)器到直方圖的選型邏輯Prometheus 的文檔很多但多數(shù)人第一步就卡在概念上什么叫樣本、什么叫標簽Counter 和 Gauge 有什么區(qū)別。不理解數(shù)據(jù)模型后面全是靠瞎試。這一章把 Prometheus 最核心的幾個機制講透后面的配置和查詢才不會發(fā)虛。2.1 拉取式采集為什么 Prometheus 用 pull 而不是 push傳統(tǒng)監(jiān)控系統(tǒng)多用 push 模式客戶端裝 agentagent 定時把數(shù)據(jù)推給服務端。推的模式看起來省事但有幾個根本問題服務端無法判斷“沒有數(shù)據(jù)”是因為客戶端掛了還是真的沒數(shù)據(jù)客戶端數(shù)量多了以后服務端要分別承擔流量峰值擴容困難數(shù)據(jù)在傳輸過程中沒有統(tǒng)一的采樣節(jié)奏時間戳對齊很費勁。Prometheus 選擇了 pull 模式服務端按 scrape_interval 定時到每個 target 的 /metrics 端口里抓取指標。這樣做的直接好處是抓取目標的狀態(tài)是標準的——成功、失敗、超時都是服務端主動探測出來的采集節(jié)奏由服務端統(tǒng)一控制target 只要暴露一個 HTTP 端口就能被任何 Prometheus 抓取。這也是為什么云原生環(huán)境下它比老牌監(jiān)控系統(tǒng)更順手。但 pull 模式對“生命周期很短的任務”有天然缺陷一個批處理任務可能跑 30 秒就退出了Prometheus 還沒等到下一次抓取。常見的做法是這類短命任務額外推一個 PushgatewayPushgateway 是一個持有指標快照的緩存層Prometheus 再從它那里拉。注意Pushgateway 只適合“臨時任務指標匯總”不適合把業(yè)務所有指標都塞進去否則它會變成一個故障點。2.2 四種指標類型Counter、Gauge、Histogram、Summary接口暴露出來的每條指標都有類型聲明。選錯類型是新手最容易犯的錯比如用 Gauge 存累計請求數(shù)那 rate 算出來會很難看。先記結論類型特點典型用法Counter只增不減請求總數(shù)、錯誤總數(shù)、字節(jié)數(shù)Gauge可增可減內存用量、連接數(shù)、溫度Histogram累計桶計數(shù)請求耗時分布服務端可求分位數(shù)Summary客戶端預計算分位數(shù)舊系統(tǒng)兼容或需要精確分位時Counter 之所以叫 Counter是為了配合 rate()只看絕對值沒有意義絕對值除以時間才是每秒速率。Gauge 描述當前狀態(tài)直接讀數(shù)不要對它做 increase。Histogram 和 Summary 都用于“分布”類指標區(qū)別在分位數(shù)在哪一側計算——Histogram 在服務端算Summary 在客戶端算。推薦優(yōu)先使用 Histogram因為你可以在 PromQL 里隨意調整分位值Summary 則是一錘子買賣必須提前在埋點里定死。一個實際指標端點的樣子可以用 curl 看curl -s http://127.0.0.1:9100/metrics | \ grep -E ^node_cpu_seconds_total|^node_memory_MemAvailable_bytes | head -n 5返回的每一行結構是指標名、用花括號包圍的標簽、空格后的值。node_cpu_seconds_total 這個 Counter 后面帶著 cpu 和 mode 兩個標簽分別代表核序號和 CPU 工作模式值表示該模式下累計的 CPU 秒數(shù)。看到 _total 后綴基本可以斷定它是 Counter這是社區(qū)約定。2.3 標簽是它的靈魂job、instance 與自定義標簽怎么命名同一臺機器上的 node_cpu_seconds_total 之所以有多條序列就是因為標簽值不同。Prometheus 的多維模型意味著同一個指標 一組不同的標簽值 一條獨立的時間序列。所有查詢都是在這個多維空間里做切片。抓取配置里自帶兩個內建標簽job 是配置里的 job_nameinstance 是 targets 的地址加端口。比如 jobnodeinstance192.168.1.10:9100。自定義標簽用 static_configs 里的 labels 字段加scrape_configs: - job_name: node static_configs: - targets: [192.168.1.10:9100] labels: env: prod role: web這段配置的效果是這個 target 抓回來的每個序列都會帶 envprod、roleweb 這兩個固定標簽。標簽命名的原則是標簽值的變化頻率越低越好。env、zone、role 這種固定值是理想標簽Pod 名稱、容器 IP、用戶 ID 這種高頻變化的字段如果進了標簽序列數(shù)量會爆發(fā)式增長直接撐爆內存這個問題在第 5 章單獨展開。2.4 本地存儲機制block、壓縮與保留策略Prometheus 不是通用時序數(shù)據(jù)庫它的本地存儲是按 2 小時為一個 block 寫的后臺再做 compaction 壓縮。默認保留時間是 15 天超過保留期的 block 會被刪除。這個設計決定了它的定位為近期排障和告警而生的短周期監(jiān)控不適合做跨月趨勢分析和審計留存。相關參數(shù)在啟動里能看到./prometheus \ --storage.tsdb.path/var/lib/prometheus \ --storage.tsdb.retention.time30dstorage.tsdb.path 指定數(shù)據(jù)目錄storage.tsdb.retention.time 寫成 30d 表示保留 30 天。我一般會在測試環(huán)境用 7d 省磁盤生產(chǎn)環(huán)境按合規(guī)要求設 15d 或 30d。想長期留數(shù)年就得把遠程存儲或者 Thanos 這類邊車方案引入進來讓歷史 block 上傳到對象存儲。這個復雜度不是入門階段要考慮的但你要知道邊界在哪。3. 本地跑通 Prometheus 的最小部署從下載到第一個查詢概念到這兒差不多了下面直接動手。這一章的最終目標在你的 Linux 機器上跑起一個 Prometheus抓取機器自身的指標然后用 curl 驗證一條真實查詢。整個過程不需要 Docker、不需要容器用最小依賴把鏈路打通。3.1 二進制安裝與 systemd 托管常見做法是直接下載官方發(fā)布的二進制包不用編譯不依賴額外運行時。到官方下載站的 release 頁面拿當前最新穩(wěn)定版的 linux-amd64 包文件名形如 prometheus-2.x.x.linux-amd64.tar.gz。解壓后目錄里自帶 prometheus 和 promtool 兩個二進制tar xzf prometheus-2.x.x.linux-amd64.tar.gz cd prometheus-2.x.x.linux-amd64 ./prometheus --versionprometheus 是主服務promtool 是命令行校驗工具配置寫完之后拿它驗證語法很有用。下載的版本號按你實際拿到的文件替換下文其他地方同理。把服務交給 systemd 管理便于開機自啟和崩潰拉起。先建運行用戶和數(shù)據(jù)目錄sudo useradd --no-create-home --shell /bin/false prometheus sudo mkdir -p /etc/prometheus /var/lib/prometheus sudo cp prometheus promtool /usr/local/bin/然后寫 systemd 單元文件配置文件路徑指定到 /etc/prometheus/prometheus.yml[Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/bin/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus \ --storage.tsdb.retention.time30d \ --web.enable-lifecycle Restartalways [Install] WantedBymulti-user.targetUser 和 Group 指定服務降權運行避免 Prometheus 以 root 身份跑。storage.tsdb.path 是數(shù)據(jù)目錄務必保證 prometheus 用戶對它可寫。Restartalways 保證進程不因意外退出而失聯(lián)。Typesimple 表示 ExecStart 啟動的進程本身就是主進程。--web.enable-lifecycle 是為了后面能通過接口熱加載配置不加的話配置改動必須重啟進程。啟動sudo systemctl daemon-reload sudo systemctl enable --now prometheus systemctl status prometheus看到 active (running) 說明服務起來了瀏覽器訪問服務器 9090 端口就能看到自帶的 UI。3.2 第一份 prometheus.yml抓取間隔、規(guī)則加載與 storage 配置Prometheus 的一切行為都從這份 YAML 開始。一個能工作的最小配置長這樣global: scrape_interval: 15s evaluation_interval: 15s scrape_timeout: 10s rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]global 里的三個參數(shù)是全局默認值scrape_interval 表示多久抓一次目標evaluation_interval 表示多久評估一次告警規(guī)則scrape_timeout 表示單次抓取允許的最大耗時。三者之間有個硬約束scrape_timeout 必須小于 scrape_interval如果抓一次要 8 秒、但 5 秒就再抓請求會重疊產(chǎn)生一堆超時誤報。rule_files 指向告警規(guī)則的存放路徑現(xiàn)在還沒有規(guī)則文件留空也會正常啟動。scrape_configs 里定義的 job_nameprometheus 是讓 Prometheus 抓自己暴露的指標targets 寫 localhost:9090 就是它的 /metrics 地址。配置改完之后用 promtool 校驗promtool check config /etc/prometheus/prometheus.yml輸出 SUCCESS 說明語法通過。配置文件改動后需要重載才生效不用重啟進程因為 3.1 里已經(jīng)開了 lifecycle 開關curl -X POST http://127.0.0.1:9090/-/reload注意 9090 端口的默認監(jiān)聽地址是 0.0.0.0生產(chǎn)環(huán)境一定用防火墻限制訪問來源或者在前面加一層帶認證的反向代理否則任何人都能查你的監(jiān)控數(shù)據(jù)。3.3 掛載 Node Exporter監(jiān)控一臺普通 Linux 機器Prometheus 只負責拉取指標從哪來取決于被監(jiān)控對象。對 Linux 服務器社區(qū)標準做法是跑一個 node_exporter它把 CPU、內存、磁盤、網(wǎng)絡等系統(tǒng)指標暴露在 9100 端口。同樣從官方下載站拿 node_exporter 的 linux-amd64 包tar xzf node_exporter-1.x.x.linux-amd64.tar.gz cd node_exporter-1.x.x.linux-amd64 sudo cp node_exporter /usr/local/bin/ node_exporter --web.listen-address:9100 同樣可以把它寫進 systemd 管理此處先用后臺方式驗證。起來之后用 curl 看一眼指標端點curl http://127.0.0.1:9100/metrics | head -n 20能看到一堆 node_ 開頭的指標就說明 exporter 工作正常。此時回到 Prometheus 配置文件把 target 加進去scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node static_configs: - targets: [192.168.1.10:9100] labels: role: web重載之后Web UI 里 Status - Targets 頁面會多出一個 node 任務狀態(tài)為 UP 表示抓取鏈路通暢。labels 里的 role 是自定義標簽加它的目的是在查詢時能按業(yè)務角色切分。3.4 用 curl 做第一次手動查詢看一眼 /api/v1/queryWeb UI 里的 Graph 面板本質就是發(fā) HTTP 請求到查詢 API。直接 curl 能更清楚看到數(shù)據(jù)如何返回curl -G http://127.0.0.1:9090/api/v1/query \ --data-urlencode queryup返回的 JSON 會有 status、data.resultType 和 data.result。result 數(shù)組里每項代表一條序列up 的值是 1 表示上一次抓取成功。Prometheus 內置的 up 指標是自檢探活最常用的每個 target 都有。再查一個真實指標curl -G http://127.0.0.1:9090/api/v1/query \ --data-urlencode querynode_memory_MemAvailable_bytes這時候返回結果里帶著 instance 和 job 標簽值是該機當前可用內存字節(jié)數(shù)。查詢 API 是 Prometheus 對外的數(shù)據(jù)接口Grafana、自研平臺、命令行都是通過它拿數(shù)據(jù)的理解 curl 的行為等于理解了所有下游工具的調用方式。4. PromQL 進階rate、histogram_quantile 與聚合的正確打開方式PromQL 是 Prometheus 的查詢語言也是“玩轉”這個詞里含金量最高的部分?；A查詢照葫蘆畫瓢不難難在窗口、速率、分位、聚合這些概念之間存在大量邊界條件。這一章把最常見也最容易出錯的四個操作講透。4.1 四類選擇器匹配字符串的四個符號一條完整的 PromQL 由指標名、標簽選擇器和可選的函數(shù)/運算組成。標簽選擇器有四種寫法http_requests_total{jobapi} http_requests_total{job!api} http_requests_total{job~api|web} http_requests_total{job!~api|web}第一行是精確匹配第二行是不等于第三行是正則匹配第四行是不匹配正則。正則表達式用 RE2 語法不是 PCRE所以像 ? 這類需要回溯的斷言是不能用的。選擇器寫的標簽越多篩選條件越收斂。注意一個陷阱PromQL 里 {job} 能匹配到?jīng)]有該標簽的序列但 {job!} 不會排除沒有該標簽的序列——它只在有 job 標簽的序列里過濾。兩套語義不一致寫排除條件時習慣先確認目標序列確實帶著這些標簽。4.2 速率計算的三條公式rate、irate 和 increaseCounter 型指標本身是累計值用它排查問題必須轉成速率。三個函數(shù)是等價的入口但行為差異很大rate(node_cpu_seconds_total{modeuser}[5m]) irate(node_cpu_seconds_total{modeuser}[5m]) increase(http_requests_total[5m])rate 計算窗口內每秒平均增速取窗口第一個樣本和最后一個樣本差值除以兩者時間差。irate 只看窗口最后的兩個樣本反映瞬時尖峰曲線更敏感、也更毛糙。increase 返回窗口內的總增量用于看“這 5 分鐘漲了多少”這類問題。窗口參數(shù) [5m] 不是隨便填的窗口至少要是抓取間隔的兩倍否則窗口里可能只有一兩個樣本rate 算出來要么是 0 要么是殘值。我個人的習慣是15s 抓一次就用 5m看長期趨勢用 rate看突發(fā)尖峰用 irateincrease 只在要和總量對比時用。4.3 直方圖分位數(shù)histogram_quantile 的參數(shù)與坑耗時類指標是排查性能問題的關鍵用的就是 Histogram。它把觀測值按 bucket 累計比如http_request_duration_seconds_bucket{le0.1} 3521 http_request_duration_seconds_bucket{le0.5} 5600 http_request_duration_seconds_bucket{le1} 7200 http_request_duration_seconds_bucket{leInf} 9800le 標簽是“小于等于”的邊界數(shù)值是累計計數(shù)耗時 0.1 秒以內的請求 3521 個1 秒以內的 7200 個。求 P99 的標準寫法是histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))里面那層 rate 先把累計計數(shù)變成每秒增量sum by (le) 按 le 標簽聚合所有實例維度外層 histogram_quantile 在 bucket 之間做線性插值。三個細節(jié)必須記住第一聚合時只能保留 le其他維度都要用 by 規(guī)則聚合掉或過濾掉不然插值會錯第二bucket 的粒度決定分位數(shù)的精度le 跨度越大P99 的誤差越大第三不要對 Histogram 用 increase因為分位數(shù)需要的是速率分布總量沒有意義。4.4 聚合與維度控制CPU 使用率的正確寫法聚合函數(shù)控制著多序列如何合并。最常用的帶上 by 保留維度sum(rate(node_cpu_seconds_total[5m])) by (instance) avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100第一行按 instance 分組計算整機 CPU 每秒使用速率第二行算的是空閑率。要 CPU 使用率取空閑率的補集100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100這個公式看似繞但它是社區(qū)里對 CPU 使用率最穩(wěn)定的定義之一。不能直接對 user mode 求和因為 mode 還有 system、iowait、steal 等好幾種只取 user 會漏掉一部分負載。寫內存使用率也有類似的套路100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)用空閑內存的補集避免被 buffer/cache 干擾。聚合維度的選擇和指標語義強相關這部分的判斷經(jīng)驗比語法本身更值錢建議每個團隊都沉淀一套自己的常用指標字典。5. Prometheus 實戰(zhàn)避坑5 個讓我熬夜的血淚教訓精確踩坑比順暢教程更救命。這里列的是我在多個環(huán)境中真實遇到的問題每條都按現(xiàn)象、原因、解決方案展開你遇到同類問題可以直接照著走。5.1 現(xiàn)象targets 一直 UP查詢卻沒有最近數(shù)據(jù)某個環(huán)境里界面顯示所有 target 都是 UP但曲線時間軸越往前越近最新數(shù)據(jù)停在幾分鐘前再往后就沒點了?？雌饋硐瘛皝G了數(shù)據(jù)”。原因是虛擬機所在宿主機和監(jiān)控服務器的時鐘不同步node_exporter 上報的樣本時間戳比 Prometheus 本地時鐘慢了幾分鐘。Prometheus 在寫入時會對時間戳做合理性判斷過于陳舊的樣本直接拒絕。解決給所有被監(jiān)控節(jié)點統(tǒng)一部署 NTP 同步配合 chrony 或 systemd-timesyncd 都可以。同步完成后重啟 exporter讓新樣本帶正確的時間戳。這類問題排查時最容易迷惑的是“指標還在但圖形在漂”先查兩端 date 命令輸出10 秒就能確認。5.2 現(xiàn)象increase 在服務重啟后數(shù)值明顯失真某服務每隔幾天重啟一次increase(http_requests_total[5m]) 在重啟時刻出現(xiàn)一個異常的尖峰或斷崖告警也跟著誤報。原因是 Counter 在進程重啟時歸零。increase 計算的是窗口內最后一個樣本減第一個樣本如果重啟發(fā)生在窗口中間兩側的樣本來自新舊兩個進程周期差值把正常增長和歸零突變混在一起算出來結果必然失真。解決不要在重啟場景里直接用 increase 做告警閾值先看 up 是否發(fā)生過翻轉再決定要不要信這個增量。也可以改用來對比兩個時間點的總量差值或者把重啟事件計入部署流程里的告警屏蔽窗口。一句話rate 和 increase 的前提是 Counter 連續(xù)遞增進程一旦重啟這個前提就破了你需要自己補條件。5.3 現(xiàn)象up 1 但業(yè)務已經(jīng)連續(xù)報錯Prometheus 自帶的 up 指標表示“抓取到了指標”不表示“服務健康”。很多團隊的第一條告警就是 up 0結果某次接口全面 5xxup 卻依然全綠。原因是 exporter 的探活停留在網(wǎng)絡層面node_exporter 能抓到數(shù)據(jù)說明操作系統(tǒng)活著、9100 端口通至于業(yè)務進程是不是在返回錯誤up 根本不關心。它是基礎設施探活不是業(yè)務健康探活。解決業(yè)務健康要單獨埋點。HTTP 服務用 blackbox_exporter 做真實探活或者用業(yè)務自身暴露的指標比如 http_requests_total{code5xx} 的速率超過閾值時告警。把 up 當“基礎設施在線”看把業(yè)務指標當“用戶體感在線”看兩者組合才是完整的健康判斷。5.4 現(xiàn)象Prometheus 內存一路攀升頻繁 OOM某次上線新業(yè)務后Prometheus 進程的 RSS 曲線肉眼可見地往上走幾天后 OOM 被殺重啟后繼續(xù)攀升。原因是標簽基數(shù)爆炸。某個客戶端埋點把請求里的請求 ID 或者用戶 ID 寫成了標簽值這會導致每來一個 ID 就新增一條時間序列。10 個 ID 沒問題1 萬個 ID 內存就崩了。Prometheus 的時序是按標簽組合存儲的組合數(shù)等于各標簽值數(shù)量的笛卡爾積增長是指數(shù)級的。解決先看當前序列總量prometheus_tsdb_head_series如果數(shù)值遠超預期去收集端把高基數(shù)標簽去掉。已經(jīng)在內存里的數(shù)據(jù)用 metric_relabel_configs 在抓取時把標簽丟棄scrape_configs: - job_name: problem_app metric_relabel_configs: - source_labels: [request_id] regex: . action: labeldrop注意relabel 只控制寫入 Prometheus 的數(shù)據(jù)源頭埋點不改的話流量早晚還會漲回來。更徹底的方案是把這類標簽從指標設計階段就刪除或者用日志系統(tǒng)去承載這類高基數(shù)維度。5.5 現(xiàn)象抓取超時exporter 數(shù)據(jù)間歇性空白某個 exporter 產(chǎn)生的指標特別多15 秒的間隔里經(jīng)常抓不完目標一會 UP 一會 DOWN曲線斷斷續(xù)續(xù)。原因是 scrape_timeout 太短。注意 Prometheus 的超時邏輯抓取開始后如果超過 scrape_timeout 還沒返回完這次抓取會被標記失敗下一次間隔再試所以圖形上表現(xiàn)為“漏點”。默認 10s對于大 exporter 來說確實不夠。解決拆開兩個參數(shù)——拉長抓取間隔、增大超時但超時必須小于間隔scrape_configs: - job_name: big_exporter scrape_interval: 60s scrape_timeout: 30s也可以檢查 exporter 自身是不是花了太多時間在計算指標上例如 node_exporter 的某些 collector 可以按需關閉。參數(shù)調節(jié)本質是拿時效性換完整性到底多長合適要看你對數(shù)據(jù)粒度還是數(shù)據(jù)連續(xù)性的優(yōu)先級更高。6. 從查詢到告警Prometheus 的進階用法與自檢習慣把數(shù)據(jù)查出來是一回事讓監(jiān)控自動找你就是另一回事。最后這一章補上告警閉環(huán)然后給你一份自檢清單把這套體系真正變成日常依賴的“值班伙伴”。6.1 告警規(guī)則與 Alertmanager兩個組件各管一段告警規(guī)則寫在 Prometheus 的 rule_files 里Prometheus 按 evaluation_interval 周期評估規(guī)則表達式觸發(fā)后把告警發(fā)給 Alertmanager。Alertmanager 負責去重、分組、路由和通知渠道。先在 rules 目錄建一個 node_alerts.ymlgroups: - name: node_alerts rules: - alert: NodeDown expr: up{jobnode} 0 for: 2m labels: severity: critical annotations: summary: instance {{ $labels.instance }} downexpr 是觸發(fā)條件for: 2m 表示條件持續(xù) 2 分鐘才激活避免瞬時抖動誤報。labels 和 annotations 是告警的元數(shù)據(jù)和可讀描述Alertmanager 里會按 labels 做路由。Alertmanager 的配置負責把告警發(fā)出去一個最小配置長這樣route: receiver: default receivers: - name: default webhook_configs: - url: http://127.0.0.1:8080/alertwebhook 通道是為了對接企業(yè)內部的消息平臺。生產(chǎn)環(huán)境一定要配置分組規(guī)則把同服務多實例的告警合并成一條否則大故障時告警轟炸是必然的。6.2 長期可用的自檢清單監(jiān)控系統(tǒng)自己也會生病我習慣每周跑一遍下面的檢查成本不到十分鐘檢查項方法關注點抓取失敗率up 0 的 target 數(shù)不應持續(xù)存在抓取耗時max(scrape_duration_seconds)是否逼近 scrape_timeout時間戳延遲timestamp(up) 與當前時間差不應持續(xù)增長序列總量prometheus_tsdb_head_series和上周對比是否翻倍規(guī)則執(zhí)行失敗prometheus_rule_evaluation_failures_total必須為 0磁盤使用tsdb 目錄占用率按 retention 估算增長這套清單不解決所有問題但能擋住大部分“監(jiān)控沒報警才知道監(jiān)控掛了”的尷尬。從我自己的經(jīng)驗講每次出問題后回來反思最后 80% 都落在指標設計不嚴謹或告警閾值沒對齊上Prometheus 本身反而很少是根源。把基礎打牢比追新工具值錢得多。希望幫到你。本文還有配套的精品資源點擊獲取