1. 項(xiàng)目概述夜鶯監(jiān)控到底是什么如果你維護(hù)過幾百臺(tái)機(jī)器又被某個(gè)傳統(tǒng)監(jiān)控平臺(tái)按著頭皮做告警規(guī)則大概率體會(huì)過這種糾結(jié)數(shù)據(jù)確實(shí)能收到但告警一多就產(chǎn)生疲勞規(guī)則寫起來費(fèi)勁想按團(tuán)隊(duì)隔離數(shù)據(jù)發(fā)現(xiàn)大家都在一個(gè)大池子里通知渠道還固定得死死的想接個(gè)企業(yè)微信都要研究半天。夜鶯監(jiān)控Nightingale這套開源系統(tǒng)正是沖著這些歷史遺留問題來的。它最早由滴滴出行開源核心代碼用 Go 編寫現(xiàn)在掛在 CNCF 沙盒項(xiàng)目里定位是覆蓋“采集、存儲(chǔ)、告警、通知”全鏈路的大規(guī)模監(jiān)控平臺(tái)同時(shí)原生兼容 Prometheus 生態(tài)。你完全可以把它理解成一套更貼合團(tuán)隊(duì)協(xié)作、更適合企業(yè)級(jí)落地的現(xiàn)代化監(jiān)控作戰(zhàn)平臺(tái)。這套系統(tǒng)適合誰如果你是運(yùn)維工程師、SRE、平臺(tái)開發(fā)或者在維護(hù)幾十臺(tái)以上服務(wù)器、一堆容器化應(yīng)用又對(duì) Zabbix 的復(fù)雜配置和 Prometheus 的分散組件感到頭疼夜鶯值得你花一個(gè)下午認(rèn)真試試。它不是一個(gè)只停留在 demo 層面的玩具而是大量生產(chǎn)環(huán)境驗(yàn)證過的項(xiàng)目。我身邊不少團(tuán)隊(duì)都是先用 Zabbix 頂著規(guī)模上來了以后逐步把業(yè)務(wù)組往夜鶯遷移。下面我會(huì)從架構(gòu)、部署、告警生命周期、與 Zabbix 的選型對(duì)比、常見問題這幾個(gè)維度把整個(gè)項(xiàng)目拆開講透。1.1 夜鶯的定位與核心價(jià)值夜鶯的核心設(shè)計(jì)目標(biāo)我總結(jié)下來就是三個(gè)詞大規(guī)模、多租戶、高可用。傳統(tǒng)監(jiān)控系統(tǒng)在幾千臺(tái)機(jī)器、幾千萬條時(shí)間序列面前往往會(huì)遇到數(shù)據(jù)庫瓶頸、告警卡頓、規(guī)則評(píng)估超時(shí)這類問題。夜鶯從一開始就按超大規(guī)模場景設(shè)計(jì)底層指標(biāo)存儲(chǔ)直接對(duì)接時(shí)序數(shù)據(jù)庫而不是把所有數(shù)據(jù)塞進(jìn)關(guān)系型數(shù)據(jù)庫里硬扛。這意味著你的監(jiān)控容量天花板被大幅抬高擴(kuò)容也變成了一件相對(duì)自然的事情。多租戶是夜鶯區(qū)別于很多開源監(jiān)控系統(tǒng)的重要特性。它用“業(yè)務(wù)組”Business Group做資源隔離不同團(tuán)隊(duì)各自管理自己的機(jī)器、采集器、告警規(guī)則互相不干擾。這個(gè)設(shè)計(jì)在大型公司里極其重要。以前用一臺(tái) Zabbix 管全公司DBA 想看數(shù)據(jù)庫的監(jiān)控運(yùn)維想看主機(jī)的監(jiān)控網(wǎng)絡(luò)組想看交換機(jī)的監(jiān)控所有人擠在同一個(gè)界面里權(quán)限不好控制告警通知也容易亂。夜鶯里天然地把這些拆開每個(gè)業(yè)務(wù)組是一個(gè)獨(dú)立工作空間從權(quán)限到告警再到通知渠道都可以各自獨(dú)立配置。另外一個(gè)值得說的點(diǎn)是它對(duì)云原生環(huán)境的包容度。夜鶯的指標(biāo)模型和 Prometheus 對(duì)齊支持 PromQL這意味著你在 Kubernetes 里用的那些 exporter、ServiceMonitor 概念都能順滑地和夜鶯銜接。很多 K8s 集群已經(jīng)在跑 Prometheus夜鶯可以扮演統(tǒng)一告警中心的角色把多個(gè) Prometheus 的數(shù)據(jù)匯聚起來做集中告警和通知分派而不是逼你把原有采集體系推倒重來。1.2 系統(tǒng)架構(gòu)與關(guān)鍵組件夜鶯的整體架構(gòu)可以分成四層采集層、服務(wù)層、存儲(chǔ)層、告警通知層。采集層負(fù)責(zé)從機(jī)器、中間件、應(yīng)用里拿指標(biāo)服務(wù)層負(fù)責(zé)接收數(shù)據(jù)、維護(hù)元數(shù)據(jù)、處理 API 請(qǐng)求存儲(chǔ)層負(fù)責(zé)指標(biāo)數(shù)據(jù)落盤和元數(shù)據(jù)記錄告警通知層負(fù)責(zé)規(guī)則評(píng)估、事件生成、消息推送。理解了這個(gè)分層后面部署和排錯(cuò)就順了。采集層官方主推 Categraf 采集器它是一個(gè)用 Go 寫的輕量 agent支持大量內(nèi)置插件可以采集 CPU、內(nèi)存、磁盤、進(jìn)程、端口、MySQL、Redis、Kafka 等常見對(duì)象。同時(shí)夜鶯也兼容 Telegraf、grafana-agent以及各種 Prometheus exporter。服務(wù)層最新版本的服務(wù)端是一個(gè)統(tǒng)一進(jìn)程包含 webapi、server、告警引擎等模塊部署上比早期版本簡單很多。元數(shù)據(jù)存 MySQL緩存走 Redis。存儲(chǔ)層指標(biāo)數(shù)據(jù)本身不存 MySQL而是通過遠(yuǎn)程寫入的方式寫進(jìn)時(shí)序數(shù)據(jù)庫。官方推薦 VictoriaMetrics也可以用 Prometheus、Mimir 等兼容的時(shí)序存儲(chǔ)。告警通知層內(nèi)部告警引擎基于 PromQL 做規(guī)則評(píng)估事件產(chǎn)生后通過內(nèi)置的通知渠道分發(fā)給企業(yè)微信、釘釘、飛書、郵件、webhook 等。這里我要特別強(qiáng)調(diào)一句“元數(shù)據(jù)和指標(biāo)數(shù)據(jù)分離”的重要意義。很多人在初次接觸夜鶯時(shí)會(huì)習(xí)慣性以為它和 Zabbix 一樣把所有監(jiān)控歷史都放在 MySQL 里。實(shí)際上表格設(shè)計(jì)完全不是這套思路。MySQL 只存機(jī)器列表、業(yè)務(wù)組、用戶、告警規(guī)則、通知記錄這類結(jié)構(gòu)化信息而真正的指標(biāo)曲線數(shù)據(jù)全部進(jìn)入時(shí)序數(shù)據(jù)庫。這套設(shè)計(jì)直接決定了它能支持幾十億條時(shí)間序列而不會(huì)像早期 Zabbix 那樣在數(shù)據(jù)量一大時(shí)明顯變慢。2. 核心功能拆解從采數(shù)到告警通知2.1 指標(biāo)采集Categraf、Telegraf 與 Prometheus 生態(tài)夜鶯的采集策略我總結(jié)了四個(gè)字“兼容并包”。最省心的方式是直接部署 Categraf。它是一個(gè)二進(jìn)制 agent部署完以后先去夜鶯頁面生成一個(gè)采集器 token把 token 填進(jìn) Categraf 配置文件的 HTTP 地址里它就會(huì)自動(dòng)向夜鶯上報(bào)機(jī)器信息和指標(biāo)數(shù)據(jù)。Categraf 的配置非常直白比如你要監(jiān)控 MySQL就在conf/input.mysql/mysql.toml里填上實(shí)例地址、賬號(hào)、密碼然后啟用插件采集器重啟后數(shù)據(jù)就會(huì)出現(xiàn)在夜鶯的指標(biāo)視圖里。我在實(shí)際項(xiàng)目里用得最多的反而是另一個(gè)組合服務(wù)已經(jīng)暴露了 Prometheus 指標(biāo)接口比如 Spring Boot 的 Actuator、Nginx Exporter、Node Exporter 這類夜鶯提供了“抓取”功能可以直接配置 URL 去拉取這些指標(biāo)不需要再裝 Categraf。這種拉模式很適合監(jiān)控那些不想被安裝 agent 的中間件或云服務(wù)。再加上 Categraf 本身也支持 prometheus 抓取插件兩邊一配合基本能覆蓋所有常見采集場景。有些場景需要推送指標(biāo)比如短生命周期任務(wù)、業(yè)務(wù)自定義指標(biāo)。夜鶯也支持通過 remote write 協(xié)議直接寫入指標(biāo)數(shù)據(jù)。換句話說你的應(yīng)用只要往指定 HTTP 接口推一段 Prometheus 格式的數(shù)據(jù)即可完全不用關(guān)心服務(wù)端內(nèi)部如何處理。2.2 告警引擎與規(guī)則設(shè)計(jì)告警是夜鶯的重頭戲也是我從 Zabbix 遷移過來后感受最深的部分。Zabbix 的觸發(fā)器表達(dá)式寫起來需要記一套獨(dú)立的語法說實(shí)話遷移和學(xué)習(xí)成本都不小。夜鶯直接用 PromQL 寫告警規(guī)則凡是接觸過 Prometheus 的人都能很快上手。更通用一點(diǎn)說PromQL 是整個(gè)云原生可觀測性領(lǐng)域的通用語言你用熟了以后不只在夜鶯里能寫在 VictoriaMetrics、Mimir 里也能寫技能是可平移的。夜鶯的告警規(guī)則支持兩種模式一種是對(duì)機(jī)器/業(yè)務(wù)組的“主機(jī)指標(biāo)告警”適合 CPU、內(nèi)存、磁盤這類以機(jī)器為維度的監(jiān)控另一種是“自定義指標(biāo)告警”直接寫 PromQL適合應(yīng)用類指標(biāo)、K8s 指標(biāo)這類更靈活的查詢。規(guī)則里可以設(shè)置持續(xù)時(shí)長、執(zhí)行頻率、告警級(jí)別、通知對(duì)象還可以關(guān)聯(lián)通知模板。我在生產(chǎn)環(huán)境里踩過一個(gè)很重要的坑告警規(guī)則里的持續(xù)時(shí)長不是越短越好。比如 CPU 使用率超過 95% 持續(xù) 1 分鐘就觸發(fā)告警看起來很及時(shí)其實(shí)很容易被瞬時(shí)峰值轟炸。我一般會(huì)設(shè)置成持續(xù) 5 到 10 分鐘并且配合“恢復(fù)通知”功能讓告警在恢復(fù)后自動(dòng)通知一次。這樣既不會(huì)漏掉真實(shí)故障也不會(huì)制造太多噪音。這個(gè)經(jīng)驗(yàn)放在 Zabbix 里同樣成立只不過 Zabbix 的觸發(fā)器里對(duì)這種持續(xù)時(shí)間表達(dá)得稍微隱晦一些。2.3 通知渠道與降噪企業(yè)微信、釘釘、飛書告警通知渠道決定了故障響應(yīng)效率。夜鶯內(nèi)置了多種通知渠道其中企業(yè)微信通知是國內(nèi)團(tuán)隊(duì)用得最多的。配置方式并不復(fù)雜你需要先在企業(yè)微信管理后臺(tái)創(chuàng)建一個(gè)自建應(yīng)用拿到企業(yè) IDCorpID、應(yīng)用 AgentId、應(yīng)用 Secret然后在夜鶯的“通知配置”里新建一個(gè)企業(yè)微信渠道把這三個(gè)信息填進(jìn)去保存后發(fā)一條測試消息驗(yàn)證即可。我額外建議做兩件降噪優(yōu)化。第一按告警級(jí)別分渠道發(fā)送例如 P0 告警發(fā)到專門的故障響應(yīng)群P2 告警只發(fā)郵件或者在工作日?qǐng)?bào)里匯總。第二利用夜鶯的“靜默”功能在維護(hù)窗口、發(fā)版期設(shè)置定時(shí)靜默避免半夜因?yàn)槔凶兏|發(fā)的告警把值班同事嚇醒。很多人前期不重視降噪結(jié)果告警渠道接入后群里全是刷屏消息沒人愿意看。這不是渠道的問題是使用姿勢的問題。3. 從零部署一套夜鶯監(jiān)控3.1 部署方式選型與資源規(guī)劃夜鶯最新的部署方式我建議直接采用官方提供的 Docker Compose 編排。一條命令拉起來整套環(huán)境省去手工安裝 MySQL、Redis、VictoriaMetrics 的麻煩。二進(jìn)制包部署方式依然存在適合那些需要把夜鶯打進(jìn)公司內(nèi)部自動(dòng)化運(yùn)維體系的場景。資源規(guī)劃方面我給出一個(gè)經(jīng)驗(yàn)值如果監(jiān)控規(guī)模在 100 臺(tái)機(jī)器以內(nèi)4 核 8G 內(nèi)存的虛機(jī)完全夠用500 臺(tái)機(jī)器左右推薦 8 核 16G超過 1000 臺(tái)就建議把 MySQL、VictoriaMetrics、夜鶯服務(wù)端拆開部署。這里最容易被低估的是磁盤性能指標(biāo)寫入對(duì)磁盤 IOPS 要求較高有條件盡量用 SSD或者給 VictoriaMetrics 單獨(dú)掛數(shù)據(jù)盤避免和系統(tǒng)盤搶 IO。3.2 快速安裝實(shí)操我以 Docker Compose 方式為例操作步驟非常直接。先裝好 Docker 和 docker-compose 插件然后拉取官方倉庫里的部署目錄執(zhí)行docker-compose up -d把整套環(huán)境啟動(dòng)起來。等待一分鐘左右打開瀏覽器訪問http://服務(wù)器IP:17000看到的就是夜鶯登錄頁。默認(rèn)賬號(hào)是root默認(rèn)密碼是root.2020這里我必須強(qiáng)調(diào)一句登錄后第一件事就是改密碼并且建議關(guān)閉默認(rèn)賬號(hào)新建自己的管理員用戶。這套系統(tǒng)暴露在公網(wǎng)以后默認(rèn)口令很容易被掃描器利用屬于絕對(duì)的低級(jí)風(fēng)險(xiǎn)。啟動(dòng)完成后你在頁面里會(huì)看到“業(yè)務(wù)組”的概念。先創(chuàng)建自己的業(yè)務(wù)組然后進(jìn)入業(yè)務(wù)組創(chuàng)建采集器 token。這個(gè) token 就是 Categraf 連接夜鶯服務(wù)端的身份憑證和 Zabbix 里的主動(dòng)注冊(cè)密碼作用類似。3.3 接入第一個(gè)監(jiān)控目標(biāo)這里我用一臺(tái) Linux 服務(wù)器舉例子。下載 Categraf 二進(jìn)制包解壓后修改conf/config.toml把 HTTP 地址改成http://夜鶯服務(wù)器IP:17000再把剛才創(chuàng)建的 token 填進(jìn)去。啟動(dòng) Categraf 進(jìn)程幾秒鐘后回到夜鶯頁面在“機(jī)器列表”里就能看到這臺(tái)宿主機(jī)的注冊(cè)信息同時(shí) CPU、內(nèi)存、磁盤這些基礎(chǔ)指標(biāo)已經(jīng)開始上報(bào)。如果你要監(jiān)控的是 MySQL在 Categraf 的 input.mysql 目錄下配置連接信息并啟用插件然后重啟 Categraf。通常一分鐘內(nèi)夜鶯的“即時(shí)查詢”里就能查到mysql_up這類指標(biāo)。這里有個(gè)排查技巧數(shù)據(jù)沒出現(xiàn)時(shí)先別急著懷疑服務(wù)端直接在 Categraf 機(jī)器上手動(dòng)執(zhí)行一次采集器看報(bào)表有沒有報(bào)錯(cuò)這個(gè)步驟能快速定位是連接問題還是配置問題。4. 告警生命周期管理從觸發(fā)到解決4.1 告警的觸發(fā)、恢復(fù)與自動(dòng)消除原理很多從 Zabbix 遷移過來的朋友第一次看到夜鶯的告警列表都會(huì)迷惑為什么這個(gè)主機(jī)的指標(biāo)明明已經(jīng)恢復(fù)正常告警還沒自動(dòng)消失這里要先理解夜鶯的告警生命周期模型。一個(gè)告警事件會(huì)經(jīng)歷“觸發(fā)中 - 已觸發(fā) - 已恢復(fù)/已解決”這幾個(gè)狀態(tài)。當(dāng)指標(biāo)滿足規(guī)則條件時(shí)事件被創(chuàng)建并產(chǎn)生通知此時(shí)狀態(tài)是“已觸發(fā)”當(dāng)指標(biāo)恢復(fù)到正常值并且滿足規(guī)則里設(shè)置的恢復(fù)條件時(shí)事件才會(huì)進(jìn)入“已恢復(fù)”狀態(tài)。Zabbix 里有一個(gè)很直觀的“主機(jī)問題已解決”的展示邏輯問題恢復(fù)后前面會(huì)打上綠色的勾。夜鶯的思路其實(shí)是一樣的只是它的恢復(fù)狀態(tài)不會(huì)默認(rèn)從列表里移除而是作為歷史事件保留下來。這樣設(shè)計(jì)的好處是保留了完整的告警審計(jì)鏈路事后復(fù)盤時(shí)可以很清楚地看到這個(gè)告警什么時(shí)候開始、什么時(shí)候恢復(fù)、通知發(fā)給了誰。所以不要用“Zabbix 會(huì)自動(dòng)變成綠色”的固有印象來套夜鶯你得適應(yīng)它的狀態(tài)流轉(zhuǎn)。4.2 手動(dòng)消除告警的幾種正確姿勢如果你確實(shí)遇到了“告警恢復(fù)后還掛在列表里”或“某些告警需要人工介入處理后才能關(guān)閉”的場景夜鶯提供了很多手動(dòng)操作手段。處理單個(gè)告警在告警事件詳情頁可以對(duì)事件執(zhí)行“關(guān)閉/標(biāo)記解決”操作相當(dāng)于人工確認(rèn)這個(gè)事件已經(jīng)處理完畢。靜默指定對(duì)象如果某臺(tái)機(jī)器正在進(jìn)行重裝系統(tǒng)、硬件維修等操作不想因?yàn)檫@些操作引發(fā)噪音告警可以創(chuàng)建一個(gè)屏蔽規(guī)則設(shè)置起始結(jié)束時(shí)間到點(diǎn)自動(dòng)解除。屏蔽整個(gè)規(guī)則當(dāng)某個(gè)業(yè)務(wù)組正在進(jìn)行大版本變更預(yù)計(jì)會(huì)長時(shí)間觸發(fā)多條規(guī)則時(shí)可以直接把相關(guān)告警規(guī)則暫?；蚣尤朱o默避免告警風(fēng)暴。我的經(jīng)驗(yàn)是手動(dòng)消除只能作為應(yīng)急手段不要養(yǎng)成“用手點(diǎn)掉”的習(xí)慣。真正要靠的是把告警規(guī)則、恢復(fù)條件和靜默策略設(shè)計(jì)好讓系統(tǒng)在常態(tài)下能自己閉環(huán)。手動(dòng)操作太多總有一天會(huì)漏掉一條真正重要的告警。4.3 夜鶯企業(yè)微信通知配置全過程企業(yè)微信通知我前面簡單提過這里把完整流程拆開。登錄夜鶯后進(jìn)入“通知配置”新建一個(gè)“企業(yè)微信”渠道。企業(yè)微信管理后臺(tái)需要你創(chuàng)建一個(gè)自建應(yīng)用記錄下 CorpID企業(yè) ID、AgentId、Secret。在夜鶯渠道配置里填好這些參數(shù)后保存并測試發(fā)送。測試消息會(huì)通過企業(yè)微信應(yīng)用推送到你綁定的成員賬戶里。這里要注意一個(gè)細(xì)節(jié)企業(yè)微信應(yīng)用默認(rèn)只能向應(yīng)用可見范圍內(nèi)的成員發(fā)送消息。如果測試沒收到優(yōu)先檢查企業(yè)微信應(yīng)用的可見范圍是否包含了接收人。另外告警通知的接收人需要和企業(yè)微信里的賬號(hào)對(duì)應(yīng)上夜鶯通過手機(jī)號(hào)或者賬號(hào) ID 做映射如果接收人配置對(duì)不上通知就會(huì)靜默失敗。我一般建議單獨(dú)建一個(gè)“監(jiān)控告警”企業(yè)微信群把告警機(jī)器人拉進(jìn)群再用群機(jī)器人 webhook 的方式作為消息通道。這種方式比直接推送企業(yè)微信應(yīng)用消息更適合值班場景因?yàn)樗邢嚓P(guān)同事都在同一個(gè)群里共享故障上下文響應(yīng)協(xié)作更方便。5. 夜鶯 vs Zabbix要不要遷移5.1 核心能力對(duì)比這個(gè)問題幾乎每個(gè)用 Zabbix 的團(tuán)隊(duì)都會(huì)問。我把兩者的關(guān)鍵差異整理成一張表你可以對(duì)照自己的情況判斷。對(duì)比項(xiàng)Zabbix夜鶯架構(gòu)ServerProxyAgent數(shù)據(jù)庫驅(qū)動(dòng)采集器服務(wù)端時(shí)序數(shù)據(jù)庫存儲(chǔ)分離指標(biāo)存儲(chǔ)MySQL/PostgreSQL 為主歷史數(shù)據(jù)摘要VictoriaMetrics/Prometheus 等時(shí)序庫告警語法專屬觸發(fā)器表達(dá)式PromQL云原生通用語言多租戶較弱主要靠主機(jī)組和權(quán)限業(yè)務(wù)組機(jī)制天然隔離適合多團(tuán)隊(duì)采集生態(tài)Agent 為主插件豐富Categraf、Telegraf、Exporter 全兼容云原生需要額外適配原生對(duì)齊 K8s/Prometheus 生態(tài)告警通知媒介類型豐富但配置較繁瑣內(nèi)置企業(yè)微信、釘釘、飛書、webhook 等二次開發(fā)自帶 API 但整體偏重Go 體系較輕組件可替換這張表充分體現(xiàn)了夜鶯的“現(xiàn)代感”。不是說 Zabbix 不好它依然是很多傳統(tǒng)企業(yè)網(wǎng)絡(luò)設(shè)備、服務(wù)器監(jiān)控場景里的可靠選擇只是在指標(biāo)規(guī)模、告警靈活度、多團(tuán)隊(duì)協(xié)作這幾個(gè)維度夜鶯的設(shè)計(jì)更貼合當(dāng)下基礎(chǔ)設(shè)施的形態(tài)。5.2 什么情況建議遷移我總結(jié)了幾類適合遷移的典型場景。第一服務(wù)器規(guī)模上千且指標(biāo)量持續(xù)增長Zabbix 的數(shù)據(jù)庫開始成為瓶頸歷史數(shù)據(jù)的查詢?cè)絹碓娇ā５诙﨣8s 容器集群越來越多需要和 Prometheus 生態(tài)深度打通Zabbix 對(duì)云原生支持始終差一些意思。第三公司內(nèi)部有多個(gè)開發(fā)團(tuán)隊(duì)各自需要獨(dú)立的監(jiān)控和告警視圖夜鶯的業(yè)務(wù)組機(jī)制能省下大量權(quán)限管控時(shí)間。反過來如果團(tuán)隊(duì)對(duì) Zabbix 非常熟悉機(jī)器規(guī)模也不大遷移帶來的收益就沒那么明顯。監(jiān)控系統(tǒng)的價(jià)值在于穩(wěn)定和熟悉不必為了“趕時(shí)髦”去做大規(guī)模替換。我見過不少團(tuán)隊(duì)遷移失敗原因不是夜鶯不好用而是部門慣性太大規(guī)則遷移又沒做好最后兩套系統(tǒng)并行維護(hù)反而增加了負(fù)擔(dān)。5.3 從 Zabbix 到夜鶯的遷移平滑方案如果你決定遷移我建議不要搞“大爆炸”切換。比較穩(wěn)妥的做法是先用邊緣業(yè)務(wù)組做試點(diǎn)把一部分非核心服務(wù)器用 Categraf 采集起來和 Zabbix 并行運(yùn)行一段時(shí)間。確認(rèn)告警規(guī)則評(píng)估結(jié)果和 Zabbix 基本一致后再逐步擴(kuò)大范圍。歷史數(shù)據(jù)遷移這塊我個(gè)人建議止損。Zabbix 里積累的歷史曲線數(shù)據(jù)遷移到夜鶯后格式和語義都不同強(qiáng)行遷移代價(jià)很大。通常保留近期 30 天的指標(biāo)數(shù)據(jù)供趨勢參考就夠了更早的數(shù)據(jù)直接歸檔。告警規(guī)則方面可以把 Zabbix 的觸發(fā)器逐條翻譯成 PromQL。這個(gè)過程會(huì)比較痛苦但值得用心梳理一次很多觸發(fā)器其實(shí)已經(jīng)過時(shí)了趁著遷移做一次規(guī)則瘦身比純平移效果更好。6. 常見問題速查與避坑手冊(cè)6.1 高頻問題排查我把實(shí)際運(yùn)維夜鶯過程中遇到的典型問題整理成速查表方便你遇到情況時(shí)快速對(duì)照?，F(xiàn)象可能原因排查思路Categraf 上報(bào)后機(jī)器列表無數(shù)據(jù)token 錯(cuò)誤或 HTTP 地址不通檢查 config.toml確認(rèn)能 ping 通服務(wù)端 17000 端口指標(biāo)有數(shù)據(jù)但告警不觸發(fā)規(guī)則里查詢的指標(biāo)名/標(biāo)簽不匹配在即時(shí)查詢里手動(dòng)執(zhí)行 PromQL確認(rèn)結(jié)果非空企業(yè)微信通知收不到可見范圍未包含接收人檢查企業(yè)微信應(yīng)用可見范圍測試發(fā)送告警恢復(fù)后仍顯示未解決恢復(fù)條件配置不正確檢查規(guī)則的恢復(fù)通知配置確認(rèn)恢復(fù)表達(dá)式正確頁面查詢歷史數(shù)據(jù)很慢時(shí)序庫磁盤 IO 不足或存儲(chǔ)空間緊張檢查 VictoriaMetrics 磁盤指標(biāo)考慮擴(kuò)容服務(wù)端重啟后數(shù)據(jù)斷點(diǎn)采集器本地緩沖未生效確認(rèn) Categraf 是否開啟了寫入緩沖功能另外一個(gè)常見誤區(qū)是很多人把夜鶯當(dāng)作一臺(tái)普通的 Web 應(yīng)用來看忽略了時(shí)序數(shù)據(jù)庫的運(yùn)維。VictoriaMetrics 的存儲(chǔ)目錄會(huì)持續(xù)增長你需要關(guān)注磁盤空間的告警設(shè)置數(shù)據(jù)保留策略。夜鶯默認(rèn)情況下會(huì)以遠(yuǎn)程寫入的方式不斷向時(shí)序庫寫入指標(biāo)一旦磁盤寫滿整個(gè)監(jiān)控都會(huì)停擺這個(gè)問題比服務(wù)端本身的故障更隱蔽。6.2 實(shí)戰(zhàn)經(jīng)驗(yàn)筆記關(guān)于告警規(guī)則編寫我強(qiáng)烈建議先做一段時(shí)間的“靜默運(yùn)行”。規(guī)則創(chuàng)建后不開啟通知只產(chǎn)生告警事件持續(xù)觀察一兩天確認(rèn)告警頻率合理、沒有大量重復(fù)事件后再打開通知。這個(gè)習(xí)慣能避免很多因?yàn)橐?guī)則設(shè)計(jì)不當(dāng)導(dǎo)致的告警風(fēng)暴也是我從多次教訓(xùn)里總結(jié)出來的。另一個(gè)經(jīng)驗(yàn)是關(guān)于告警恢復(fù)通知的。很多人覺得恢復(fù)通知無所謂實(shí)際上它很重要。值班同事收到一條告警后會(huì)很自然地等待恢復(fù)消息來關(guān)閉工單。如果只有觸發(fā)通知沒有恢復(fù)通知值班人員就得反復(fù)刷新面板確認(rèn)狀態(tài)。夜鶯里開啟恢復(fù)通知后整條告警鏈路就完整了觸發(fā)、通知、恢復(fù)、再通知整個(gè)過程不需要人工介入去確認(rèn)。還有一點(diǎn)權(quán)限和賬號(hào)體系最好在剛開始就規(guī)劃好。夜鶯支持本地賬號(hào)也支持對(duì)接 LDAP/OAuth。如果公司已經(jīng)有統(tǒng)一登錄直接對(duì)接別給每個(gè)運(yùn)維同事單獨(dú)開一堆賬號(hào)。賬號(hào)不及時(shí)回收和權(quán)限過寬是監(jiān)控系統(tǒng)里最容易出安全問題的環(huán)節(jié)這一點(diǎn)我建議所有團(tuán)隊(duì)都重視起來。7. 場景延伸監(jiān)控系統(tǒng)如何支撐低空與邊緣場景7.1 低空監(jiān)控對(duì)基礎(chǔ)設(shè)施的訴求最近“低空監(jiān)控系統(tǒng)”這個(gè)詞熱度很高無人機(jī)、低空飛行器、城市治理相關(guān)的監(jiān)控需求明顯增多。但很多人的第一反應(yīng)是低空監(jiān)控等于雷達(dá)和攝像頭這套專門系統(tǒng)其實(shí)這類系統(tǒng)背后同樣需要一套扎實(shí)的基礎(chǔ)設(shè)施監(jiān)控。無人機(jī)機(jī)巢的電池健康、飛控系統(tǒng)的 CPU 負(fù)載、通訊鏈路的信號(hào)強(qiáng)度、邊緣網(wǎng)關(guān)的網(wǎng)絡(luò)穩(wěn)定性這些數(shù)據(jù)都要被持續(xù)采集和告警。這個(gè)場景對(duì)監(jiān)控系統(tǒng)提出了幾個(gè)要求采集端部署輕量、能跑在邊緣小設(shè)備上數(shù)據(jù)量可能不大但需要統(tǒng)一管理告警要及時(shí)推送到維護(hù)人員的手機(jī)上。這些恰好是夜鶯這類現(xiàn)代化監(jiān)控系統(tǒng)的強(qiáng)項(xiàng)。Categraf 采集器非常輕量可以跑在只有 512M 內(nèi)存的邊緣網(wǎng)關(guān)或工業(yè)盒子上采集到的指標(biāo)通過標(biāo)準(zhǔn)協(xié)議傳到中心端再通過企業(yè)微信、釘釘?shù)惹腊迅婢平o現(xiàn)場維護(hù)團(tuán)隊(duì)。7.2 基于夜鶯擴(kuò)展邊緣監(jiān)控的路線如果你要設(shè)計(jì)一套低空飛行器基礎(chǔ)設(shè)施監(jiān)控方案可以參考這個(gè)思路所有機(jī)巢和無人機(jī)接入點(diǎn)部署 Categraf采集系統(tǒng)級(jí)指標(biāo)CPU、內(nèi)存、磁盤、進(jìn)程狀態(tài)和業(yè)務(wù)級(jí)指標(biāo)設(shè)備電量、充電狀態(tài)、信號(hào)強(qiáng)度、任務(wù)狀態(tài)通過夜鶯統(tǒng)一展示在一張業(yè)務(wù)組的監(jiān)控面板上針對(duì)關(guān)鍵指標(biāo)配置告警規(guī)則。例如當(dāng)某個(gè)機(jī)巢的電池溫度持續(xù)高于閾值或者通訊鏈路丟包率持續(xù)升高夜鶯的告警引擎會(huì)立刻觸發(fā)企業(yè)微信通知值班人員可以在手機(jī)上看到具體是哪個(gè)點(diǎn)位、什么指標(biāo)、多少數(shù)值再?zèng)Q定是否需要遠(yuǎn)程重啟或安排現(xiàn)場處理。這套模式不僅適用于低空監(jiān)控也適用于一切邊緣節(jié)點(diǎn)、IoT 設(shè)備、移動(dòng)基站等分布式基礎(chǔ)設(shè)施場景。還有一個(gè)小建議邊緣設(shè)備的網(wǎng)絡(luò)經(jīng)常不穩(wěn)定Categraf 本地最好開啟磁盤緩沖網(wǎng)絡(luò)恢復(fù)后數(shù)據(jù)能自動(dòng)補(bǔ)傳不會(huì)因?yàn)閿嗑W(wǎng)導(dǎo)致指標(biāo)出現(xiàn)空洞。夜鶯對(duì)斷點(diǎn)補(bǔ)傳的支持雖然不是特別花哨但應(yīng)付邊緣網(wǎng)絡(luò)抖動(dòng)場景已經(jīng)夠用了。實(shí)際部署時(shí)我建議邊緣端和中心端之間盡量建立一條低延遲鏈路否則數(shù)據(jù)延遲會(huì)很影響告警的實(shí)時(shí)性。最后再分享一個(gè)我個(gè)人的體會(huì)。監(jiān)控系統(tǒng)這種東西剛開始接觸時(shí)很容易被各種概念和組件帶偏總覺得功能越多越好、圖表越花哨越好。真正用下來幾年我的標(biāo)準(zhǔn)反而越來越樸素?cái)?shù)據(jù)能不能穩(wěn)定采集、告警能不能在需要的時(shí)候準(zhǔn)確定位、通知能不能到該到的人手里。夜鶯在這三點(diǎn)上做得相當(dāng)扎實(shí)它沒有過多炫技而是把大規(guī)模監(jiān)控里的各種臟活累活安排得明明白白。如果你一直在為 Zabbix 的擴(kuò)展性發(fā)愁或者厭倦了拼湊一堆開源組件來搭建監(jiān)控平臺(tái)不妨從今天這個(gè)部署實(shí)操開始給它一個(gè)機(jī)會(huì)也給自己一個(gè)更省心的運(yùn)維方案。