作為一個常年跟分布式執(zhí)行鏈路打交道的人我對“監(jiān)控大屏”這件事態(tài)度一直很矛盾做淺了就是接幾個圖表把數(shù)據(jù)畫出來老板看一眼就不看了做深了又容易陷進(jìn)具體的組件細(xì)節(jié)里壓根看不到整體。但 Harness 層的 Agent 運(yùn)行狀態(tài)可視化不一樣它是那種“不做不知道做了才覺得真該早做”的基礎(chǔ)工程。這里說的 Harness 層你可以把它理解成任務(wù)調(diào)度和 Agent 執(zhí)行之間的“中間管理層”負(fù)責(zé)統(tǒng)一管理海量 Agent 的生命周期、承接指令下發(fā)、收集執(zhí)行結(jié)果。沒有這層透明化Agent 到底在干嘛、卡在哪、有沒有在空轉(zhuǎn)全憑猜。我在實際經(jīng)歷里最大的體會就是這類監(jiān)控大屏核心不是那張大屏而是“運(yùn)行狀態(tài)可視化的數(shù)據(jù)模型怎么建立”。所以這篇不是講三個大屏模板怎么套用而是從 Harness 層的架構(gòu)邊界、指標(biāo)口徑、數(shù)據(jù)采集鏈路到前端 WebSocket 推送、狀態(tài)漂移的排查把整條思路完整還原一遍。如果你正在做類似的基礎(chǔ)設(shè)施可視化項目或者剛接手 Agent 穩(wěn)定性治理但覺得無從下手這篇應(yīng)該能給你省下不少彎路。1. 項目背景與整體設(shè)計先把監(jiān)控邊界畫清楚1.1 數(shù)據(jù)分層與 Harness 層到底扮演什么角色任何監(jiān)控大屏項目第一步絕對不是選圖表框架而是先弄清楚你要服務(wù)的是哪一層數(shù)據(jù)。一個常見的分布式任務(wù)系統(tǒng)大概可以分成三個層面應(yīng)用服務(wù)層面向用戶的功能比如提交任務(wù)、查看結(jié)果。Harness/調(diào)度管理層負(fù)責(zé)把任務(wù)翻譯成 Agent 可執(zhí)行的指令管理 Agent 注冊、健康檢查、升級、負(fù)載分配。它更像是“監(jiān)工”不直接搬磚但每一塊磚運(yùn)沒運(yùn)到、由誰運(yùn)的它最清楚。Agent 執(zhí)行層真正跑在服務(wù)器上的底層執(zhí)行器執(zhí)行命令、跑模型推理、寫文件、上報狀態(tài)。我們做的 Harness 層監(jiān)控大屏服務(wù)的正是中間這層。當(dāng)時有同事建議把監(jiān)控范圍擴(kuò)大到整條業(yè)務(wù)鏈路被我們攔住了。如果從頁面按鈕一路畫到服務(wù)器 CPU看板必然臃腫最后什么都看不清。既然標(biāo)題寫的是“Harness 層”那最佳口徑就是把 Agent 狀態(tài)、指令分發(fā)情況、Agent 集群健康度作為主體上層業(yè)務(wù)只展示吞吐趨勢底層硬件只留幾個應(yīng)急參考指標(biāo)。1.2 項目真正的目標(biāo)復(fù)現(xiàn)“異常瞬間”而不只是畫圖還有一個設(shè)計層面的問題值得講清楚監(jiān)控大屏和報警平臺有什么不同報警平臺是在出問題時喊你監(jiān)控大屏則是讓你平時就能感知系統(tǒng)正在發(fā)生什么。但更核心的一個目標(biāo)是當(dāng)某類異常出現(xiàn)能通過大屏快速還原出事那一刻的狀態(tài)。比如之前有一次 Agent 批量失聯(lián)當(dāng)時如果只看日志只能知道一條條超時記錄。但大屏上一定要能讓我們一眼看出失聯(lián)是有時間先后順序的還是同時消失的分布在哪些機(jī)器上失聯(lián)前是不是有過大批指令下發(fā)。這種按時間軸回放的 Agent 運(yùn)行狀態(tài)可視化才是大屏項目真正值錢的地方。如果做成純“當(dāng)前在線數(shù)”那種儀表盤就沒有這個復(fù)現(xiàn)現(xiàn)場的能力了。2. 指標(biāo)體系建設(shè)最容易返工卻最沒人重視的環(huán)節(jié)2.1 核心指標(biāo)到底要選哪些為什么是這些確定了大屏邊界后最先要做的是指標(biāo)清單而不是先畫原型。Harness 層最關(guān)鍵的 Agent 運(yùn)行狀態(tài)指標(biāo)我按照自己踩過坑后的經(jīng)驗分成四組生命周期類注冊 Agent 數(shù)、在線 Agent 數(shù)、離線 Agent 數(shù)、啟動中 Agent 數(shù)。用來判斷整個集群的真實規(guī)模。心跳與連接類心跳上報成功率、平均心跳延遲、最近心跳分布。這兩個指標(biāo)能快速區(qū)分網(wǎng)絡(luò)抖動和 Agent 進(jìn)程假死。任務(wù)執(zhí)行類排隊中任務(wù)數(shù)、執(zhí)行中任務(wù)數(shù)、任務(wù)成功率、平均執(zhí)行時長。資源與異常類CPU/內(nèi)存均值、指令超時次數(shù)、異常退出次數(shù)、Agent 版本分布。我們在第一期只做了前三組結(jié)果上線后發(fā)現(xiàn)少了一個關(guān)鍵視角版本分布。有一次新版本 Agent 灰度引入內(nèi)存泄漏老版本都正常新版高負(fù)載時不穩(wěn)定。沒有版本維度的大屏只會看到“某區(qū)域 Agent 在線率下跌”排查很久才定位到是版本問題。所以版本分布這事后期又被塞進(jìn)了大屏的輔助區(qū)域雖然不大但真的救命。2.2 指標(biāo)的采集口徑一個半小時的返工教訓(xùn)指標(biāo)定下來之后更大的坑在于采集口徑。我們當(dāng)時因為多套系統(tǒng)之間的定義不統(tǒng)一吃過很大的虧。具體來說任務(wù)成功率有兩種算法一是從 Harness 的數(shù)據(jù)庫里統(tǒng)計指令狀態(tài)為成功的總數(shù)除以總數(shù)二是從每個 Agent 上報的事件日志里統(tǒng)計成功事件數(shù)除以事件總數(shù)。前者偏向最終狀態(tài)后者偏向過程記錄。由于 Agent 重啟或重試的問題這兩個分母并不一樣一度導(dǎo)致大屏的數(shù)據(jù)和明細(xì)后臺對不上。后來我們固定了一條規(guī)則一切以 Harness 層落庫的“任務(wù)狀態(tài)流轉(zhuǎn)記錄”為唯一數(shù)據(jù)源Agent 上報事件僅作為輔助證據(jù)。到這一步我才理解做可視化項目時圖表美術(shù)只是殼指標(biāo)口徑的一致性才是骨架。每個指標(biāo)在畫上去之前必須寫清它的定義公式、采集源、時間窗口。寧可花一天做指標(biāo)字典也別上線后花一周對數(shù)據(jù)。2.3 標(biāo)簽設(shè)計決定了后續(xù)能怎么“切”在設(shè)計存儲和圖表時要預(yù)先考慮好需要從哪些維度篩選。我建議每個 Agent 運(yùn)行時至少帶上這幾類標(biāo)簽集群/區(qū)域版本號操作系統(tǒng)和架構(gòu)Agent 所在宿主機(jī)或 Pod負(fù)責(zé)的業(yè)務(wù)線有了這些標(biāo)簽大屏的數(shù)據(jù)才能被靈活切片。比如你后來想做一個“按業(yè)務(wù)線查看當(dāng)前 Agent 成功率”的視圖就不需要重新改造上報格式只要查詢時按 label 過濾即可。這套思路和 Prometheus 的時間序列模型很像指標(biāo)名 標(biāo)簽集合就是唯一的時間序列標(biāo)識。3. 數(shù)據(jù)鏈路與實時計算從 Agent 上報到大屏渲染3.1 Agent 主動上報和中心拉取到底選哪個到這里指標(biāo)清單有了接下來是數(shù)據(jù)的“運(yùn)輸問題”。Harness 層和 Agent 之間通常已經(jīng)存在長連接或 HTTP 輪詢。如果是長連接更適合做服務(wù)端推送監(jiān)控如果是短連接可以采集心跳但難以做到精確的在線狀態(tài)。我們的 Agent 選擇的是 MQTT 長連接和 Harness 的 Broker 保持心跳。這樣在線狀態(tài)基本是準(zhǔn)實時的無需再去額外掃描服務(wù)器端口。與之配套的還有一套兜底機(jī)制若 MQTT 通道斷開Agent 本地會緩存最近的任務(wù)執(zhí)行日志恢復(fù)后自動重傳。這在實現(xiàn)監(jiān)控時價值很大因為它能解釋“為什么 Agent 顯示在線但數(shù)據(jù)很久沒更新”的情況。另外有個經(jīng)驗大屏上“Agent 在線數(shù)”統(tǒng)計的并不是 MQTT 的連接數(shù)而是最近 5 分鐘內(nèi)有有效心跳的 Agent 個數(shù)。MQTT 連接可能處于半開狀態(tài)連接沒斷但收不到數(shù)據(jù)如果只看連接數(shù)會掩蓋一部分假死問題。這個規(guī)則我們在數(shù)據(jù)接入層統(tǒng)一處理避免開發(fā)圖表時每個模塊各自寫一套“在線”判斷。3.2 實時計算鏈路選型Kafka 流處理 Redis 時間序列庫畫大屏的數(shù)據(jù)鏈路我最推薦的是下面這條組合拳Agent 通過 MQTT/HTTP 把狀態(tài)上報到 Harness 網(wǎng)關(guān)網(wǎng)關(guān)校驗后寫入 Kafka。使用 Kafka Streams 或者輕量的消費(fèi)者程序?qū)ο⒆銮逑?、聚合計?1 分鐘粒度的心跳成功率、任務(wù)成功率、平均耗時。聚合結(jié)果寫入 Redis用于大屏實時顯示當(dāng)前值和時序數(shù)據(jù)庫用于趨勢圖和歷史回放。大屏服務(wù)端通過 WebSocket 訂閱 Redis 的變更事件推送數(shù)據(jù)到前端。你可能想問為什么不能直接讓大屏查 DataFrame 或者查 MySQL原因很簡單大屏的加載頻率特別高如果每次整屏刷新都打到業(yè)務(wù)庫會給正常業(yè)務(wù)帶來無謂的壓力。Harness 層的數(shù)據(jù)庫必須保證核心寫入性能不能承擔(dān)頻繁聚合查詢的負(fù)擔(dān)。時序庫我們用的是 VictoriaMetrics選它不選別的主要是上線成本極低單機(jī)模式就能扛住每秒幾十萬的指標(biāo)寫入而且兼容 PromQL查詢語法生態(tài)齊全。當(dāng)時也糾結(jié)過要不要直接上 ClickHouse后來想通了我們大屏核心是在線數(shù)和成功率這種流式聚合不是海量明細(xì)的隨意切片分析VictoriaMetrics 的定位更貼合需求。3.3 為什么最終沒有用統(tǒng)一網(wǎng)關(guān)存所有日志第一版架構(gòu)里我心血來潮想把 Agent 執(zhí)行產(chǎn)生的所有日志也走 Kafka 存下來用于“大屏上看日志預(yù)覽”。后來發(fā)現(xiàn)代價很高很容易把大屏這個“狀態(tài)可視化系統(tǒng)”做成一個“日志搜索系統(tǒng)”預(yù)算和精力分配都崩了。想清楚后我們做了個取舍大屏只接收結(jié)構(gòu)化的指標(biāo)和輕量事件比如狀態(tài)變更、任務(wù)開始結(jié)束、異常碼而完整執(zhí)行日志仍走獨(dú)立的文件或日志平臺。監(jiān)控大屏的核心能力是在一堆狀態(tài)里快速發(fā)現(xiàn)異常而不是提供逐行日志閱讀的沉浸體驗。如果想看某異常 Agent 的細(xì)節(jié)在大屏上點擊一個節(jié)點跳轉(zhuǎn)到日志平臺帶參查詢即可沒必要把兩個系統(tǒng)硬揉在一起。4. 大屏前端實現(xiàn)可視化框架選擇與顯示細(xì)節(jié)4.1 可視化圖表庫選型ECharts 為主體Canvas 為輔助到了前端部分這才是很多人印象里的“可視化大屏”工作。我們選型時對比了一陣。主框架用的是 Vue 3這一層因團(tuán)隊熟悉度不同沒有絕對標(biāo)準(zhǔn)。重點是圖表庫我們選擇了 Apache ECharts。理由有三點內(nèi)置地圖和雷達(dá)圖等圖表類型多官方文檔全社區(qū)踩坑案例多在大數(shù)據(jù)量下支持 Canvas 渲染而不是 SVG節(jié)點幾千個時依然流暢。偶爾需要極高性能的節(jié)點拓?fù)鋾r再用 Canvas 手寫繪制比如“全網(wǎng) Agent 連接拓?fù)洹辈⒉皇浅ｉ_而是作為輔助 tab 存在。如果你還在猶豫選 ECharts 還是 AntV我的建議是先看團(tuán)隊更熟悉哪個。它們能力都很強(qiáng)。但如果你可能用到自定義大屏背景和復(fù)雜的飛線效果ECharts 能省不少事如果有比較強(qiáng)烈的統(tǒng)計分析需求AntV 的統(tǒng)計圖表會更順手。4.2 大屏頁面結(jié)構(gòu)設(shè)計狀態(tài)總覽、趨勢、節(jié)點拓?fù)浔O(jiān)控大屏不是一屏展示越多越好。我們做了三塊區(qū)域中央主視圖顯示 Harness 層管理下的 Agent 集群實時在線率配一張按區(qū)域分布的縮略地圖用色階從綠到紅展示健康度。左側(cè)趨勢區(qū)當(dāng)前時刻往前推 24 小時的任務(wù)成功率、心跳延遲變化方便觀察長期趨勢。右側(cè)異常列表區(qū)實時滾動顯示離線 Agent 和高延遲 Agent。為何這樣布局觀察順序是先看整體健康狀態(tài)再橫向?qū)Ρ葧r段趨勢最后下鉆到具體異常實體。我們在實際試運(yùn)行中收到不少好評因為操作人員不用來回切換 Tab 就能完成“感知異?！_認(rèn)范圍—點擊進(jìn)入詳情”三步。4.3 接口推送方案用 WebSocket 代替輪詢在數(shù)據(jù)刷新上高實時大屏最主要的一個經(jīng)驗是不要用 setInterval 每 5 秒拉一次全量接口。否則當(dāng)頁面放大到大屏 4K 分辨率時瀏覽器幀率會明顯掉下來。我們的做法是頁面初載時調(diào)用一次 HTTP 接口拿全量基礎(chǔ)數(shù)據(jù)之后只通過 WebSocket 接收增量推送。每個推送消息帶有自增時間戳前端去重后每 2 秒合并進(jìn)圖表的數(shù)據(jù)集。這樣既減輕后端壓力也讓幀率保持穩(wěn)定。同時WebSocket 自動斷線重連邏輯必須做而且要處理“重連后立即拉取一次全量同步”避免斷線期間圖表數(shù)據(jù)產(chǎn)生空洞。4.4 視覺呈現(xiàn)的細(xì)節(jié)不是越炫越好很多網(wǎng)上的“可視化大屏背景”預(yù)設(shè)第一眼看著很酷但放到業(yè)務(wù)狀態(tài)監(jiān)控上未必合適。大量的漸變、粒子動畫雖然適合展廳大屏卻對日常盯守是一種干擾。我們的取舍原則是只有狀態(tài)異常時使用醒目的紅色或閃爍提醒正常狀態(tài)盡量用偏冷淡的藍(lán)綠色。圖表邊框盡量細(xì)背景使用深色但不必有好幾層光暈。這樣做的目的是讓值班人員掃一眼就能判斷“這個系統(tǒng)是否正?！倍皇敲看味家屑?xì)辨析顏色深淺。5. 實操中避不開的坑狀態(tài)漂移、數(shù)據(jù)不一致與告警疲勞5.1 狀態(tài)漂移顯示的在線和實際不一致在這類監(jiān)控項目中最常見的坑就是“狀態(tài)漂移”。比如大屏顯示 Agent 在線但實際 Agent 已經(jīng)假死不再執(zhí)行任務(wù)。造成這種問題的原因通常是心跳機(jī)制不夠嚴(yán)格。心跳和真實能力無關(guān)一個阻塞在 IO 上的 Agent 依然能發(fā)送心跳。我們在心跳之外增加了“任務(wù)探活”Harness 每 30 秒隨機(jī)選擇少量 Agent 發(fā)送一個輕量級的 ping 指令并要求收到 pong 響應(yīng)。只有心跳成功且最近 ping 響應(yīng)正常的 Agent 才被標(biāo)記為“健康”。大屏上展示的在線率改成健康率比單純在線率更有操作指導(dǎo)意義。5.2 大屏數(shù)據(jù)對不上明細(xì)系統(tǒng)數(shù)據(jù)不一致問題在很多可視化項目里都存在。我們已經(jīng)要求統(tǒng)一指標(biāo)口徑但還有另一個常見來源時間窗口和時區(qū)。比如任務(wù)成功率如果按開始時間聚合那跨天任務(wù)會算到前一天還是后一天不同報表之間會有差異。大屏數(shù)據(jù)與 Excel 報表不一致的問題常有人理解成“大屏顯示錯了”實則不是錯而是聚合維度不同。這次我們專門統(tǒng)一了所有數(shù)據(jù)產(chǎn)品的默認(rèn)口徑窗口按 Agent 任務(wù)結(jié)束時間歸入當(dāng)天統(tǒng)計。這一點建議越早定越好最好在項目的指標(biāo)字典里直接寫明。5.3 監(jiān)控大屏沒人看、報警風(fēng)暴的連鎖反應(yīng)一個獨(dú)立監(jiān)控大屏最容易產(chǎn)后失去價值不是說不再顯示而是大家都習(xí)以為常。上線第一周新鮮感還在到了第四周基本沒人主動看。啟動原因往往是所有該暴露的問題都被告警轟炸過已經(jīng)麻木。我們的應(yīng)對措施是給大屏加了一個“溫和升級”機(jī)制對于離線 Agent按照兩個等級展示一個是瞬時斷連、一個是持續(xù)離線超過 10 分鐘。只有持續(xù)離線才會觸發(fā)嚴(yán)重告警。同時在頁面頂部留出一行“最近 1 小時恢復(fù)”的指標(biāo)讓團(tuán)隊看到我調(diào)整配置后發(fā)生的問題確實在減少形成正向反饋。坦白說這部分已經(jīng)超出了“做圖表”的范疇但正是這種產(chǎn)品化思維讓大屏最終真正成為大家每天開會都會掃一眼的地方。6. 上線后的最佳實踐與遷移擴(kuò)展建議任何平臺都不可能一成不變。Harness 層監(jiān)控大屏跑了一段時間后會有幾個重要的擴(kuò)展方向。其一是做 Agent“狀態(tài)預(yù)測”。我們通過時序庫中保存的歷史數(shù)據(jù)對 Agent 離線趨勢做了簡單回歸預(yù)測比如未來半小時內(nèi)某區(qū)域的 Agent 離線率可能超過閾值系統(tǒng)提前給出預(yù)警。實現(xiàn)思路不復(fù)雜但收益明顯優(yōu)于事后告警。需要注意的是預(yù)測僅適合作為參考不要直接驅(qū)動自動運(yùn)維動作避免誤操作影響業(yè)務(wù)。其二是把可視化能力開放給業(yè)務(wù)方。我們提供了類似 SQL 查詢的 API讓各業(yè)務(wù)線可以自行拉取他們關(guān)心的 Agent 專屬指標(biāo)而不必每個需求都改動大屏。大屏本身只維護(hù)一套統(tǒng)一基線視圖細(xì)節(jié)交給自助分析。第三個和前面說到的實時鏈路相關(guān)如果在當(dāng)前架構(gòu)下 Kafka 消費(fèi)能力成為瓶頸優(yōu)先檢查和調(diào)整分區(qū)數(shù)而不是盲目抬高消費(fèi)線程。出現(xiàn)積壓時在大屏數(shù)據(jù)流上有滯后感卻不能丟數(shù)據(jù)這是我們實際的經(jīng)驗具體分區(qū)策略要按上報量峰值來判斷沒有統(tǒng)一最好的配置只有最匹配當(dāng)下來流量模型的配置。最后提醒一句這種 Harness 層監(jiān)控可視化項目最怕一步到位。第一版可以做概要視圖把在線率、成功率、離線數(shù)這幾個核心指標(biāo)跑通第二版再考慮節(jié)點拓?fù)湎裸@和異常歸類。先把鏈路打通確定數(shù)據(jù)可靠的根后面視覺層的東西都是錦上添花。