做運維這些年我越來越覺得“監(jiān)控”是件挺反直覺的事情你搭它的時候總覺得“沒多大必要”等線上真的出了事故、翻日志翻到懷疑人生的時候又開始后悔當(dāng)時怎么沒把指標(biāo)體系建得再細(xì)一點。尤其是Linux服務(wù)器一多CPU飆了、磁盤滿了、進(jìn)程悄悄掛了這種事靠人肉盯根本盯不過來。所以我想把最近在用的這套方案——夜鶯監(jiān)控加categraf采集器——從頭到尾梳理一遍包括部署、配置、常見問題排查和那些文檔里不太會寫的坑。如果你正準(zhǔn)備給團隊搭一套能用、不折騰、還看得住事的監(jiān)控系統(tǒng)這篇文章應(yīng)該能讓你少走不少彎路。這套組合的核心邏輯其實很簡單categraf負(fù)責(zé)從各個Linux節(jié)點上采數(shù)據(jù)夜鶯監(jiān)控Nightingale負(fù)責(zé)存儲、展示、告警。categraf是夜鶯生態(tài)下的采集器但它本身也支持Prometheus協(xié)議、influxdb協(xié)議采集能力并不局限于夜鶯自家設(shè)備。你完全可以把它理解成一個更現(xiàn)代化的Telegraf或者node_exporter只不過配置方式、插件管理、數(shù)據(jù)上報方式都做了很多打磨。整條鏈路跑起來之后服務(wù)器的基礎(chǔ)指標(biāo)、中間件指標(biāo)、業(yè)務(wù)自定義指標(biāo)都能統(tǒng)一收口再配上告警規(guī)則誰出了問題一目了然。這篇文章主要面向兩類人一是剛接觸Linux系統(tǒng)監(jiān)控、想從零搭一套監(jiān)控體系的運維新人二是已經(jīng)在用Prometheus或者其他采集器、但覺得維護成本偏高、想換一個更順手方案的進(jìn)階玩家。我會把架構(gòu)思路、安裝步驟、配置項含義、故障排查方法都講清楚盡量做到你是照著操作就能跑起來的程度。1. 監(jiān)控體系總體設(shè)計與組件分工在動手部署之前先把整體架構(gòu)捋清楚后面排錯才能有方向。很多人搭監(jiān)控喜歡“先裝上再說”裝上之后指標(biāo)出不來就懵了其實就是沒理解數(shù)據(jù)到底是怎么流動的。1.1 夜鶯監(jiān)控能做什么、和Prometheus有什么關(guān)系夜鶯監(jiān)控從產(chǎn)品形態(tài)上看是一個完整的可觀測性平臺覆蓋了指標(biāo)采集、數(shù)據(jù)存儲、可視化、告警通知這幾大塊。它早期版本直接兼容Prometheus的配置和概念比如你可以把Prometheus里的scrape_config遷過來也可以用PromQL查詢數(shù)據(jù)這就讓很多原本在Prometheus生態(tài)里做監(jiān)控的團隊遷移成本很低。在v5之后的版本里夜鶯逐步做了自己的數(shù)據(jù)模型和告警引擎但核心思路還是“類Prometheus”指標(biāo)由采集器抓取或推送存儲進(jìn)時序數(shù)據(jù)庫再通過統(tǒng)一的查詢語言做展示和告警。和直接用Prometheus相比夜鶯的優(yōu)勢主要體現(xiàn)在兩端一是告警管理更貼近國內(nèi)團隊的使用習(xí)慣內(nèi)置了值班、升級、靜默、聚合等功能二是有原生的大盤管理和用戶權(quán)限體系多人協(xié)作時不用自己再造一套。而且夜鶯的部署方式是“中心化”的服務(wù)端只需要部署一套所有agent上報到同一套后端規(guī)模上來之后維護成本不會線性增長。當(dāng)然這不是說夜鶯能完全替代Prometheus如果你現(xiàn)有的生態(tài)里已經(jīng)大量使用Prometheus Operator、各類exporter保留Prometheus做數(shù)據(jù)采集把夜鶯作為統(tǒng)一展示和告警入口也是常見做法。1.2 categraf在整個鏈路里的位置categraf在鏈路里扮演的角色簡單說就是“數(shù)據(jù)入口”。它跑在每一臺需要監(jiān)控的Linux機器上負(fù)責(zé)采集CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、進(jìn)程、日志等指標(biāo)然后通過HTTP上報給中心端的時序數(shù)據(jù)庫。和傳統(tǒng)Telegraf相比categraf最讓我喜歡的一點是它原生支持多種上報格式既能以Prometheus格式暴露metrics端點又能直接推送到VictoriaMetrics、M3DB這類存儲還能兼容夜鶯自己的數(shù)據(jù)格式。這樣設(shè)計的好處是你不需要在采集層做格式轉(zhuǎn)換下游怎么方便就怎么接。categraf的插件體系也值得一提。它內(nèi)置了大量input插件像cpu、mem、disk、net、system、procstat、exec等都在其中。每個插件對應(yīng)一個配置文件放在conf目錄下的input.xxx文件夾里默認(rèn)都帶了一份示例配置你只需要按需打開或修改。這種“一個插件一個目錄”的設(shè)計比Telegraf那種集中式配置要直觀不少排查問題的時候直接看對應(yīng)插件的conf文件就行。1.3 這套組合適合什么場景我不是說所有監(jiān)控需求都應(yīng)該無腦上這一套但它確實很適合幾類典型場景。第一種是中小團隊機器規(guī)模在幾十到幾百臺之間需要一個輕量、不依賴太多外部組件的監(jiān)控方案。第二種是已經(jīng)用了Prometheus、但告警和看盤管理比較痛苦、想讓開發(fā)和運維都能方便地看到系統(tǒng)狀態(tài)的團隊。第三種是想把“采集、存儲、告警、通知”完全打通不想在自己拼一堆開源組件之間做膠水層的團隊。如果你們團隊本身已經(jīng)有成熟的Prometheus Grafana Alertmanager鏈路而且運行得很穩(wěn)定那其實沒有必要強行切換到夜鶯。但如果你正在選型或者對現(xiàn)狀不滿意夜鶯 categraf這套組合在易用性和完整度上確實是目前國內(nèi)開源方案里很能打的一個。2. 環(huán)境準(zhǔn)備與部署安裝好了架構(gòu)層面聊清楚了下面進(jìn)入實操環(huán)節(jié)。這部分我會按照服務(wù)端和客戶端分開講服務(wù)端負(fù)責(zé)存儲和展示客戶端就是categraf采集器。2.1 服務(wù)端準(zhǔn)備MySQL、Redis、VictoriaMetrics、n9e夜鶯服務(wù)端依賴幾個組件MySQL存元數(shù)據(jù)、Redis做緩存、VictoriaMetrics或M3DB等存時序數(shù)據(jù)最后是夜鶯自身進(jìn)程n9e。我這里以二進(jìn)制部署為例因為這種方式最容易理解各組件之間的關(guān)系排查問題也更方便。首先是MySQL。版本建議選5.7或8.0裝好之后創(chuàng)建一個獨立的庫比如數(shù)據(jù)庫名可以讓夜鶯初始化腳本自動建也可以手動建好再導(dǎo)入。不論哪種方式都要保證字符集是utf8mb4不然有些告警內(nèi)容或標(biāo)簽值會報編碼錯誤。Redis用默認(rèn)配置即可主要是給告警引擎和session用的如果服務(wù)端和Redis不在同一臺機器記得bind地址要改成內(nèi)網(wǎng)IP或者單獨配置訪問控制。然后是VictoriaMetrics。這個組件我強烈建議單獨部署不要和夜鶯進(jìn)程混在一起跑因為時序數(shù)據(jù)的寫入量比較大混在一起容易互相影響。VictoriaMetrics的單機版安裝非常簡單解壓后執(zhí)行帶storageDataPath參數(shù)的啟動命令即可。它默認(rèn)監(jiān)聽8428端口categraf會上報到這個端口。這里有個細(xì)節(jié)夜鶯是支持配置多個數(shù)據(jù)源的但默認(rèn)情況下的時序庫地址就是指VictoriaMetrics的寫入和查詢地址我一般會檢查一下夜鶯的etc/config.toml里Prometheus部分的配置是否和VictoriaMetrics實際端口一致。最后是n9e進(jìn)程本身。解壓安裝包之后通常需要導(dǎo)入數(shù)據(jù)庫表結(jié)構(gòu)再修改config.toml里的MySQL、Redis、時序庫連接信息最后啟動n9e訪問/health接口確認(rèn)服務(wù)正常。夜鶯服務(wù)端的初始化步驟官方文檔寫得很詳細(xì)但有一個細(xì)節(jié)容易漏如果你用的是MySQL 8.0要注意默認(rèn)認(rèn)證插件是caching_sha2_password老版本的Go驅(qū)動可能不支持建議在創(chuàng)建用戶時指定mysql_native_password。2.2 categraf客戶端安裝categraf安裝就更直接了。從GitHub或網(wǎng)盤拉取對應(yīng)CPU架構(gòu)的二進(jìn)制壓縮包解壓到指定目錄比如/opt/categraf。目錄里有兩個核心部分一個是categraf可執(zhí)行文件另一個是conf配置目錄。conf目錄下默認(rèn)有config.toml全局配置和一個叫inputs的目錄里面按插件名分了子目錄每個子目錄里放著相應(yīng)插件的配置文件。安裝完成后先別急著啟動先改全局配置里的幾個關(guān)鍵項一是上報地址也就是夜鶯服務(wù)端或VictoriaMetrics的地址二是采集器自身的主機名和標(biāo)簽這決定了你之后在夜鶯上看到這臺機器叫什么名字、帶哪些標(biāo)簽。我習(xí)慣上會把region、env這種通用標(biāo)簽打在全局配置里這樣在多機房或多環(huán)境混部的時候篩選起來特別方便。改完配置之后可以先用單次模式啟動一次驗證配置是否正確。categraf支持直接運行categraf --test這樣類似telegraf的測試模式它會采集一次數(shù)據(jù)并輸出結(jié)果。看到stdout里有一行行數(shù)據(jù)打印出來就可以把categraf注冊成systemd服務(wù)正式跑起來了。2.3 客戶端到服務(wù)端的連通性驗證雖然這一步看起來很簡單但很多問題都出在這里。categraf啟動后如果配置的上報地址是VictoriaMetrics可以直接在服務(wù)器上執(zhí)行curl -s http://服務(wù)端IP:8428/api/v1/query?queryup來查一下有沒有這個采集目標(biāo)的數(shù)據(jù)。如果返回的結(jié)果是空的說明categraf的數(shù)據(jù)根本沒進(jìn)到存儲里。這個時候需要排查三層網(wǎng)絡(luò)通不通、端口通不通、數(shù)據(jù)格式對不對。網(wǎng)絡(luò)和端口層面主要是查防火墻和selinux。很多云服務(wù)器默認(rèn)安全組只放行了常用端口8428、17000這類監(jiān)控端口容易被漏掉。另外categraf上報如果走的是獨立agent端口還要確認(rèn)agent監(jiān)聽端口有沒有放行。數(shù)據(jù)格式層面的問題通常表現(xiàn)為categraf日志里報連接失敗或者返回非200狀態(tài)碼。這時可以把categraf日志級別調(diào)到debug它會打印出完整的HTTP請求地址和響應(yīng)碼很快就能定位是URL拼錯了還是鑒權(quán)沒過。3. 采集器核心配置與指標(biāo)接入安裝跑通只是第一步真正的重頭戲在于配置采集器讓數(shù)據(jù)符合你的監(jiān)控需求。這一部分我挑幾個最重要的配置項和插件展開講講覆蓋大部分人的日常所需。3.1 categraf全局配置詳解categraf的全局配置在conf/config.toml里。你打開這個文件最先看到的會是一個[global]配置段里面有hostname、labels、interval等參數(shù)。interval是采集周期默認(rèn)15秒如果你對實時性要求高可以改成10秒、5秒但要注意采集頻率提高之后對機器和時序庫的壓力也會加大建議從默認(rèn)值開始等需要時再調(diào)。接下來的[writer_opt]和[[writers]]配置段決定了數(shù)據(jù)往哪發(fā)。[[writers]]這里可以配置多個輸出端每個輸出端有url、basic_auth等字段。我們?nèi)粘Ｓ玫降膱鼍坝袃煞N一種是直接把數(shù)據(jù)寫到VictoriaMetrics的Prometheus協(xié)議接口另一種是寫到夜鶯的collector端再由夜鶯統(tǒng)一轉(zhuǎn)發(fā)。前者更直接后者多了一層緩沖和認(rèn)證。如果你用前者寫法類似[[writers]] url http://127.0.0.1:8428/api/v1/write # basic_auth [用戶名, 密碼]這里要特別提醒的是url末尾的路徑別寫錯。VictoriaMetrics兼容Prometheus remote write的接口路徑是/api/v1/write很多人習(xí)慣性寫成/api/v1/prom/write或者/api/v1/import導(dǎo)致數(shù)據(jù)一直寫不進(jìn)去。這個坑我踩過不止一次排查的時候繞了大半天才發(fā)現(xiàn)是路徑問題。另外全局配置里還有[log]段、[http]段、[aha]段。[log]控制日志輸出路徑和級別排錯時建議把level改成debug正常運行時改成info或warn。[http]段可以開啟一個本地HTTP端口用來暴露categraf自身的運行指標(biāo)和pprof信息。我一般會開啟這個端口后面排查采集器本身性能問題時非常有用。3.2 常用插件配置CPU、內(nèi)存、磁盤、進(jìn)程categraf的inputs目錄下每個插件子目錄里都有對應(yīng)的配置文件。幾個最常用的我分別說一下關(guān)鍵參數(shù)。CPU采集對應(yīng)的目錄是input.cpu主要配置是collect_per_cpu和collect_cpu_time這兩個布爾值。如果你只關(guān)心整體CPU使用率collect_per_cpu可以設(shè)為false減少指標(biāo)數(shù)量如果想看每個邏輯核的使用率就設(shè)為true。內(nèi)存采集對應(yīng)input.mem配置相對簡單基本沒有需要改的參數(shù)默認(rèn)采集的就是能直接用于畫圖和告警的內(nèi)存使用率、可用內(nèi)存等指標(biāo)。磁盤采集對應(yīng)input.disk和input.diskio。這里的坑稍多一是mounted fs類型要選對比如你不需要采集proc、sysfs、tmpfs這類虛擬文件系統(tǒng)二是ignore_fs或者mount_point的過濾規(guī)則要配置好否則會有大量重復(fù)指標(biāo)上報。我通常會把ignore_fs設(shè)成tmpfs|devtmpfs|overlay|squashfs避免出現(xiàn)一堆云主機里掛載的無意義文件系統(tǒng)。diskio那邊默認(rèn)采集所有塊設(shè)備如果機器上有很多云盤或loop設(shè)備指標(biāo)數(shù)量會偏大建議用devices過濾一下。進(jìn)程監(jiān)控是很多人會忽略、但實際很實用的一個插件對應(yīng)input.procstat。它可以按進(jìn)程名或者pid文件監(jiān)控具體進(jìn)程的運行狀態(tài)、CPU、內(nèi)存、線程數(shù)、文件句柄數(shù)等。配置里最關(guān)鍵的是pattern字段用來匹配進(jìn)程名。例如監(jiān)控nginx進(jìn)程[[instances]] pattern nginx這個插件設(shè)置好了以后進(jìn)程“活著但端口掛了”“進(jìn)程起來了但CPU占用異常高”這類問題就能第一時間暴露出來。我還習(xí)慣配合一個exec插件做自定義腳本采集比如自定義采集某個日志文件大小、某個隊列長度、某個API的響應(yīng)時間categraf會定期執(zhí)行腳本并把腳本輸出的格式解析成指標(biāo)。這種方式擴展性很強而且不需要重新編譯采集器。3.3 數(shù)據(jù)上報與指標(biāo)驗證配置好插件之后重啟categraf服務(wù)等待一個采集周期然后去查詢數(shù)據(jù)確認(rèn)。如果數(shù)據(jù)直接寫到VictoriaMetrics可以用PromQL查詢驗證比如curl -g http://127.0.0.1:8428/api/v1/query?querymem_used_percent返回結(jié)果里應(yīng)該能看到當(dāng)前機器的內(nèi)存使用率。這時再去夜鶯的“指標(biāo)查詢”頁面切到PromQL查詢模式輸入同樣的表達(dá)式如果也能查到那就說明鏈路已經(jīng)通了。如果夜鶯頁面查不到而VictoriaMetrics里能查到問題大概率在夜鶯的數(shù)據(jù)源配置或者時序庫地址不一致上如果兩邊都查不到回categraf日志里看是否有采集錯誤或上報錯誤。另外有一個小習(xí)慣我強烈建議養(yǎng)成給新增的采集指標(biāo)都配上host標(biāo)簽或env標(biāo)簽。很多人剛開始搭監(jiān)控時不注意標(biāo)簽規(guī)范化等機器多了以后查詢和告警里寫標(biāo)簽匹配規(guī)則時會特別痛苦。標(biāo)簽這玩意兒前期花半小時設(shè)計好后面能省無數(shù)個早晨。4. 告警規(guī)則與監(jiān)控面板采集器把數(shù)據(jù)送進(jìn)來只是基礎(chǔ)監(jiān)控系統(tǒng)真正產(chǎn)生價值的地方在告警和可視化。夜鶯在這兩塊的體驗做得比較貼近用戶直覺我講講常用的配置思路。4.1 告警規(guī)則配置夜鶯的告警規(guī)則配置入口在“告警管理”模塊。新建告警規(guī)則時有幾個關(guān)鍵字段需要理解清楚規(guī)則名稱、PromQL、告警級別、執(zhí)行頻率、持續(xù)時間、通知組。PromQL是你首先要寫對的東西。比如想告警CPU使用率超過90%持續(xù)5分鐘表達(dá)式可以寫成cpu_usage_idle 10注意categraf的CPU指標(biāo)通常是cpu_usage_idle空閑率不是直接的usage率所以“使用率超過90%”要反過來寫。這個細(xì)節(jié)很多人沒注意直接寫cpu_usage 90發(fā)現(xiàn)數(shù)據(jù)永遠(yuǎn)是空的其實是字段名或者語義反了。執(zhí)行頻率和持續(xù)時間要配合好。我一般建議執(zhí)行頻率設(shè)置成一分鐘持續(xù)時間設(shè)置成5分鐘。這樣既不會因為瞬時抖動頻繁報警也不會因為等待時間太長錯過故障窗口。告警級別和通知渠道方面夜鶯支持接入釘釘、企業(yè)微信、郵件、Webhook等每種渠道都能綁定到不同的告警級別。實際操作時我把P0級別的告警同時發(fā)到電話/IM和郵件P2級別只發(fā)到IM群這樣可以讓緊急問題盡快觸達(dá)核心人員又不至于讓普通故障把大家手機震麻。還有一個容易被忽略的點是“告警恢復(fù)通知”。夜鶯默認(rèn)會在告警恢復(fù)后發(fā)送恢復(fù)通知這一項建議保持開啟。沒有恢復(fù)通知的話值班同事經(jīng)常得在告警群里猜“現(xiàn)在到底好了沒有”體驗很糟糕。4.2 內(nèi)置大盤與自定義面板夜鶯自帶了一些官方大盤模板比如Linux主機監(jiān)控、MySQL監(jiān)控等。如果只是看基礎(chǔ)指標(biāo)直接用內(nèi)置大盤就夠了。但內(nèi)置大盤的布局不一定符合你團隊的習(xí)慣我一般會再復(fù)制一份做調(diào)整。夜鶯的大盤編輯是所見即所得的模式新增圖表時核心還是PromQL比如展示CPU使用率趨勢100 - cpu_usage_idle變量面板功能也很有用比如給大盤設(shè)置一個host的變量然后圖表里用$host去過濾。這樣你一套大盤就能看所有機器不用每臺機器建一個面板。面板類目比較多的時候建議按“主機監(jiān)控、中間件監(jiān)控、業(yè)務(wù)監(jiān)控、告警統(tǒng)計”分組。分組清晰了新人上手找面板的成本會低很多。4.3 指標(biāo)保留周期與存儲策略存儲策略這塊很多人一開始不在乎等數(shù)據(jù)量大了才頭疼。VictoriaMetrics單機版默認(rèn)會保留所有數(shù)據(jù)如果不設(shè)置retentionPeriod參數(shù)磁盤會越用越多。建議在啟動VictoriaMetrics時加上-retentionPeriod3或者6單位是月根據(jù)自己的實際需求設(shè)置保存時長。基礎(chǔ)監(jiān)控指標(biāo)保留3個月一般夠了如果要做趨勢分析、容量規(guī)劃可以保留更長時間但要確保磁盤容量足夠。另外要注意存儲目錄的磁盤空間監(jiān)控。時序數(shù)據(jù)在指標(biāo)數(shù)量大、采集頻率高的情況下增長很快如果磁盤滿了VictoriaMetrics寫入會報錯categraf的數(shù)據(jù)就開始積壓。我踩過一次磁盤寫滿的坑最后的教訓(xùn)是給監(jiān)控存儲單獨掛一塊盤并且把這塊盤的磁盤使用率納入基礎(chǔ)告警規(guī)則里誰滿了第一時間告警出來。5. 常見問題排查與實操避坑這一章我梳理一下實際操作里出現(xiàn)頻率比較高的幾類問題每個問題都按照“現(xiàn)象-排查思路-解決辦法”的格式寫方便你到時候直接對著查。5.1 啟動失敗與配置加載失敗categraf啟動時報錯最常見的是配置文件格式不正確。TOML格式對縮進(jìn)和引號的要求比較嚴(yán)格稍不注意就解析失敗。啟動時報錯信息里一般會指向具體的行號你直接打開對應(yīng)文件看那一行附近有沒有多了或少了引號、方括號。還有可能是某插件配置文件里引用了不存在的模塊名這時categraf會提示unknown input。解決辦法是進(jìn)入conf/inputs目錄仔細(xì)核對插件目錄名和配置文件里的type字段是否一致。另一種情況是systemd啟動失敗日志顯示沒有權(quán)限讀取某配置文件。這通常是因為categraf運行的workdir配置不對它內(nèi)部很多相對路徑是相對于當(dāng)前工作目錄的。如果用了systemd托管在service文件里要顯式指定WorkingDirectory/opt/categraf否則categraf會去當(dāng)前的默認(rèn)目錄下找conf自然找不到。5.2 數(shù)據(jù)不顯示從采集到查詢逐層排查這個問題發(fā)生的頻率排第一。一臺機器加了監(jiān)控結(jié)果夜鶯大盤上一個指標(biāo)都沒有怎么排查按照數(shù)據(jù)流方向逐層確認(rèn)第一步確認(rèn)categraf進(jìn)程正常。執(zhí)行systemctl status categraf或者直接看進(jìn)程列表。如果進(jìn)程不在回看啟動日志。第二步確認(rèn)categraf有沒有采集到數(shù)據(jù)。用--test模式手動跑一次插件看看是否有指標(biāo)輸出。第三步確認(rèn)數(shù)據(jù)有沒有上報?？碿ategraf日志里有沒有write error或者網(wǎng)絡(luò)超時的記錄或者到VictoriaMetrics的接口上查一下最近時間戳有沒有新數(shù)據(jù)寫入。第四步確認(rèn)夜鶯查詢鏈路。在夜鶯的指標(biāo)查詢頁面用裸指標(biāo)名查詢查看是否返回數(shù)據(jù)。如果裸查詢有數(shù)據(jù)但面板上沒數(shù)據(jù)就檢查面板的PromQL表達(dá)式和變量過濾是否正確。實際上很多“數(shù)據(jù)不顯示”的問題最后定位出來都是標(biāo)簽過濾條件寫多了面板的變量host選了A而指標(biāo)上的host標(biāo)簽是B自然查不到。這種情況不是監(jiān)控壞了是查詢條件不一致。建議新手在排查這類問題時先不加任何過濾條件查原始指標(biāo)等看到數(shù)據(jù)了再逐步添加條件一步步縮小范圍。5.3 網(wǎng)絡(luò)與防火墻問題導(dǎo)致的寫不進(jìn)去categraf日志里如果反復(fù)出現(xiàn)connection refused或者timed out多半是網(wǎng)絡(luò)層面的問題。先ping一下服務(wù)端IP再telnet一下目標(biāo)端口。如果是云主機除了系統(tǒng)防火墻還要檢查安全組如果是物理機檢查iptables規(guī)則。還有一個我經(jīng)常踩的坑服務(wù)端VictoriaMetrics監(jiān)聽的是127.0.0.1而不是0.0.0.0導(dǎo)致客戶端根本連不上。這個可以通過ss -lntp來確認(rèn)確保監(jiān)聽地址是0.0.0.0或者內(nèi)網(wǎng)IP。另外要注意HTTP代理的影響。有些服務(wù)器設(shè)置了http_proxy環(huán)境變量categraf的上報請求有可能走了代理而代理又不通內(nèi)網(wǎng)地址。這種問題表現(xiàn)得很隱蔽日志里看著是網(wǎng)絡(luò)超時但服務(wù)端和客戶端本機網(wǎng)絡(luò)都正常。解決辦法是在啟動categraf的systemd服務(wù)里取消代理環(huán)境變量或者在配置文件的網(wǎng)絡(luò)相關(guān)部分明確不走代理。5.4 告警沒有觸發(fā)或者重復(fù)告警告警配置好了但不觸發(fā)先檢查PromQL在夜鶯查詢頁面能不能查出數(shù)據(jù)。如果查詢有數(shù)據(jù)檢查告警規(guī)則里的“持續(xù)時間”設(shè)置持續(xù)時間是5分鐘意味著指標(biāo)連續(xù)5分鐘都滿足條件才告警中間任何一次恢復(fù)到正常都會重新計時這是很多新人困惑的地方。如果查詢沒數(shù)據(jù)那說明告警對象本身就沒有指標(biāo)需要回到數(shù)據(jù)采集層面排查。重復(fù)告警也很常見。夜鶯默認(rèn)會對同一規(guī)則的同一告警對象做去重但如果你配置了多個告警規(guī)則同時匹配同一指標(biāo)或者通過夜鶯的“內(nèi)置指標(biāo)”和自定義指標(biāo)重復(fù)配置了相似的規(guī)則就會造成告警風(fēng)暴。解決辦法是定期梳理告警規(guī)則保持規(guī)則盡量精簡。再補充一個告警靜默的場景某臺機器做計劃內(nèi)維護導(dǎo)致CPU持續(xù)飆高這時與其關(guān)掉告警規(guī)則不如給這臺機器添加一個靜默策略。夜鶯支持按機器標(biāo)簽設(shè)置靜默時間段時間到了自動恢復(fù)不會出現(xiàn)“維護了三天、忘了開告警第四天才能發(fā)現(xiàn)”的尷尬局面。6. 從量到質(zhì)監(jiān)控體系的優(yōu)化心得平臺跑起來、告警響起來之后工作還沒完。我在實際運營這套系統(tǒng)的過程中慢慢總結(jié)出幾條經(jīng)驗寫在這里供你參考。6.1 資源占用與采集頻率的平衡categraf本身用Go寫的資源占用很小在普通2C4G的機器上默認(rèn)配置下CPU占用通常在1%以內(nèi)內(nèi)存占用在100MB左右。但是當(dāng)你啟用了大量插件尤其是procstat、exec這類需要反復(fù)掃描系統(tǒng)信息的插件時資源占用會有明顯上升。我建議在上線之前在測試機上看一下top輸出確認(rèn)categraf的CPU和內(nèi)存占用是否符合預(yù)期。如果采集頻率比較激進(jìn)比如5秒一次而且同時開了很多插件可以考慮把頻率放寬到10秒或15秒這通常不會對告警及時性造成明顯影響但能顯著降低負(fù)載。還有一個容易忽略的資源點是文件句柄數(shù)。categraf會打開很多設(shè)備文件、socket連接如果機器ulimit設(shè)置得過低運行時間長了可能報too many open files。建議在systemd服務(wù)文件里設(shè)置LimitNOFILE65535或者更大。6.2 資產(chǎn)梳理與標(biāo)簽規(guī)范隨著機器數(shù)量增長你會發(fā)現(xiàn)標(biāo)簽規(guī)范化是監(jiān)控系統(tǒng)后期最重要的資產(chǎn)。每一臺機器上報的數(shù)據(jù)都應(yīng)該帶有固定的標(biāo)簽機房、環(huán)境、業(yè)務(wù)線、角色。比如一臺Web服務(wù)器標(biāo)簽可以設(shè)計成idccn-east-1, envprod, serviceweb, rolenginx。這樣在做聚合和過濾的時候一條PromQL就能快速圈定范圍。標(biāo)簽規(guī)范建議在第一次部署時就定好并且要求所有新增機器嚴(yán)格遵循。我在實際工作中見到太多團隊因為沒有規(guī)范后面寫告警篩選條件時只能靠機器名模糊匹配效率極低。還有一點categraf全局標(biāo)簽和插件獨立標(biāo)簽不要互相覆蓋改動標(biāo)簽時先想清楚會影響哪些存量告警規(guī)則避免一改標(biāo)簽告警全失效。6.3 最后一點個人經(jīng)驗說實話監(jiān)控系統(tǒng)這個東西搭建只是開始后面大量的時間其實是花在“規(guī)則調(diào)優(yōu)”和“數(shù)據(jù)質(zhì)量治理”上。我的體會是不要追求一次把所有指標(biāo)都采全、把所有告警都配上而是先鋪一個最小可用集合CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、關(guān)鍵進(jìn)程。跑一段時間觀察哪些告警是有價值的、哪些是噪音再逐步增加更多的中間件和業(yè)務(wù)指標(biāo)。先把鏈路弄通再慢慢做厚這個路徑是最穩(wěn)的。我還習(xí)慣在夜鶯上建一塊“告警統(tǒng)計”大盤用來匯總每天、每周的告警數(shù)量、Top告警對象、告警恢復(fù)耗時。通過這個大盤能比較直觀地發(fā)現(xiàn)哪些機器總是出問題、哪些告警規(guī)則一直在吵但沒人處理然后定期做一輪治理。監(jiān)控不是用來“嚇人”的它是幫你提前發(fā)現(xiàn)風(fēng)險的信號系統(tǒng)。希望這套夜鶯加categraf的方案能讓你在遇到故障的時候少一點手忙腳亂多一點從容排查的底氣。