說實話我剛開始接觸運維那會兒最發(fā)愁的事情就是半夜被電話吵醒——業(yè)務(wù)掛了全靠用戶反饋等登錄服務(wù)器去看的時候日志都刷了好幾屏了連個因果關(guān)系都對不上。后來慢慢搭起了自己的監(jiān)控體系才算是把被動挨打變成了主動防御。這幾年做過的監(jiān)控方案不少但要說最順手、社區(qū)最活躍、資料最好找的組合還得是Linux環(huán)境下這套Prometheus加Grafana的雙人組。這篇文章我就把從零開始搭建這套可視化監(jiān)控平臺的完整過程捋一遍所有步驟都是我自己在生產(chǎn)環(huán)境實際跑過的參數(shù)怎么配、哪些坑不能踩都會交代清楚。不管你是剛?cè)腴T的運維新人還是想把手頭服務(wù)器納入統(tǒng)一監(jiān)控的老手這套流程都可以直接抄作業(yè)。1. 項目概述為什么偏偏是Prometheus和Grafana1.1 監(jiān)控平臺到底解決了什么問題服務(wù)器監(jiān)控這件事往小了說是看一眼CPU高不高、磁盤滿沒滿往大了說其實是兩件事預警和追蹤。預警好理解指標超過閾值提前報警別等用戶發(fā)現(xiàn)才補救。追蹤則更關(guān)鍵——當業(yè)務(wù)出現(xiàn)抖動你得能從歷史曲線里往回倒推還原出當時系統(tǒng)到底發(fā)生了什么。沒有監(jiān)控這些問題都只能靠猜而運維工作一旦進入“猜測模式”效率和口碑基本就是零。我自己最早用的監(jiān)控工具其實是腳本加定時任務(wù)寫個shell腳本每五分鐘跑一次記錄一下負載和內(nèi)存出問題再去翻文本日志。說實話這種方式在小規(guī)模場景下勉強能用但一旦機器數(shù)量超過十臺腳本管理就變成一場災難更別提需要臨時去對比多臺機器的同一時間點的狀態(tài)了。后來轉(zhuǎn)向集中式監(jiān)控平臺是必然選擇而Prometheus加上Grafana這套組合恰好把數(shù)據(jù)采集、存儲、查詢和可視化這幾塊全部覆蓋了。1.2 三件套的核心角色劃分這套方案里有幾個組件各自負責的活兒完全不同。Prometheus主監(jiān)控服務(wù)器負責抓取指標數(shù)據(jù)、存儲時間序列、執(zhí)行告警規(guī)則。它本身是自帶時序數(shù)據(jù)庫的所以不需要額外再接MySQL或者PostgreSQL來存監(jiān)控數(shù)據(jù)。Exporter被監(jiān)控機器上的數(shù)據(jù)采集代理會把操作系統(tǒng)層面的各種狀態(tài)CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等轉(zhuǎn)化成Prometheus能識別的指標格式然后等在一旁讓Prometheus來拉取。Grafana可視化前端連接Prometheus作為數(shù)據(jù)源把指標畫成面板、儀表盤、折線圖。告警功能它也能做但我通常把正式告警交給Prometheus的Alertmanager組件處理Grafana定位就是純粹的展示和交互。你要理解這套架構(gòu)的巧妙之處就記住一個詞拉模式。Prometheus是主動去各臺機器上拉取數(shù)據(jù)而不是各機器往上報送。這樣主監(jiān)控端完全掌控了采集節(jié)奏新增一臺機器只需要改一下Prometheus的配置文件就行不用去那臺機器上部署Agent端的上報腳本規(guī)模擴展非常順滑。1.3 和別家方案的對比它強在哪很多剛接觸監(jiān)控的朋友會問Zabbix不是也挺火的嗎為什么選Prometheus我用下來最大的感受是Prometheus的指標模型是多維度的。Zabbix的監(jiān)控項定義比較復雜每條數(shù)據(jù)要想清楚是浮點數(shù)還是字符型預處理怎么搞。而Prometheus里每個指標就是一組帶標簽的數(shù)值序列比如說統(tǒng)計所有機器的CPU使用率條件是某臺機器、某個CPU核心、某種模式用戶態(tài)還是內(nèi)核態(tài)直接在查詢語句里動態(tài)篩選就行靈活度完全不在一個級別。另外Prometheus的查詢語言PromQL上手之后是真的好用一條語句就能算出過去五分鐘的CPU平均使用率還能按不同標簽分組展示。再加上Grafana社區(qū)里現(xiàn)成的儀表盤模板特別多導入即用不用每次從空白畫起。整體來說這套方案的學習曲線確實存在但過了那層窗戶紙帶來的收益絕對對得起投入的時間。2. 環(huán)境準備開始之前的必要功課2.1 最小硬件配置參考先說配置很多人一上來就擔心Prometheus是不是特別吃資源。這里給一個我在實際部署中驗證過的參考范圍監(jiān)控服務(wù)器跑Prometheus和Grafana2核CPU、4GB內(nèi)存足夠應付幾百臺節(jié)點的規(guī)模磁盤看你的數(shù)據(jù)保留周期按每天約2GB估算就行。如果監(jiān)控的機器數(shù)量大或者指標特別密集再加配置也不遲。被監(jiān)控的Linux服務(wù)器跑Node Exporter只需要很小的開銷512MB內(nèi)存的老機器也能輕松跑起來CPU占用通常連1%都不到。我自己在不少低配云主機上驗證過完全不影響業(yè)務(wù)。有一說一如果你只是個人學習或者家里有幾臺服務(wù)器玩一下用一個普通的Linux虛擬機甚至樹莓派都能扛住這套監(jiān)控系統(tǒng)沒必要過度配置。2.2 操作系統(tǒng)版本的選擇這套方案對Linux發(fā)行版基本不挑CentOS系、Ubuntu系、Debian都行甚至國產(chǎn)Linux系統(tǒng)也可以正常跑因為Prometheus和Grafana都提供了通用的二進制包和systemd服務(wù)支持。不過有幾個小差異點要留意在Ubuntu和Debian上二進制包直接扔到/usr/local/bin就能跑systemd服務(wù)文件路徑在/etc/systemd/system/。在CentOS/RHEL系上如果開啟了SELinux需要注意端口和目錄權(quán)限的放行否則會出現(xiàn)服務(wù)起得來但數(shù)據(jù)寫不進去的詭異情況。如果是國產(chǎn)Linux環(huán)境架構(gòu)通常跟CentOS 7/8保持一致直接按CentOS那套來就好基本沒有兼容性問題。我在后面的演示里統(tǒng)一以Linux系統(tǒng)的通用操作為準同時標注兩邊的差異。示例環(huán)境我用的是Ubuntu 22.04CentOS用戶看差異說明就行。2.3 工具準備與前置條件在正式動手之前你需要保證下面這些是準備好的一臺能聯(lián)網(wǎng)的Linux服務(wù)器并且你擁有root權(quán)限或者能通過sudo切換。監(jiān)控軟件要寫系統(tǒng)目錄、注冊服務(wù)、開端口這一步省不掉。控制臺終端工具比如Windows自帶的Terminal或者Mac上的iTerm2你用Xshell這類工具遠程連接也行關(guān)鍵是能貼命令和看輸出。了解一點基礎(chǔ)的Linux常用命令tar解壓、vi編輯、systemctl管理服務(wù)。如果你完全沒碰過這些命令建議先去把Linux常用命令大全翻一遍再回來否則后面每一步都會卡殼。還有一點防火墻。很多朋友把軟件裝好了結(jié)果Prometheus啟動正常但Grafana連不上數(shù)據(jù)源十有八九就是防火墻把9090端口擋住了。Ubuntu上要用ufw放行端口CentOS上要用firewall-cmd操作這個細節(jié)后面排查章節(jié)我會重點再提。3. 動手安裝Prometheus服務(wù)器端3.1 獲取安裝包與目錄規(guī)劃Prometheus官方提供了預編譯的二進制包里面包含了主程序和一個默認配置示例不需要自己編譯源碼。到Prometheus官網(wǎng)的下載頁面找到linux-amd64的壓縮包復制下載鏈接后用wget拉取到服務(wù)器上。這里我分享一下我的目錄規(guī)劃習慣按這個結(jié)構(gòu)來后續(xù)升級和排查都方便# 創(chuàng)建專用目錄結(jié)構(gòu) mkdir -p /opt/prometheus/{bin,conf,data}把二進制包解壓后prometheus主程序和promtool工具都放到/opt/prometheus/bin/目錄下配置文件統(tǒng)一放在/opt/prometheus/conf/監(jiān)控數(shù)據(jù)落在/opt/prometheus/data/。這樣做的核心好處是Prometheus、Grafana、Exporter等各類組件配置路徑一目了然哪天要備份、要清理直接對著目錄來就行不會出現(xiàn)安裝包解壓在哪就在哪的混亂局面。3.2 編寫Prometheus主配置文件Prometheus的所有行為都靠一個YAML格式的配置來驅(qū)動。文件路徑可以自己定但內(nèi)容結(jié)構(gòu)是固定的。下面這是一個最小可用的配置global: scrape_interval: 15s # 采集頻率 evaluation_interval: 15s # 告警規(guī)則評估頻率 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]這段配置的意思非常直白每15秒對localhost:9090這個地址發(fā)起一次抓取請求抓取到的數(shù)據(jù)就是Prometheus自身的運行指標比如它收到了多少請求、處理了多少采樣點、內(nèi)存用了多少。剛裝完第一件事就是先把Prometheus自己管起來確認整個鏈路是通的再逐步擴展監(jiān)控目標。這個配置文件的每個字段都不是隨便寫的scrape_interval決定了數(shù)據(jù)的時間顆粒度設(shè)得越小數(shù)據(jù)越密集但同時存儲和查詢的壓力也會上去。對于絕大多數(shù)系統(tǒng)監(jiān)控場景15秒足夠了。告警規(guī)則的評估頻率也同理不需要太激進否則會頻繁產(chǎn)生無意義的重復告警。3.3 啟動Prometheus服務(wù)為了方便管理我用systemd把它注冊成系統(tǒng)服務(wù)這樣開機自動啟動掛了還能自動拉起。在/etc/systemd/system/prometheus.service寫入以下內(nèi)容[Unit] DescriptionPrometheus Server Afternetwork.target [Service] ExecStart/opt/prometheus/bin/prometheus \ --config.file/opt/prometheus/conf/prometheus.yml \ --storage.tsdb.path/opt/prometheus/data \ --web.listen-address0.0.0.0:9090 Restartalways Usernobody [Install] WantedBymulti-user.target有幾個參數(shù)值得展開說說。--storage.tsdb.path是時序數(shù)據(jù)落盤位置我單獨指定到data目錄防止和程序目錄混在一起默認情況下時序數(shù)據(jù)會保留15天這個是內(nèi)置策略如果你想存更久后續(xù)需要用--storage.tsdb.retention.time參數(shù)來調(diào)整--web.listen-address如果不設(shè)置默認就是監(jiān)聽0.0.0.0:9090但我習慣寫出來明確告訴別人這個服務(wù)端口是故意暴露出來的。保存文件后執(zhí)行systemctl daemon-reload systemctl enable --now prometheus systemctl status prometheus看到active (running)的狀態(tài)就說明Prometheus已經(jīng)跑起來了。這時候用瀏覽器訪問http://你的服務(wù)器IP:9090你會看到一個簡約的查詢界面這是Prometheus自帶的簡易Web UI。你可以在它的輸入框里敲一個查詢語句試試比如prometheus_tsdb_head_samples_appended_total回車就能看到實時數(shù)據(jù)。這個UI本身沒法和Grafana比但勝在方便適合臨時查數(shù)據(jù)用。4. 接入系統(tǒng)監(jiān)控指標Node Exporter4.1 Node Exporter是什么角色Prometheus本身只管采集真正去操作系統(tǒng)內(nèi)部讀取各種狀態(tài)數(shù)據(jù)的是Node Exporter。它是一個獨立的小程序運行在被監(jiān)控的機器上會自動收集內(nèi)核暴露出來的各項指標CPU使用率、內(nèi)存占用、磁盤空間、網(wǎng)絡(luò)流量、文件系統(tǒng)inode耗盡情況、系統(tǒng)負載等然后統(tǒng)一放在/metrics接口里等Prometheus來抓。Node Exporter確實能往前端可視化頁面?zhèn)鬟f數(shù)據(jù)這可行。但最常見的判斷是監(jiān)控基礎(chǔ)資源用Node Exporter監(jiān)控具體應用再上對應的exporter。比如MySQL數(shù)據(jù)庫配MySQL ExporterRedis配Redis ExporterNginx配Nginx Exporter。安裝Node Exporter的方式和Prometheus一模一樣也是下載二進制包解壓運行。為了管理方便我同樣是注冊成systemd服務(wù)。它的默認監(jiān)聽端口是9100啟動命令非常簡單# 同樣下載node_exporter的二進制包放到/opt/node_exporter/ /opt/node_exporter/node_exporter --web.listen-address:9100如果你擔心9100端口暴露在公網(wǎng)上不安全可以用--web.listen-address127.0.0.1:9100只監(jiān)聽本機回環(huán)地址然后讓Prometheus通過SSH隧道或者內(nèi)網(wǎng)地址來采集。不過一般情況下被監(jiān)控機器和監(jiān)控主機都在內(nèi)網(wǎng)環(huán)境里直接監(jiān)聽內(nèi)網(wǎng)IP即可。4.2 把節(jié)點加入Prometheus的抓取任務(wù)Node Exporter裝好后回到Prometheus主配置文件的scrape_configs里增加一段新的job配置讓它去抓取該機器的指標scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: linux-node static_configs: - targets: - 192.168.1.101:9100 # 替換為你需要監(jiān)控的機器IP這里解釋一下job_name的作用它是這批監(jiān)控目標的邏輯分組名稱后面在Grafana作圖時經(jīng)常要按job來篩選機器。同一個job下可以寫很多臺機器每行一個IP和端口Prometheus會并行去抓取。改完配置后重啟服務(wù)Prometheus那邊不需要任何額外的命令下次抓取周期到達時會自動發(fā)現(xiàn)新目標。重啟后可以在Prometheus的Web UI里打開Status - Targets頁面能看到每個job下的監(jiān)控目標列表狀態(tài)為UP就代表抓取成功。這個頁面是我日常排查的首選入口只要哪個目標狀態(tài)是DOWN多半就是網(wǎng)絡(luò)不通、端口被防火墻堵了或者Exporter進程掛了。4.3 用動作和腳本驗證采集鏈路確認Node Exporter的數(shù)據(jù)進了Prometheus之后可以在Prometheus查詢框里試試這些基礎(chǔ)指標判斷鏈路是否正常# 查看所有節(jié)點的CPU使用率百分比 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100 # 查看內(nèi)存使用率 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 # 查看根分區(qū)磁盤使用率 100 - (node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100這些查詢語句看起來復雜但拆開看就不難了。rate函數(shù)是PromQL中最常用的專門用來計算計數(shù)器指標的變化速率比如CPU在5分鐘內(nèi)從累計值變成了每秒的使用率。換成人話說這條語句就是在算“過去五分鐘CPU的空閑時間占比是多少然后拿100減掉得到實際使用率”。理解了這一層后面你寫任何查詢邏輯都會有思路。多提一嘴node_cpu_seconds_total這個名字它其實是一個累計值cgroup統(tǒng)計的是從開機到現(xiàn)在CPU在各種模式下總共消耗的秒數(shù)。直接查詢這個數(shù)你會看到一個不斷增長的大數(shù)值本身沒有太大意義用一個rate()函數(shù)把它轉(zhuǎn)成每秒速率再配合modeidle過濾出空閑模式才能算出來使用率。這是PromQL最重要的思維轉(zhuǎn)換——監(jiān)控的是速率不是累計值。5. 部署Grafana可視化展示的核心層5.1 安裝與首次啟動Grafana的安裝包在官網(wǎng)可以找到支持rpm、deb和二進制壓縮包幾種形式。我用的是二進制包方式因為內(nèi)部服務(wù)器經(jīng)常與互聯(lián)網(wǎng)物理隔離YUM或APT源不一定可用下載離線包分發(fā)是最常見的部署路徑。下載后同樣解壓把主程序和輔助文件放到/opt/grafana目錄wget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.4.2.linux-amd64.tar.gz tar -zxvf grafana-enterprise-10.4.2.linux-amd64.tar.gz mv grafana-10.4.2 /opt/grafanaGrafana默認讀取它自己目錄下的conf/defaults.ini獲取配置如果你需要自定義端口或數(shù)據(jù)目錄可以復制一份defaults.ini改名為custom.ini再修改。不過對于大部分初始部署保持默認配置足夠。啟動方式同樣用systemd托管好處是開機自啟動進程崩潰能自動拉起。跳過這個直接跑二進制也沒毛病但就沒有守護進程了。啟動后瀏覽器訪問http://服務(wù)器IP:3000首次打開會看到登錄頁面默認用戶名和密碼都是admin。系統(tǒng)會強制你修改初始密碼這里建議改成強密碼并妥善記錄因為Grafana賬號有數(shù)據(jù)源的配置權(quán)限一旦泄露不僅監(jiān)控數(shù)據(jù)暴露攻擊者還能通過Grafana的接口去探測內(nèi)網(wǎng)的IP和端口。5.2 配置Prometheus數(shù)據(jù)源登錄后進入的是Grafana的主界面?，F(xiàn)在服務(wù)端還是空殼必須先添加數(shù)據(jù)源告訴它往哪兒查數(shù)據(jù)。步驟如下鼠標移到左側(cè)邊欄的“齒輪”圖標上點擊“Connections”里的“Data sources”。點擊“Add data source”按鈕在列表里選擇“Prometheus”。在“URL”欄填寫Prometheus的地址例如http://192.168.1.100:9090。我這里特意說明一下如果你的瀏覽器和服務(wù)器不在同一臺機器IP不要寫localhost。點擊頁面底部的“Save test”看到綠色的“Successfully queried the Prometheus API”提示就代表連接成功。這一步是整套可視化鏈路中的勝負手我見過不少人卡在這里。最常見的坑是URL寫成了localhost:9090但瀏覽器打開的Grafana頁面來自遠程它拿localhost去連Prometheus自然連不上。說白了這個URL是Grafana服務(wù)器進程去訪問的地址不是你的瀏覽器去訪問的地址必須寫Grafana服務(wù)器能訪問到的Prometheus地址。然后是端口放行問題很多環(huán)境下Linux防火墻默認禁止跨主機的9090端口互訪測試數(shù)據(jù)源連接失敗時先用telnet IP 9090檢查一下網(wǎng)絡(luò)通不通再懷疑配置問題。5.3 快速導入現(xiàn)成的儀表盤模板Grafana最吸引人的一個地方就是社區(qū)里的儀表盤模板極其豐富不需要從零開始畫圖表。在Grafana官網(wǎng)的Dashboard頁面搜索“Node Exporter Full”或者“Linux Hosts”能找到很多現(xiàn)成的面板模板每個模板都有一個對應的ID編號。以我長期在用的模板1860為例操作步驟是在Grafana左側(cè)邊欄點擊“”號選擇“Import”。在“Import via dashboard ID”欄輸入1860點擊“Load”。下拉菜單里選擇之前配好的Prometheus數(shù)據(jù)源點擊“Import”。幾秒鐘后一個包含CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、進程等幾十個面板的完整儀表盤就出現(xiàn)了。導入成功后頁面展示的是一整套Linux主機狀態(tài)總覽從總覽頁能看到當前在線的主機數(shù)、平均負載、整體CPU趨勢、內(nèi)存使用柱狀圖等。需要注意這類模板默認可能只配置了一個主機變量如果你監(jiān)控了多臺機器右上角的下拉框里可以切換。模板畢竟是社區(qū)貢獻的個別面板可能出現(xiàn)無數(shù)據(jù)的情況多半是模板作者用的查詢語句里帶了一些固定標簽過濾條件你把查詢語句改一下就能適配自己的環(huán)境。這塊不想折騰的話也可以先學著自己從第一個空白面板畫起練熟了再考慮套模板節(jié)省時間。6. 親手配置第一個可視化面板6.1 從空白畫布開始自己動手畫面板是理解Grafana的核心環(huán)節(jié)。光會導入模板還不行模板是別人的思路出了詭異數(shù)據(jù)你根本不知道問題出在哪自己畫過一遍就知道每個數(shù)字是怎么算出來的了。個人建議剛接觸時一定要抽出半小時從空白面板開始做。新建面板的入口在左側(cè)“”號然后選“Dashboard”進入Dashboard編輯界面后點擊“Add”選“Visualization”。Grafana提供了豐富的圖表類型監(jiān)控場景下最常用的是時間序列圖也就是折線圖。面板右側(cè)編輯區(qū)分為幾個維度Data source選擇PrometheusQuery Type保持默認的Metrics然后關(guān)鍵的就是在輸入框里寫PromQL查詢語句。6.2 常用PromQL查詢解析我們用一個監(jiān)控CPU使用率的查詢來做演示在查詢編輯器里輸入100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100這時面板上應該立刻出現(xiàn)一條曲線橫軸是時間縱軸是百分比。如果你監(jiān)控了多臺機器Prometheus返回的每個序列會帶上機器實例的標簽圖表里就會顯示多條不同顏色的線。面板右上角還可以設(shè)置數(shù)據(jù)刷新周期比如每15秒自動拉取新數(shù)據(jù)頁面就像活的一樣在跳動。關(guān)于CPU這個查詢我再說一個容易忽略的點avg如果不加by(instance)會把所有CPU核心和所有機器混合求平均你看到的是一條總平均曲線。要區(qū)分開每臺機器和每個核心可以這樣寫avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)意思是按instance標簽分組后分別求每臺機器的平均使用率。同理如果你想看每個CPU核心的使用率by(cpu)就行。Grafana查詢框支持直接調(diào)整PromQL語句改完立刻能看到圖表變化多試幾次就掌握標簽篩選和聚合的玩法了。6.3 面板變量讓Dashboard支持多臺機器切換單臺機器畫好了接下來需要讓面板演示更靈活。Grafana支持定義模板變量簡單來說就是讓你在Dashboard頂部加一個下拉框點擊切換監(jiān)控目標所有關(guān)聯(lián)面板自動刷新展示對應數(shù)據(jù)。在Dashboard頁面點擊右上角的“Settings”圖標進入“Variables”標簽頁點擊“Add variable”。變量類型選擇“查詢”查詢語句可以寫成這樣它會把所有出現(xiàn)在特定標簽值里的機器名稱列出來label_values(node_boot_time_seconds, instance)添加完成后在面板的查詢語句里把原來寫死的機器IP替換成變量100 - avg(rate(node_cpu_seconds_total{instance$host}[5m])) * 100這樣切換變量值所有用到變量的面板會同時切換展示對象。這個功能用在幾十臺服務(wù)器組網(wǎng)監(jiān)控時尤其好使每個業(yè)務(wù)組建一組機器清單變量整個Dashboard就變成了一套可交互的業(yè)務(wù)監(jiān)控總覽。7. 告警推送走出可視化的最后一步7.1 Prometheus告警規(guī)則怎么寫監(jiān)控的最終目的不是畫圖是故障時能第一時間通知到人。Prometheus的告警體系分兩層規(guī)則層負責判斷“指標是否越界”通知層由Alertmanager承擔負責把告警發(fā)送到釘釘、郵件、企業(yè)微信等渠道。告警規(guī)則寫在獨立的規(guī)則文件里在Prometheus主配置文件中指定引用例如rule_files: - /opt/prometheus/rules/node_alerts.yml然后在node_alerts.yml里面定義具體的規(guī)則用一個最簡單的示例groups: - name: node_alerts rules: - alert: InstanceDown expr: up 0 for: 2m labels: severity: critical annotations: summary: Instance {{ $labels.instance }} is down description: Host is unreachable for more than 2 minutesup這個指標非常特殊它是Prometheus在每次抓取目標時自動生成的一個指標1代表成功0代表失敗。up 0的意思就是有監(jiān)控目標抓取失敗了。后面的for: 2m表示這個狀態(tài)要持續(xù)2分鐘才觸發(fā)告警這樣能有效防止偶發(fā)抖動造成的誤報。我遇到過的最奇葩問題是告警規(guī)則寫好了Prometheus的--alertmanager.url參數(shù)沒配置導致告警狀態(tài)能在UI上看到但根本不發(fā)送。告警狀態(tài)從Inactive到Pending再到Firing只在Prometheus內(nèi)部有記錄不推送到Alertmanager就等于白搭。7.2 Alertmanager的部署與通知配置Alertmanager是Prometheus生態(tài)里的告警集中器負責接收Prometheus推送來的告警事件然后根據(jù)路由規(guī)則分發(fā)給不同渠道。它的安裝包同樣是預編譯二進制下載解壓后配置一個alertmanager.yml。下面是一個配置了釘釘機器人通知的簡版配置route: group_by: [alertname] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://127.0.0.1:8060/dingtalk/webhook1這套流程配置完成后告警鏈路變成Prometheus判斷出InstanceDown狀態(tài)為Firing推給AlertmanagerAlertmanager再根據(jù)路由規(guī)則把消息POST到釘釘機器人的Webhook地址釘釘群里立刻跳出一條紅色告警。整個過程只需要記清楚規(guī)則層管“判斷”服務(wù)層管“發(fā)送”。實際生產(chǎn)中釘釘和飛書這類辦公軟件的群機器人配置都很簡單就是用自定義關(guān)鍵詞加一個Webhook地址。通知信息會帶著告警標題、級別、實例地址和觸發(fā)時間。如果你需要更豐富的交互可以后續(xù)再接一個簡單的中轉(zhuǎn)服務(wù)去格式化消息讓告警內(nèi)容里附帶當前的主機實時負載信息等。8. 生產(chǎn)環(huán)境的常見問題與排障手冊8.1 服務(wù)起不來或端口不對表現(xiàn)是systemctl status prometheus顯示服務(wù)未運行或者瀏覽器訪問不了9090端口。排查分三步走先看服務(wù)日志journalctl -u prometheus -f配置文件路徑寫錯了、目錄沒建、參數(shù)拼錯日志里都會有明確提示。再確認端口占用ss -lntp | grep 9090如果端口被占用多半是之前啟動過但沒徹底關(guān)掉kill進程后重新啟動即可。最后檢查防火墻我處理過太多案例服務(wù)明明監(jiān)聽正常但外部就是不通換臺機器telnet一下發(fā)現(xiàn)端口不通然后檢查firewalld或ufw規(guī)則放行915端口才結(jié)束。很多人卡在“服務(wù)明明起來了為什么訪問不了”就是防火墻這一關(guān)。攔路虎不是配置本身而是運維意識里總是默認防火墻沒作用其實現(xiàn)在的發(fā)行版默認都開防火墻主動放行端口是標準動作換個思路能少踩很多坑。8.2 Grafana面板沒有數(shù)據(jù)這一個問題能覆蓋十個不同原因排查時要有順序。先用Prometheus的查詢界面驗證數(shù)據(jù)源有沒有數(shù)據(jù)。打開Prometheus的Graph頁面輸入up執(zhí)行查詢。如果這里就查不到數(shù)據(jù)說明Prometheus側(cè)就有問題先檢查Targets頁面里監(jiān)控目標的狀態(tài)全部DOWN的話要么是Exporter沒起要么是網(wǎng)絡(luò)不通。如果Prometheus有數(shù)據(jù)但Grafana面板空白多半是查詢語句里帶了不存在的標簽名或者面板用了模板變量但變量沒有匹配到任何序列還有一種常見情況是面板時間范圍設(shè)置得不對選的是最近三天而數(shù)據(jù)昨天才開始采集進Prometheus。我經(jīng)歷過一次特別隱蔽的問題Grafana面板里部分圖表空著后來看到查詢語句里寫死了hostname~$host而我定義的主機名變量和節(jié)點上的hostname標簽值不一致。這種問題在導入模板時特別常見模板作者的標簽命名和你的環(huán)境不匹配需要檢查一下實際數(shù)據(jù)里的標簽列表對號入座。8.3 時間不同步導致數(shù)據(jù)錯亂Prometheus對監(jiān)控目標的時間戳非常敏感。如果被監(jiān)控機器的系統(tǒng)時間和監(jiān)控服務(wù)器差異過大常見表現(xiàn)為數(shù)據(jù)點丟失、突變、時好時壞。這是因為Prometheus在存儲序列時會檢測數(shù)據(jù)點的時間戳是否合理當前時間差超過一定范圍的數(shù)據(jù)可能會被拒絕寫入。這個問題的根治方案很簡單所有服務(wù)器統(tǒng)一啟用NTP時間同步。# Ubuntu timedatectl set-ntp true # CentOS yum install -y chrony systemctl enable --now chronyd時間同步之后定期用timedatectl status確認一下即可。我見過兩臺機器只差了五分鐘監(jiān)控曲線就開始出現(xiàn)奇怪的毛刺這個問題往往被忽視但它對數(shù)據(jù)可信度的影響極大。8.4 數(shù)據(jù)膨脹與磁盤用盡Prometheus存儲時間序列數(shù)據(jù)是按采樣點來算的指標越多、采集間隔越短、保留時間越長占用磁盤越多。尤其是Exporter側(cè)帶出了很多隱藏的高基數(shù)指標比如網(wǎng)絡(luò)連接狀態(tài)按客戶端IP拆分這種數(shù)據(jù)量很容易失控。這里規(guī)劃一個常規(guī)的容量預估假設(shè)你監(jiān)控50臺機器每臺機器大約產(chǎn)生3000個時間序列Prometheus每秒大概會接收1500個采樣點每天大約要消耗2GB磁盤空間。當然這只是個保守估算值真實情況取決于指標數(shù)量和數(shù)據(jù)基數(shù)。如果磁盤比較緊張可以在啟動參數(shù)中按需縮短保留周期--storage.tsdb.retention.time7d保留7天的數(shù)據(jù)對于大多數(shù)系統(tǒng)監(jiān)控場景夠用因為查詢歷史趨勢一般就看最近一周。結(jié)尾個人的一點實踐經(jīng)驗整套平臺從零到能用的過程如果操作順利一個小時以內(nèi)就能跑通。但想把它用出價值關(guān)鍵還在于日常的持續(xù)投入每接入一臺新業(yè)務(wù)就順手把對應的監(jiān)控指標梳理一遍每次線上出問題時都去復盤一下監(jiān)控數(shù)據(jù)里是否早就暴露出了蛛絲馬跡。這也是我寫這篇文章的主要愿望——幫大家把監(jiān)控體系的基礎(chǔ)打穩(wěn)省下的時間可以花在更有價值的事情上。根據(jù)我個人的使用習慣最后還建議你養(yǎng)成一個“小操作”每次修改過Prometheus配置或者新增面板之后都導出一份當前配置文件的備份用Git管理起來。別小看這一步生產(chǎn)環(huán)境出問題時你做的第一件事一定是回看“上一次可用的配置是什么”而不是原地猜測。祝大家的監(jiān)控曲線都長一條直線——平穩(wěn)、健康、不用半夜爬起來接告警電話。