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