1. 為什么選SNMP動(dòng)環(huán)平臺(tái)接入溫濕度變送器的方案取舍1.1 這個(gè)項(xiàng)目的實(shí)際場(chǎng)景與初始需求去年我接手了一個(gè)機(jī)房動(dòng)環(huán)平臺(tái)改造項(xiàng)目目標(biāo)是打通全公司27個(gè)機(jī)房的溫濕度監(jiān)測(cè)鏈路。機(jī)房里的動(dòng)環(huán)設(shè)備種類很多UPS、精密空調(diào)、漏水檢測(cè)、煙霧傳感、門禁以及這次重點(diǎn)處理的溫濕度變送器。平臺(tái)側(cè)需要實(shí)時(shí)顯示當(dāng)前溫濕度也要能把歷史數(shù)據(jù)調(diào)取出來(lái)支撐后續(xù)的故障追溯和能耗分析。項(xiàng)目最開(kāi)始的卡點(diǎn)不在平臺(tái)而在設(shè)備接入現(xiàn)場(chǎng)溫濕度變送器有十幾種型號(hào)廠家接口五花八門有的走RS485串口有的走以太網(wǎng)私有協(xié)議還有一批是早年搭的SNMP老設(shè)備。需求拆開(kāi)看其實(shí)很樸素每個(gè)機(jī)房部署若干溫濕度變送器平臺(tái)能夠周期性讀到溫度、濕度兩個(gè)值并把帶時(shí)間戳的數(shù)據(jù)寫(xiě)入歷史庫(kù)上層頁(yè)面能按時(shí)間范圍拉取歷史記錄也能按小時(shí)、按天聚合出趨勢(shì)曲線。聽(tīng)起來(lái)不復(fù)雜但真正動(dòng)手時(shí)才發(fā)現(xiàn)動(dòng)環(huán)平臺(tái)開(kāi)發(fā)里最耗時(shí)間的往往不是頁(yè)面和數(shù)據(jù)庫(kù)而是設(shè)備接入層那些“看起來(lái)一個(gè)樣、實(shí)際每家都不一樣”的通信協(xié)議。這個(gè)項(xiàng)目的轉(zhuǎn)折點(diǎn)是SNMP協(xié)議。機(jī)房里有大量網(wǎng)絡(luò)設(shè)備已經(jīng)支持SNMP而相當(dāng)一部分溫濕度變送器也把SNMP作為標(biāo)準(zhǔn)接口。統(tǒng)一走SNMP之后采集端的代碼不再需要為每個(gè)廠家單獨(dú)維護(hù)一套私有協(xié)議解析平臺(tái)面對(duì)的是一棵規(guī)范化的MIB樹(shù)OID、數(shù)據(jù)類型、單位換算都變得可預(yù)期。這篇文章就把我當(dāng)時(shí)調(diào)通SNMP調(diào)取溫濕度變送器歷史數(shù)據(jù)的完整過(guò)程寫(xiě)下來(lái)包括踩過(guò)的坑和最后沉淀下來(lái)的設(shè)計(jì)思路。1.2 有線串口、Modbus、SNMP三種路線的對(duì)比接入動(dòng)環(huán)設(shè)備常見(jiàn)有三條技術(shù)路線RS485總線上的Modbus RTU、以太網(wǎng)上的私有TCP/JSON接口、以及通用性最強(qiáng)的SNMP。很多老機(jī)房喜歡用RS485串口方案現(xiàn)場(chǎng)布線簡(jiǎn)單變送器便宜一條總線能掛幾十個(gè)設(shè)備但這套方案在平臺(tái)化接入時(shí)非常痛苦。每個(gè)串口對(duì)應(yīng)一臺(tái)采集器平臺(tái)要管理這么多串口鏈路還要處理輪詢時(shí)序總線設(shè)備太多時(shí)一輪查詢可能要十幾秒任何一臺(tái)設(shè)備無(wú)響應(yīng)都會(huì)拖慢整條總線。而且Modbus的設(shè)備地址、寄存器表、數(shù)據(jù)精度全靠設(shè)備手冊(cè)不同廠家的寄存器映射完全不一致解析層工作量很大。私有TCP/JSON接口是很多新式智能傳感器廠家的做法HTTP方式最直觀平臺(tái)側(cè)發(fā)一次請(qǐng)求拿一個(gè)JSON里面有溫度、濕度、電量、固件版本等字段開(kāi)發(fā)效率確實(shí)高。但問(wèn)題在于沒(méi)有標(biāo)準(zhǔn)每家字段命名都不一樣字段取值單位也不一致項(xiàng)目里接十種設(shè)備就得寫(xiě)十套適配器。對(duì)于動(dòng)環(huán)平臺(tái)這種需要長(zhǎng)期維護(hù)的系統(tǒng)私有協(xié)議越多后面升級(jí)和擴(kuò)展的隱性成本越高。SNMP作為網(wǎng)絡(luò)管理領(lǐng)域的標(biāo)準(zhǔn)協(xié)議最大優(yōu)勢(shì)是統(tǒng)一了“被管設(shè)備的資源描述”。不管是交換機(jī)、UPS還是溫濕度變送器只要實(shí)現(xiàn)SNMP Agent平臺(tái)側(cè)就用一套snmpget、snmpwalk邏輯去訪問(wèn)。MIB文件定義了每個(gè)計(jì)數(shù)器或傳感器值的OID、數(shù)據(jù)類型和讀寫(xiě)屬性即使不同品牌OID不同解析框架是一樣的。三年前我還會(huì)為每個(gè)設(shè)備單獨(dú)寫(xiě)連接類現(xiàn)在SNMP設(shè)備的接入工作已經(jīng)壓縮到只改配置文件的OID映射和單位換算規(guī)則。做過(guò)對(duì)比之后這個(gè)項(xiàng)目里我優(yōu)先把所有支持SNMP的溫濕度變送器統(tǒng)一接到SNMP通道不支持SNMP的老舊串口設(shè)備再通過(guò)串口網(wǎng)關(guān)轉(zhuǎn)成SNMP透?jìng)?。用SNMP作為中間層平臺(tái)側(cè)只面對(duì)一套協(xié)議后面設(shè)備擴(kuò)容時(shí)能省下大量改動(dòng)時(shí)間。1.3 我最終定下的接入架構(gòu)整個(gè)接入鏈路分四層。最下面是溫濕度變送器它們內(nèi)部有溫濕度探頭然后把測(cè)量值映射到SNMP OID上。中間是接入層支持SNMP Agent的變送器直接進(jìn)網(wǎng)線純RS485型變送器則先接到串口服務(wù)器或工業(yè)網(wǎng)關(guān)由網(wǎng)關(guān)輪詢Modbus寄存器再把數(shù)據(jù)以SNMP Agent方式暴露給上層。第三層是采集服務(wù)部署在一臺(tái)Linux服務(wù)器上通過(guò)SNMP協(xié)議周期性讀取各設(shè)備的溫濕度OID做單位換算、異常值過(guò)濾后寫(xiě)入歷史數(shù)據(jù)庫(kù)。最上層才是動(dòng)環(huán)平臺(tái)本身包含實(shí)時(shí)數(shù)據(jù)看板、歷史查詢接口、告警規(guī)則引擎。這里需要提前決策的一個(gè)點(diǎn)是歷史數(shù)據(jù)的存儲(chǔ)平臺(tái)初期規(guī)模不大我選的是MySQL/MariaDB用獨(dú)立歷史表存原始點(diǎn)位數(shù)據(jù)后續(xù)如果點(diǎn)位量變大再平滑遷移到時(shí)序數(shù)據(jù)庫(kù)。SNMP這條鏈路里最需要理解的是OID的樹(shù)形結(jié)構(gòu)。整個(gè)MIB以1.3.6.1為根往下有interfaces、enterprises等分支廠商自定義的信息通常掛在enterprises私有節(jié)點(diǎn)下。溫濕度變送器的具體OID一般由廠商預(yù)置到固件里平臺(tái)側(cè)只要配置好每個(gè)設(shè)備對(duì)應(yīng)的溫度OID、濕度OID就能讀數(shù)。動(dòng)環(huán)平臺(tái)開(kāi)發(fā)實(shí)錄里最典型的一天工作不是在寫(xiě)復(fù)雜算法而是反復(fù)核對(duì)設(shè)備手冊(cè)里的OID表和實(shí)際返回的原始值類型。2. 和設(shè)備對(duì)上話從MIB文件到OID解析2.1 snmpwalk這一步能省則省但別跳接入SNMP設(shè)備時(shí)我習(xí)慣先在服務(wù)器上用命令行工具把設(shè)備“底朝天”摸一遍而不是直接讀手冊(cè)就寫(xiě)代碼。這個(gè)習(xí)慣幫我避開(kāi)了很多廠商手冊(cè)寫(xiě)得含糊不清的坑。拿到一臺(tái)新變送器我會(huì)先看它的IP、SNMP版本、Community字符串只讀的一般是public也有改成監(jiān)控專用字符串的然后用snmpwalk做一次全樹(shù)遍歷。命令格式大致是這樣snmpwalk -v 2c -c public -On 192.168.10.101 device_full_walk.txt關(guān)鍵參數(shù)有三個(gè)-v 2c表示SNMP版本-c public是Community授權(quán)字符串-On要求輸出帶完整的OID數(shù)字路徑不要只顯示縮寫(xiě)名稱。全樹(shù)遍歷結(jié)果會(huì)生成一個(gè)文本文件幾十到幾百行不等。這份文件有多少行基本上就是這個(gè)設(shè)備暴露出來(lái)的全部可讀信息。溫濕度變送器一般還會(huì)暴露設(shè)備名稱、固件版本、序列號(hào)、當(dāng)前溫度、當(dāng)前濕度、報(bào)警狀態(tài)這些OID。不少工程師會(huì)跳過(guò)這一步直接按照設(shè)備清單里給的那幾個(gè)OID開(kāi)始寫(xiě)采集代碼。這么做短期沒(méi)問(wèn)題但一旦設(shè)備返回的數(shù)據(jù)跟預(yù)期不符你會(huì)因?yàn)闆](méi)有參考基線而無(wú)從排查。snmpwalk輸出的原始文件里有時(shí)能看到廠商額外暴露的OID比如“本機(jī)溫度校準(zhǔn)偏差”“濕度零點(diǎn)漂移補(bǔ)償值”這些信息對(duì)后期數(shù)據(jù)維護(hù)很有用。設(shè)備說(shuō)明書(shū)給出的OID可能是符號(hào)名比如tempHumidityTemperature但程序里真正要用的是數(shù)字OID路徑。因?yàn)椴煌瑥S商的MIB符號(hào)名可能相同數(shù)字路徑不會(huì)歧義。用snmpwalk -On一次就能把符號(hào)名和數(shù)字路徑的對(duì)應(yīng)關(guān)系拿到我通常會(huì)把這個(gè)映射存進(jìn)設(shè)備檔案表避免以后忘了哪個(gè)數(shù)字OID對(duì)應(yīng)哪個(gè)物理量。2.2 數(shù)據(jù)類型的坑整數(shù)、浮點(diǎn)、編碼換算一個(gè)都不能漏SNMP協(xié)議本身只定義了有限的類型體系。實(shí)際調(diào)溫濕度數(shù)據(jù)時(shí)最常見(jiàn)的返回類型是INTEGER、Unsigned32、OCTET STRING也有部分設(shè)備返回Float類型的OID。為什么說(shuō)這里是重災(zāi)區(qū)因?yàn)椴煌瑥S商對(duì)同一個(gè)物理量的編碼方式可能完全不同。同一臺(tái)設(shè)備上溫度返回的原始值可能是325而設(shè)備文檔里寫(xiě)“溫度乘以10”那么真實(shí)溫度就是32.5攝氏度。濕度返回456乘0.1得到45.6%RH。但另一家設(shè)備溫度返回的是32.5直接用Float類型更折騰的情況是OCTET STRING里塞了一個(gè)ASCII字符串比如32.5 C你還要做字符串截取。我踩過(guò)的一次尷尬事故某批次設(shè)備的濕度OID返回整數(shù)比如299文檔寫(xiě)單位是0.1%RH結(jié)果我按%RH直接入庫(kù)導(dǎo)致平臺(tái)上濕度顯示299%自然觸發(fā)了告警風(fēng)暴。當(dāng)時(shí)整個(gè)動(dòng)環(huán)平臺(tái)連續(xù)半夜報(bào)警排查了一圈才發(fā)現(xiàn)是換算系數(shù)沒(méi)生效。后來(lái)我養(yǎng)成了一個(gè)硬性習(xí)慣任何新增SNMP點(diǎn)位入網(wǎng)前必須在測(cè)試環(huán)境用真實(shí)設(shè)備驗(yàn)證原始值、換算公式、最終展示值三層數(shù)據(jù)。建議數(shù)據(jù)類型和換算規(guī)則一定要進(jìn)配置。我會(huì)在設(shè)備Profile里定義字段oid_temperature: 1.3.6.1.4.1.xxxxx.1.3.1.1.5.0temperature_type: INTEGERtemperature_factor: 0.1temperature_unit: C。采集服務(wù)讀配置而不是硬編碼這樣新增一批設(shè)備時(shí)只需在數(shù)據(jù)庫(kù)里多插一條記錄不用改代碼再發(fā)版。2.3 一個(gè)真實(shí)的OID解析案例以我項(xiàng)目中較多的一批設(shè)備為例廠商MIB把傳感器信息放在enterprises私有節(jié)點(diǎn)下溫度OID通常是1.3.6.1.4.1.5000.1.3.1.1.5.0濕度OID對(duì)應(yīng)1.3.6.1.4.1.5000.1.3.1.1.6.0用snmpget驗(yàn)證snmpget -v 2c -c public -On 192.168.10.101 1.3.6.1.4.1.5000.1.3.1.1.5.0返回.1.3.6.1.4.1.5000.1.3.1.1.5.0 INTEGER: 312這表示當(dāng)前溫度原始值是312按手冊(cè)換算除以10得到31.2℃。濕度OID返回INTEGER: 578按除以10得到57.8%RH。單臺(tái)設(shè)備驗(yàn)證通過(guò)后我會(huì)連讀幾輪確認(rèn)返回值是否穩(wěn)定波動(dòng)然后才接入采集服務(wù)。如果設(shè)備返回的是OCTET STRING: 31.2那就需要先判斷編碼方式再?zèng)Q定是由采集端轉(zhuǎn)數(shù)值還是直接給上層面板解析字符串。這里有個(gè)細(xì)節(jié)值得注意OID最后的.0代表標(biāo)量對(duì)象實(shí)例。如果廠商在MIB里定義的是表格類型比如多個(gè)傳感器做成一張表那遍歷時(shí)會(huì)出現(xiàn)不同的最后一位索引這時(shí)候就要用snmpwalk把整張表列出來(lái)再按傳感器序號(hào)去匹配。溫濕度變送器通常只有一個(gè)測(cè)量點(diǎn)標(biāo)量OID也就夠了但多探頭設(shè)備或者帶多個(gè)傳感器節(jié)點(diǎn)的采集器往往就需要按索引循環(huán)讀取。3. 歷史數(shù)據(jù)鏈路輪詢采集、入庫(kù)與規(guī)范化3.1 輪詢調(diào)度設(shè)計(jì)頻率、超時(shí)與重試拿到設(shè)備OID和數(shù)據(jù)類型后下一步就是把“讀一次”變成“持續(xù)讀”。動(dòng)環(huán)平臺(tái)的實(shí)時(shí)性要求不算高溫度濕度的變化本身是慢變量我最終把輪詢周期定為30秒。這里需要解釋一下為什么不是5秒或10秒SNMP是UDP承載的輪詢頻率越高網(wǎng)絡(luò)包越多設(shè)備單板CPU和平臺(tái)服務(wù)器壓力都會(huì)上來(lái)而30秒粒度已經(jīng)足夠覆蓋空調(diào)故障導(dǎo)致的溫度跳變、機(jī)房熱區(qū)波動(dòng)等絕大多數(shù)場(chǎng)景歷史數(shù)據(jù)體積也能控制住。采集服務(wù)我用Python寫(xiě)。每個(gè)采集周期會(huì)并發(fā)發(fā)起所有設(shè)備的SNMP請(qǐng)求。輪詢服務(wù)里最重要的設(shè)計(jì)是超時(shí)和重試策略。snmpget默認(rèn)超時(shí)1秒、重試5次在動(dòng)環(huán)場(chǎng)景下太激進(jìn)設(shè)備偶爾因?yàn)轫憫?yīng)慢導(dǎo)致單次輪詢被拖成好幾秒后續(xù)積壓任務(wù)會(huì)越來(lái)越多。我把超時(shí)設(shè)為1.5秒重試2次失敗后本輪不再?gòu)?qiáng)求標(biāo)記該點(diǎn)位為異常等待下一輪周期自然恢復(fù)。這樣既減少了無(wú)效請(qǐng)求數(shù)量又能保證異常告警在1分鐘內(nèi)觸發(fā)。調(diào)度上用了輕量級(jí)的調(diào)度框架核心邏輯是每30秒觸發(fā)一次批量采集任務(wù)。批量采集內(nèi)部用線程池并發(fā)讀取設(shè)備例如27個(gè)機(jī)房包括變送器在內(nèi)總共120個(gè)SNMP點(diǎn)位一輪完成時(shí)間基本能控制在3秒以內(nèi)。單點(diǎn)輪詢的最長(zhǎng)等待時(shí)間是超時(shí)加上重試時(shí)間約4.5秒線程池并行處理不會(huì)互相阻塞整體輪詢節(jié)奏非常穩(wěn)定。需要特別提示的是SNMP版本選擇。SNMP v1和v2c走Community字符串認(rèn)證v3支持用戶名密碼和加密。設(shè)備如果支持v3建議優(yōu)先用v3配合私網(wǎng)隔離可以做到比較可靠的安全閉環(huán)。如果設(shè)備只支持v1/v2c那么必須把訪問(wèn)控制在內(nèi)部監(jiān)控網(wǎng)段不要跨公網(wǎng)直接暴露。3.2 數(shù)據(jù)入庫(kù)與歷史表結(jié)構(gòu)劃分歷史數(shù)據(jù)調(diào)取的前提是先把數(shù)據(jù)存得有條理。我設(shè)計(jì)歷史表時(shí)沒(méi)有把所有類型點(diǎn)位塞進(jìn)一張“通用值表”雖然那樣擴(kuò)展性看上去很強(qiáng)但查詢溫濕度歷史時(shí)會(huì)因?yàn)橐^(guò)濾point_type產(chǎn)生很多無(wú)效掃描。最終方案是專門建一張溫濕度歷史表字段如下CREATE TABLE temp_humi_history ( id BIGINT AUTO_INCREMENT PRIMARY KEY, device_id VARCHAR(32) NOT NULL, collect_time DATETIME NOT NULL, temperature DECIMAL(5,2) NULL, humidity DECIMAL(5,2) NULL, status TINYINT NOT NULL DEFAULT 1, UNIQUE KEY uk_device_time (device_id, collect_time) );status字段很關(guān)鍵1表示正常0表示該輪讀取失敗或者設(shè)備掉線。為什么即使讀取失敗也要插入一條記錄因?yàn)榍岸水?huà)時(shí)間序列曲線時(shí)如果某個(gè)時(shí)間點(diǎn)沒(méi)有數(shù)據(jù)圖表會(huì)留白如果插入一條status0的記錄前端可以明確把該時(shí)段標(biāo)記為斷線或異常。平臺(tái)頁(yè)面上看到“這段時(shí)間沒(méi)有數(shù)據(jù)”和“這段時(shí)間設(shè)備告警離線”是兩個(gè)等級(jí)的問(wèn)題前者會(huì)被誤認(rèn)為機(jī)房一直正常后者才符合動(dòng)環(huán)平臺(tái)的監(jiān)控語(yǔ)義。入庫(kù)采用批量寫(xiě)入方式。單個(gè)輪詢周期內(nèi)積累的幾百條記錄一次性executemany插入而不是一條一條插入。MySQL對(duì)批量插入的吞吐量遠(yuǎn)高于單條插入而且減少了連接開(kāi)銷。隨著點(diǎn)位數(shù)量增長(zhǎng)歷史表建議按月分表或按季度分區(qū)。我當(dāng)時(shí)的方案是保留最新3個(gè)月的30秒原始數(shù)據(jù)更老的數(shù)據(jù)會(huì)由定時(shí)任務(wù)聚合到5分鐘/1小時(shí)統(tǒng)計(jì)表原始表按時(shí)間分區(qū)定期清理避免單表無(wú)限膨脹。3.3 時(shí)區(qū)、庫(kù)存檔和補(bǔ)傳機(jī)制動(dòng)環(huán)平臺(tái)歷史數(shù)據(jù)最容易被忽略的問(wèn)題之一是時(shí)間戳。設(shè)備本身沒(méi)有時(shí)區(qū)概念返回?cái)?shù)據(jù)也不帶UTC偏移。如果采集服務(wù)沒(méi)處理好跨過(guò)夏令時(shí)或者部署在不同時(shí)區(qū)的服務(wù)器上歷史曲線的對(duì)齊就會(huì)出問(wèn)題。我的做法是采集服務(wù)統(tǒng)一使用服務(wù)器本地時(shí)間生成collect_time數(shù)據(jù)庫(kù)連接串固定時(shí)區(qū)接口層輸出時(shí)明確要求前端按指定時(shí)區(qū)解析。所有歷史查詢都以collect_time為基準(zhǔn)不允許客戶端傳一個(gè)“其他時(shí)間”再讓數(shù)據(jù)庫(kù)做時(shí)區(qū)轉(zhuǎn)換。另一個(gè)現(xiàn)實(shí)問(wèn)題是SNMP請(qǐng)求偶爾會(huì)整體超時(shí)尤其是現(xiàn)場(chǎng)網(wǎng)線松動(dòng)或者中繼網(wǎng)關(guān)重啟時(shí)。如果不能把這段時(shí)間的數(shù)據(jù)補(bǔ)回來(lái)歷史庫(kù)就會(huì)有空洞。我實(shí)現(xiàn)了一個(gè)補(bǔ)傳隊(duì)列每個(gè)輪詢周期結(jié)束后正常的記錄直接寫(xiě)庫(kù)失敗的點(diǎn)位進(jìn)入內(nèi)存隊(duì)列在后繼輪詢周期里插入補(bǔ)讀任務(wù)。補(bǔ)傳策略是“只補(bǔ)最近N個(gè)周期最多補(bǔ)15分鐘”。超過(guò)15分鐘不補(bǔ)說(shuō)明設(shè)備持續(xù)離線此時(shí)空檔就交給狀態(tài)字段去表達(dá)不再硬補(bǔ)。這個(gè)取舍很重要無(wú)限制補(bǔ)傳會(huì)把采集服務(wù)拖進(jìn)歷史欠賬的泥潭特別是長(zhǎng)時(shí)間離線場(chǎng)景下設(shè)備恢復(fù)瞬間積壓幾百個(gè)補(bǔ)讀任務(wù)反而把正常輪詢擠掉。動(dòng)環(huán)平臺(tái)開(kāi)發(fā)到歷史數(shù)據(jù)階段真正產(chǎn)生價(jià)值的往往不是“把數(shù)據(jù)查出來(lái)”而是“把缺失和異常表達(dá)清楚”。補(bǔ)傳機(jī)制保證的是常規(guī)情況下的完整度status字段保證的是異常情況下的透明度。這兩樣配齊歷史數(shù)據(jù)調(diào)取才有質(zhì)量可言。4. 歷史數(shù)據(jù)調(diào)取的幾個(gè)現(xiàn)實(shí)問(wèn)題4.1 查詢接口的設(shè)計(jì)歷史數(shù)據(jù)調(diào)取在平臺(tái)側(cè)體現(xiàn)為一個(gè)HTTP查詢接口。接口設(shè)計(jì)上我盡量讓它“一次查得完查完能直接用”。最基礎(chǔ)的能力是給定設(shè)備、起止時(shí)間返回原始記錄但前端畫(huà)圖不可能一次把幾萬(wàn)條原始點(diǎn)全拉走所以接口必須支持聚合。聚合查詢的核心參數(shù)是interval單位有raw、1m、5m、1h、1d。當(dāng)intervalraw時(shí)直接查原始30秒數(shù)據(jù)為聚合模式時(shí)按時(shí)間段做平均值、最大值、最小值三要素聚合。比如查詢某一天某個(gè)機(jī)房的溫度趨勢(shì)接口返回每小時(shí)內(nèi)的均值、最高溫度、最低溫度前端畫(huà)帶波動(dòng)范圍的趨勢(shì)線非常方便。SQL上利用MySQL的日期函數(shù)做時(shí)間桶分組。接口參數(shù)我做得比較嚴(yán)start_time和end_time必填時(shí)間跨度最大限制為31天防止有人一次性導(dǎo)出整個(gè)數(shù)據(jù)庫(kù)導(dǎo)致服務(wù)端卡死。導(dǎo)出CSV功能單獨(dú)做異步任務(wù)避免同步響應(yīng)超時(shí)。動(dòng)環(huán)平臺(tái)的使用者通常是運(yùn)維人員和設(shè)施管理崗他們更關(guān)注某個(gè)時(shí)間段的溫度曲線、高溫時(shí)段、空調(diào)設(shè)備異常前后的溫升趨勢(shì)所以查詢條件里我額外支持了“過(guò)濾異常狀態(tài)記錄”的開(kāi)關(guān)默認(rèn)開(kāi)啟查詢結(jié)果只展示status1的正常數(shù)據(jù)。4.2 歷史數(shù)據(jù)的精度損失與存儲(chǔ)策略歷史數(shù)據(jù)調(diào)取時(shí)最容易被忽略的是精度問(wèn)題。SNMP原始值換算成溫度后可能是31.23333這樣的浮點(diǎn)數(shù)但數(shù)據(jù)庫(kù)字段我用的是DECIMAL(5,2)。這里有兩個(gè)選擇保持原始浮點(diǎn)數(shù)或者按兩位小數(shù)入賬。我最終選擇了兩位小數(shù)理由是溫濕度變送器本身的測(cè)量精度通常在正負(fù)0.3度左右傳感器探頭精度都不夠高存更多小數(shù)位沒(méi)有實(shí)際意義。不過(guò)這個(gè)取舍在下游分析場(chǎng)景會(huì)帶來(lái)一個(gè)問(wèn)題每天聚合的平均值如果基于四舍五入后的值再計(jì)算累計(jì)誤差會(huì)稍微變大。比如原始值31.25和31.35分別存成31.25和31.35還能接受但如果變成31.3和31.4聚合平均就會(huì)偏掉0.025。我是這樣處理的原始?xì)v史表里保留DECIMAL(5,4)上層展示和聚合時(shí)統(tǒng)一四舍五入到兩位。也就是原始精度保留足夠查詢結(jié)果做展示精度。調(diào)取歷史數(shù)據(jù)時(shí)很多團(tuán)隊(duì)只看見(jiàn)了可讀性沒(méi)意識(shí)到把精度損失在入庫(kù)這一層后面分析系統(tǒng)再想找回原始數(shù)據(jù)就難了。存儲(chǔ)周期也需要根據(jù)數(shù)據(jù)用途定清楚。30秒原始數(shù)據(jù)保留3個(gè)月左右5分鐘聚合數(shù)據(jù)保留1年1小時(shí)聚合數(shù)據(jù)保留3年。這樣前端的“近一周詳細(xì)曲線”能精確到每個(gè)采樣點(diǎn)半年趨勢(shì)圖則用聚合數(shù)據(jù)不需要掃描全量原始表。歸檔任務(wù)在凌晨低峰期執(zhí)行把過(guò)期原始數(shù)據(jù)刪除。生產(chǎn)成本和數(shù)據(jù)價(jià)值之間的平衡是所有動(dòng)環(huán)平臺(tái)都會(huì)遇到的我建議在初始階段就設(shè)計(jì)好別等項(xiàng)目跑了一年后發(fā)現(xiàn)歷史表幾個(gè)億行才后悔。4.3 從“調(diào)得到”到“調(diào)得對(duì)”數(shù)據(jù)校驗(yàn)?zāi)苷{(diào)出數(shù)據(jù)只是一個(gè)開(kāi)始“調(diào)得對(duì)”才是動(dòng)環(huán)平臺(tái)真正要解決的。歷史數(shù)據(jù)常見(jiàn)的臟數(shù)據(jù)有幾類設(shè)備讀數(shù)為0本質(zhì)是傳感器故障但采集鏈路正常數(shù)據(jù)跳變比如濕度從40%突然變成99%下一輪又回到40%長(zhǎng)時(shí)間恒定可能是探頭凍結(jié)或者A/D采樣異常。我插入數(shù)據(jù)前會(huì)做簡(jiǎn)單合理性校驗(yàn)溫度范圍-40到85度濕度范圍0到100%RH超出直接按異常處理在status中標(biāo)記可疑。對(duì)于跳變判斷我沒(méi)有在入庫(kù)時(shí)做太復(fù)雜的邏輯因?yàn)楝F(xiàn)場(chǎng)數(shù)據(jù)本來(lái)就可能瞬時(shí)突變誤判反而麻煩這部分交給告警側(cè)做持續(xù)N輪超過(guò)閾值再觸發(fā)。歷史數(shù)據(jù)調(diào)取時(shí)還有一個(gè)容易踩的坑設(shè)備掉線后重新上線如果只回補(bǔ)一部分周期因?yàn)樵O(shè)備內(nèi)部時(shí)鐘不準(zhǔn)補(bǔ)過(guò)來(lái)的數(shù)據(jù)時(shí)間戳可能是亂的。我遇到過(guò)一次很典型的一臺(tái)變送器離線半小時(shí)后網(wǎng)絡(luò)恢復(fù)采集服務(wù)補(bǔ)讀到了數(shù)據(jù)但設(shè)備把時(shí)間戳寫(xiě)成了剛上電時(shí)的時(shí)間導(dǎo)致歷史表里出現(xiàn)同一設(shè)備時(shí)間倒流的記錄。我的辦法是入庫(kù)時(shí)以采集服務(wù)器時(shí)間為準(zhǔn)完全忽略設(shè)備內(nèi)部時(shí)間戳同時(shí)寫(xiě)入collected_at和insert_time兩個(gè)字段前者用于業(yè)務(wù)查詢后者用于排查入庫(kù)延遲。代碼層面調(diào)取歷史數(shù)據(jù)時(shí)也不應(yīng)該無(wú)條件信任數(shù)據(jù)庫(kù)里的所有記錄。我在查詢接口里增加了一個(gè)預(yù)處理層如果某條記錄status為正常但相鄰兩條記錄間隔異常超過(guò)3個(gè)輪詢周期會(huì)把這段區(qū)間標(biāo)記為“存在缺失”。前端圖例里用虛線段表達(dá)而不去偽造一條平滑曲線。這樣業(yè)務(wù)側(cè)既能看到完整趨勢(shì)又能識(shí)別出哪些區(qū)間是真實(shí)的、哪些是推斷的從數(shù)據(jù)倫理上也更干凈。5. 現(xiàn)場(chǎng)運(yùn)維中踩過(guò)的坑和壓箱底經(jīng)驗(yàn)5.1 設(shè)備重啟后OID路徑變了SNMP設(shè)備接入中最詭異的問(wèn)題是同一型號(hào)設(shè)備固件版本升級(jí)后OID路徑發(fā)生變化。我有一次晚上巡檢發(fā)現(xiàn)某臺(tái)變送器溫度一直讀到127度直接把機(jī)房打進(jìn)了高溫告警。排查半天發(fā)現(xiàn)那臺(tái)設(shè)備前一天剛被現(xiàn)場(chǎng)人員升級(jí)過(guò)固件原來(lái)溫度OID返回的值在新固件里變成了內(nèi)部傳感器編號(hào)真正的溫度OID向后挪了一級(jí)。這種情況你沒(méi)法寫(xiě)“萬(wàn)能兼容”只能靠監(jiān)控臺(tái)賬每次設(shè)備固件變更后跑一次snmpwalk對(duì)比OID基線有變化自動(dòng)告警。動(dòng)環(huán)平臺(tái)的歷史數(shù)據(jù)可追溯性很大程度取決于設(shè)備臺(tái)賬維護(hù)得是否及時(shí)。5.2 跨品牌設(shè)備兼容性動(dòng)環(huán)現(xiàn)場(chǎng)很少只用一家設(shè)備。不同廠家的溫濕度變送器溫度和濕度OID經(jīng)常完全不一樣數(shù)據(jù)類型和單位也有差異。我在配置里維護(hù)了一個(gè)設(shè)備類型表每種類型綁定一套OID Profile。平臺(tái)采集時(shí)按設(shè)備類型取配置而不是按具體設(shè)備逐臺(tái)硬編碼。這樣新增同型號(hào)設(shè)備只是錄入一條新設(shè)備記錄新品牌則加一種Profile采集服務(wù)代碼始終不變。跨品牌兼容更隱蔽的問(wèn)題是SNMP OID的返回精度不同。同樣表示26.5度A廠家返回265B廠家返回26.5C廠家返回2650。我的采集服務(wù)在解析時(shí)統(tǒng)一按Profile里的factor字段處理A、C兩家的factor分別為0.1、0.001B家factor為1。這條規(guī)則看起來(lái)簡(jiǎn)單但前端頁(yè)面展示時(shí)如果不按這個(gè)factor二次換算就會(huì)出現(xiàn)某些設(shè)備溫度正常、某些設(shè)備溫度差了10倍的情況。建議做個(gè)自動(dòng)煙霧測(cè)試平臺(tái)新接入設(shè)備后和現(xiàn)場(chǎng)標(biāo)準(zhǔn)溫濕度計(jì)比對(duì)一次誤差在合理范圍內(nèi)才算上線。5.3 針對(duì)動(dòng)環(huán)平臺(tái)的整體穩(wěn)定性建議動(dòng)環(huán)平臺(tái)不像互聯(lián)網(wǎng)業(yè)務(wù)那樣追求高并發(fā)但它的長(zhǎng)期穩(wěn)定性要求很高。我把穩(wěn)定性經(jīng)驗(yàn)總結(jié)為三條。第一采集服務(wù)必須守護(hù)進(jìn)程化并自帶看門狗不能因?yàn)橐淮挝床东@異常就退出。SNMP網(wǎng)絡(luò)包是UDP和服務(wù)器多線程并發(fā)時(shí)偶爾會(huì)出現(xiàn)socket超時(shí)異常代碼里必須對(duì)所有snmpget/walk操作做完整異常捕獲異常只影響單個(gè)點(diǎn)位不影響整輪采集。第二告警系統(tǒng)要基于真實(shí)讀數(shù)的連續(xù)N次判斷而不是單次讀數(shù)立刻告警。溫度瞬時(shí)竄高有可能是設(shè)備自身干擾連續(xù)三次都高才說(shuō)明現(xiàn)場(chǎng)確實(shí)異常。這個(gè)去抖機(jī)制避免了不少半夜被誤報(bào)告警叫醒的情況。第三定期用標(biāo)準(zhǔn)溫度計(jì)現(xiàn)場(chǎng)比對(duì)溫濕度變送器的讀數(shù)。SNMP鏈路再穩(wěn)定傳感器探頭本身也會(huì)漂移一般建議每半年或一年校準(zhǔn)一次。動(dòng)環(huán)平臺(tái)的歷史數(shù)據(jù)質(zhì)量最底層依賴的還是傳感器測(cè)量精度這一層失守上面協(xié)議再標(biāo)準(zhǔn)、存儲(chǔ)再好出來(lái)的也是精準(zhǔn)的錯(cuò)誤。最后想分享一個(gè)小技巧我在每臺(tái)接入設(shè)備的歷史記錄里都會(huì)保留首次入網(wǎng)時(shí)的OID基線walk文件和配置快照。后期無(wú)論是更換備件、升級(jí)固件還是排查抖動(dòng)都能快速對(duì)比出“設(shè)備還是不是當(dāng)初那臺(tái)設(shè)備”。這個(gè)習(xí)慣幫我解決過(guò)很多跨周排查的疑難雜癥強(qiáng)烈建議做動(dòng)環(huán)平臺(tái)的人都保留一份。