做運(yùn)維久了就會(huì)發(fā)現(xiàn)“服務(wù)沒掛”和“用戶能訪問”完全是兩碼事。我之前就吃過這個(gè)虧后臺(tái)服務(wù)進(jìn)程跑得穩(wěn)穩(wěn)當(dāng)當(dāng)CPU、內(nèi)存、連接數(shù)全部正常前端頁面就是刷不出來。排查到最后問題出在服務(wù)依賴的一個(gè)資源 URL 上——那個(gè)地址在某個(gè)中間環(huán)節(jié)已經(jīng)不通了但從進(jìn)程視角看一切指標(biāo)都正常。這類問題最能逼出一個(gè)需求你需要一個(gè)能主動(dòng)、持續(xù)、按自己的規(guī)則去探測(cè)資源 URL 連通性的工具。市面上現(xiàn)成的監(jiān)控平臺(tái)不少但真要滿足內(nèi)部環(huán)境、私有服務(wù)、自定義探測(cè)頻率和判定標(biāo)準(zhǔn)這些場(chǎng)景還是得自己動(dòng)手寫一個(gè)心里才踏實(shí)。這篇文章就聊聊我自建這個(gè) URL 連通性探測(cè)工具的全過程從需求拆解、協(xié)議選擇到參數(shù)設(shè)計(jì)、告警降噪再到部署后踩過的坑。內(nèi)容偏實(shí)操適合被“服務(wù)正常但客戶說連不上”困擾過的朋友也適合準(zhǔn)備從零搭一套輕量可用性監(jiān)控的人。1. 為什么我要自己寫這個(gè) URL 連通性探測(cè)工具1.1 外部監(jiān)控平臺(tái)覆蓋不到的“網(wǎng)絡(luò)死角”很多團(tuán)隊(duì)一開始都在用第三方監(jiān)控平臺(tái)定時(shí)去檢查公網(wǎng)入口、首頁、登錄接口這些“門面地址”這套方案對(duì)純公網(wǎng)業(yè)務(wù)還算湊合。但我們當(dāng)時(shí)面臨的情況更復(fù)雜一部分服務(wù)跑在企業(yè)內(nèi)網(wǎng)另一部分在開發(fā)測(cè)試環(huán)境還有一些服務(wù)依賴的是別人提供的內(nèi)部資源地址比如對(duì)象存儲(chǔ)網(wǎng)關(guān)、消息隊(duì)列管理接口、數(shù)據(jù)平臺(tái)的調(diào)度入口。這些地址從公網(wǎng)探針根本訪問不到外部監(jiān)控平臺(tái)自然給不出任何有價(jià)值的結(jié)果。就算把探針部署到內(nèi)網(wǎng)第三方平臺(tái)的調(diào)度粒度和判定邏輯也很難貼合實(shí)際。監(jiān)控平臺(tái)通常是分鐘級(jí)輪詢自定義探針部署又得在他們的客戶端里做二次開發(fā)限制不少。最尷尬的是測(cè)試環(huán)境地址經(jīng)常變、端口臨時(shí)起臨時(shí)關(guān)想調(diào)整監(jiān)控項(xiàng)還得等平臺(tái)側(cè)配置生效運(yùn)氣不好一次變更要等半天。對(duì)運(yùn)維來說這種“監(jiān)控死角”比沒有監(jiān)控還難受——你以為有人盯著其實(shí)那里什么保護(hù)都沒有。1.2 從一次線上事故說起監(jiān)控有但告警晚了半拍讓我把時(shí)間撥回項(xiàng)目最難熬的那一周。有個(gè)面向內(nèi)部員工的門戶系統(tǒng)頻繁出現(xiàn)“頁面加載一半就轉(zhuǎn)圈”的投訴。服務(wù)端日志翻遍了沒發(fā)現(xiàn)異常數(shù)據(jù)庫連接池、Redis 命中率、網(wǎng)關(guān)轉(zhuǎn)發(fā)耗時(shí)都在正常范圍。最后靠抓包才發(fā)現(xiàn)門戶頁面里引用的一個(gè)靜態(tài)資源地址指向了遷移后的新域名而舊域名在內(nèi)網(wǎng) DNS 里的解析記錄已經(jīng)失效。瀏覽器一直請(qǐng)求這個(gè)域名每次都等超時(shí)頁面自然就卡住了。這個(gè)資源地址恰好不在任何監(jiān)控項(xiàng)里。第三方平臺(tái)監(jiān)控的是首頁 URL 本身首頁 HTML 確實(shí)能返回 200但里面引用的子資源已經(jīng)死了很久。更諷刺的是舊域名的 DNS 解析其實(shí)是間歇性失敗屬于偶發(fā)問題分鐘級(jí)監(jiān)控根本抓不住這種“時(shí)好時(shí)壞”的狀態(tài)。那次事故后我下決心自己寫一個(gè)工具要求很樸素想探測(cè)什么 URL 就探測(cè)什么 URL想多久探一次就多久探一次判定失敗的標(biāo)準(zhǔn)也能自己定。不做成大而全的監(jiān)控平臺(tái)就做一個(gè)“指哪打哪”的連通性探測(cè)工具能持續(xù)跑、能出歷史數(shù)據(jù)、能告警就夠。2. 動(dòng)手前的三個(gè)關(guān)鍵決策協(xié)議棧、探測(cè)頻率與失敗判定2.1 協(xié)議棧怎么選HTTP/HTTPS、TCP 還是 ICMP很多初學(xué)者寫探測(cè)工具第一反應(yīng)就是“用 ping”但實(shí)際做下來會(huì)發(fā)現(xiàn)ICMP 在很多網(wǎng)絡(luò)環(huán)境下會(huì)被防火墻直接丟棄而且 ping 只能驗(yàn)證主機(jī)層面的連通性完全看不出來 80 端口和 443 端口是否正常。真正在業(yè)務(wù)場(chǎng)景里我更常用的是這幾種探測(cè)協(xié)議HTTP/HTTPS 請(qǐng)求最貼合業(yè)務(wù)視角能檢查 URL 是否能正常響應(yīng)能拿到狀態(tài)碼、響應(yīng)時(shí)間、響應(yīng)體內(nèi)容適合探測(cè) API、頁面、靜態(tài)資源地址。TCP 端口連通適合非 HTTP 服務(wù)比如數(shù)據(jù)庫端口、消息隊(duì)列端口、Redis、內(nèi)部 RPC 服務(wù)。只需要確認(rèn)“端口能連上”不關(guān)心具體協(xié)議內(nèi)容。TCP 自定義協(xié)議握手這是 HTTP 探測(cè)的超集。比如探測(cè)一個(gè)自研 RPC 端口連接后需要發(fā)一段固定的握手包能收到預(yù)期響應(yīng)才算通過。這個(gè)能力擴(kuò)展起來很方便我在工具里預(yù)留了“發(fā)送字節(jié)”和“期望響應(yīng)字節(jié)”的配置位。這里有個(gè)容易踩的誤區(qū)不是所有 HTTP 服務(wù)都返回 200 才算健康。有些內(nèi)部服務(wù)為了不暴露內(nèi)部信息對(duì)健康檢查路徑故意返回 403有些管理接口返回 302 跳轉(zhuǎn)到登錄頁反而是正常狀態(tài)。所以探測(cè)工具不能硬編碼“2xx 就是成功”必須支持自定義期望狀態(tài)碼。2.2 頻率、超時(shí)與重試的參數(shù)取舍探測(cè)頻率這塊我一開始想得比較簡(jiǎn)單既然要監(jiān)控那就 10 秒探一次越快發(fā)現(xiàn)問題越好。結(jié)果上線第一天就被現(xiàn)實(shí)教育了。某個(gè)老系統(tǒng)接口扛不住高頻訪問監(jiān)控跑了一個(gè)小時(shí)直接把對(duì)方接口觸發(fā)限流對(duì)方運(yùn)維氣勢(shì)洶洶找過來問是不是在打他們接口。所以頻率設(shè)置必須尊重兩個(gè)約束一是探測(cè)目標(biāo)自身能承受的請(qǐng)求壓力二是問題發(fā)現(xiàn)速度的真實(shí)需求。我的經(jīng)驗(yàn)是對(duì)公網(wǎng)資源一般 30 秒到 60 秒探一次足夠內(nèi)網(wǎng)核心服務(wù)可以激進(jìn)一點(diǎn)到 10 秒到 15 秒但需要提前確認(rèn)目標(biāo)服務(wù)的承受能力。如果是對(duì)外網(wǎng)第三方服務(wù)做探測(cè)頻率務(wù)必要保守有些服務(wù)商會(huì)把高頻率請(qǐng)求視為攻擊行為。超時(shí)參數(shù)同樣需要單獨(dú)設(shè)計(jì)。很多人的做法是requests.get(url, timeout5)把所有超時(shí)混在一起。但更正確的做法是區(qū)分連接超時(shí)和讀取超時(shí)連接超時(shí)太短跨地域訪問會(huì)大量誤報(bào)讀取超時(shí)太短處理慢的接口很容易被誤判。我一般把連接超時(shí)設(shè)為 3 秒到 5 秒讀取超時(shí)設(shè)為 10 秒到 30 秒不同目標(biāo)可以在配置里單獨(dú)覆蓋。重試邏輯也不是越重試越好。過度重試會(huì)讓故障恢復(fù)時(shí)間被拉長本來 5 秒能發(fā)現(xiàn)的問題重試三次之后可能拖到 30 秒。我的設(shè)計(jì)是第一次失敗立即重試一次如果仍失敗間隔 5 秒再重試一次再失敗才標(biāo)記為探測(cè)失敗。這樣能過濾掉絕大多數(shù)網(wǎng)絡(luò)抖動(dòng)又不會(huì)把告警拖得太遲鈍。2.3 判定“失敗”的完整鏈路僅僅“發(fā)起請(qǐng)求”和“收到響應(yīng)”并不足以定義探測(cè)成功。我把一次完整探測(cè)拆成了五個(gè)環(huán)節(jié)每個(gè)環(huán)節(jié)都有明確的失敗類型環(huán)節(jié)判定標(biāo)準(zhǔn)典型失敗類型DNS 解析域名能解析出 IPdns_errorTCP 建連目標(biāo)端口能完成握手connection_refused / timeoutTLS 握手證書有效且能完成加密握手tls_error / certificate_expiredHTTP 響應(yīng)狀態(tài)碼符合期望http_5xx / unexpected_status業(yè)務(wù)語義響應(yīng)體包含期望關(guān)鍵字可選body_mismatch這個(gè)拆解特別重要因?yàn)樗苤苯記Q定后續(xù)怎么處理。DNS 解析失敗和 TCP 連接超時(shí)代表網(wǎng)絡(luò)鏈路有問題值得立即重試和告警HTTP 500 說明鏈路是通的但服務(wù)本身在處理請(qǐng)求時(shí)出錯(cuò)了這同樣值得告警但排查方向和前者完全不同。有了失敗類型告警信息里就不再只是一句干巴巴的“連接失敗”而是“探測(cè)到 https://xxx 域名解析失敗重試兩次后仍失敗”定位效率翻倍。3. 核心實(shí)現(xiàn)從單探針到并發(fā)可觀測(cè)3.1 同步請(qǐng)求的短板與并發(fā)方案的選擇第一版工具我寫得很直接用一個(gè)循環(huán)逐個(gè)探測(cè) URL順序執(zhí)行。跑起來才發(fā)現(xiàn)一旦探測(cè)列表里有那么一兩個(gè)慢接口整個(gè)周期就被拖慢了。比如一個(gè)接口 20 秒超時(shí)另一個(gè)接口本來 1 秒就能探完結(jié)果都得等這 20 秒走完才開始下一輪。探測(cè)周期被無限拉長監(jiān)控的及時(shí)性大打折扣。解決辦法自然是并發(fā)但并發(fā)方案有講究。Python 生態(tài)里有三種選擇多線程、多進(jìn)程、協(xié)程。對(duì)探測(cè)這種以網(wǎng)絡(luò) IO 為主的任務(wù)多線程和協(xié)程都?jí)蛴貌顒e主要在資源的簡(jiǎn)潔性上。協(xié)程寫起來更輕但很多現(xiàn)成的 HTTP 庫在協(xié)程環(huán)境里需要配套生態(tài)支持多線程更成熟代碼也更容易理解。最終我選擇了線程池方案并發(fā)數(shù)設(shè)置成 20。這個(gè)數(shù)字不是拍腦袋定的而是根據(jù)目標(biāo)服務(wù)承受能力和單輪探測(cè)任務(wù)量算出來的。當(dāng)時(shí)大概有三十多個(gè) URL 需要探測(cè)20 個(gè)并發(fā)意味著單輪最多兩批跑完而大多數(shù)目標(biāo)響應(yīng)都在 1 秒內(nèi)整體周期能控制在 2 秒以內(nèi)。測(cè)試環(huán)境網(wǎng)絡(luò)抖動(dòng)比較常見所以單線程那種“一個(gè)慢請(qǐng)求拖一輪”的問題必須避免。3.2 代碼骨架與關(guān)鍵函數(shù)核心探測(cè)邏輯其實(shí)不復(fù)雜關(guān)鍵在結(jié)構(gòu)清晰。我抽象了一個(gè)ProbeTask對(duì)象發(fā)起探測(cè)的入口長這樣import socket import ssl import time from dataclasses import dataclass, field from concurrent.futures import ThreadPoolExecutor, as_completed dataclass class ProbeResult: target: str protocol: str status_code: int time_total: float fail_type: str message: str detected_at: float def probe_http(url: str, expected_code: int, timeout: tuple) - ProbeResult: start time.time() try: resp session.get(url, timeouttimeout, allow_redirectsTrue) elapsed round(time.time() - start, 3) if resp.status_code expected_code: return ProbeResult(url, http, resp.status_code, elapsed, , ) return ProbeResult(url, http, resp.status_code, elapsed, unexpected_status, f期望 {expected_code}實(shí)際 {resp.status_code}) except Exception as exc: elapsed round(time.time() - start, 3) fail_type classify_exception(exc) return ProbeResult(url, http, 0, elapsed, fail_type, str(exc))有人可能覺得這個(gè)代碼看起來有點(diǎn)“薄”但探測(cè)工具本來就不該塞太多業(yè)務(wù)邏輯。關(guān)鍵在幾個(gè)容易被忽略的細(xì)節(jié)session.get用的是預(yù)創(chuàng)建的連接池長連接能省去反復(fù)握手的開銷異常分類classify_exception把socket.timeout、ConnectionError、ssl.SSLError分別映射到明確類型為后續(xù)統(tǒng)計(jì)和告警鋪路。3.3 結(jié)果數(shù)據(jù)結(jié)構(gòu)與錯(cuò)誤分類探測(cè)結(jié)果統(tǒng)一用 JSON 行格式落盤一行一個(gè)記錄。這個(gè)格式選它不是圖省事而是因?yàn)槿罩绢惞ぞ吆兔钚蟹治龉ぞ叨继烊恢С謌rep、awk、jq 隨手就能處理。每行包含目標(biāo)地址、協(xié)議、狀態(tài)碼、耗時(shí)、失敗類型、探測(cè)時(shí)間這幾個(gè)核心字段排查問題時(shí)會(huì)明顯感覺到方便。classify_exception的錯(cuò)誤分類要盡量細(xì)。我見過很多人把異常全部打包成“連接失敗”導(dǎo)致告警永遠(yuǎn)只顯示一句話根本沒法派單。我自己維護(hù)了這樣一張映射表異常類型映射結(jié)果告警級(jí)別建議socket.timeouttimeout高ConnectionRefusedErrorconnection_refused高socket.gaierrordns_error高ssl.SSLCertVerificationErrorcertificate_error中需提前續(xù)期SSLEOFErrortls_error高HTTP 5xxhttp_5xx高HTTP 4xxhttp_4xx低需人工判斷不同類型的失敗后續(xù)重試和告警策略也可以不同。比如證書錯(cuò)誤通常不會(huì)因?yàn)橹卦嚩謴?fù)重試只會(huì)浪費(fèi)時(shí)間但http_5xx有可能是服務(wù)臨時(shí)抖動(dòng)重試成功的概率很高。這個(gè)區(qū)分在告警降噪里非常重要。4. 聚合、告警與持續(xù)觀測(cè)讓數(shù)據(jù)說話4.1 狀態(tài)聚合用滑動(dòng)窗口代替單點(diǎn)判斷最開始看探測(cè)結(jié)果我習(xí)慣看最近一輪的狀態(tài)這一輪通了就是綠燈這一輪掛了就告警。后來復(fù)盤發(fā)現(xiàn)這種方法問題很大——單輪探測(cè)受網(wǎng)絡(luò)抖動(dòng)影響太明顯經(jīng)常出現(xiàn)上一輪失敗、下一輪成功的情況告警發(fā)得毫無價(jià)值。后來我引入了滑動(dòng)窗口聚合。簡(jiǎn)單說就是統(tǒng)計(jì)最近 5 分鐘內(nèi)總探測(cè)次數(shù)和成功次數(shù)用成功率來代表當(dāng)前健康狀態(tài)。成功率低于一個(gè)閾值才認(rèn)為異常否則最多算“抖動(dòng)”或“降級(jí)”。窗口大小可以配置對(duì)敏感業(yè)務(wù)可以縮短到 1 分鐘對(duì)普通資源用 5 分鐘更合理。這樣做還有個(gè)額外好處可以更容易地畫趨勢(shì)圖而不是只看一個(gè)孤立的“通/不通”狀態(tài)。4.2 告警降噪連續(xù)失敗閾值與恢復(fù)確認(rèn)告警降噪是這套工具里性價(jià)比最高的優(yōu)化。我的規(guī)則很簡(jiǎn)單單次失敗不立刻告警連續(xù)失敗三次才觸發(fā)恢復(fù)通知也不是恢復(fù)成功一次就發(fā)而是連續(xù)成功三次才解除告警。這個(gè)“三次”是拍腦袋定的嗎不是。我統(tǒng)計(jì)過前一個(gè)月的探測(cè)數(shù)據(jù)網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的瞬時(shí)失敗幾乎不會(huì)連續(xù)出現(xiàn)三次以上而真實(shí)故障大概率會(huì)持續(xù)超過一分鐘。告警消息里一定要帶上前因后果。我有一條固定的告警模板包含目標(biāo) URL、連續(xù)失敗次數(shù)、最近一次失敗類型、最近三次探測(cè)結(jié)果時(shí)間線、DNS 解析耗時(shí)和 TLS 證書剩余天數(shù)。這些信息能讓收到告警的人不用再登服務(wù)器查日志直接判斷是找網(wǎng)絡(luò)組還是找應(yīng)用組。4.3 歷史數(shù)據(jù)的價(jià)值趨勢(shì)與回歸很多人把連通性探測(cè)工具當(dāng)成“告警觸發(fā)器”用完就扔我覺得這是浪費(fèi)。工具每天會(huì)沉淀大量可觀測(cè)數(shù)據(jù)這些數(shù)據(jù)的價(jià)值比告警本身大得多。舉個(gè)例子某個(gè)外部服務(wù)的響應(yīng)時(shí)間從 200ms 逐漸漲到 800ms單日的探測(cè)結(jié)果看起來都“正?！睕]有觸發(fā)任何告警。但拉出一個(gè)月的趨勢(shì)折線你會(huì)發(fā)現(xiàn)這條線斜率很明顯說明對(duì)方服務(wù)在緩慢劣化。等真的哪一天超時(shí)閾值被擊穿就完全不是突發(fā)問題而是趨勢(shì)惡化的必然結(jié)果。把歷史數(shù)據(jù)落成 CSV 或者導(dǎo)入時(shí)序數(shù)據(jù)庫后這類“緩慢劣化”基本都能提前發(fā)現(xiàn)。5. 實(shí)際部署三個(gè)月后踩過的那些坑5.1 環(huán)境變量里的代理陷阱這是最隱蔽的一個(gè)坑。工具剛上線時(shí)跑在內(nèi)網(wǎng)一臺(tái)機(jī)器上明明網(wǎng)絡(luò)正常但所有 HTTPS 探測(cè)全部超時(shí)。排查了半天最后發(fā)現(xiàn)機(jī)器的環(huán)境變量里配置了http_proxy和https_proxy指向一個(gè)早已廢棄的內(nèi)部代理地址。第三方 HTTP 庫默認(rèn)會(huì)讀取這些環(huán)境變量導(dǎo)致每個(gè)請(qǐng)求都試圖先連代理代理連不上自然全部失敗。解決辦法是顯式禁用自動(dòng)代理在請(qǐng)求會(huì)話里明確指定trust_envFalse。如果你也在寫類似的工具建議在初始化 session 后立刻打印一份“當(dāng)前是否使用代理”的狀態(tài)避免被環(huán)境變量悄悄影響。5.2 探測(cè)目標(biāo)本身的反爬和限流前文提到過有個(gè)老系統(tǒng)被高頻探測(cè)打到限流。這提醒了我一個(gè)原則探測(cè)工具必須站在目標(biāo)服務(wù)的角度想問題。有些資源 URL 是公開頁面帶頻率限制有些內(nèi)部接口有白名單機(jī)制源 IP 不在列表中會(huì)直接拒絕還有些 CDN 廠商對(duì)異常 User-Agent 做攔截。我的工具在配置里增加了自定義請(qǐng)求頭設(shè)置默認(rèn)帶上了一個(gè)顯眼的 User-Agent比如health-checker/1.0。這樣做一方面能讓目標(biāo)方清楚地識(shí)別這是監(jiān)控流量另一方面也能避免被誤判成“掃描器”。同時(shí)每個(gè)目標(biāo)都支持獨(dú)立的頻率配置敏感服務(wù)單獨(dú)調(diào)低不再一刀切。5.3 時(shí)間戳、日志輪轉(zhuǎn)與證書過期預(yù)警三個(gè)不起眼但很重要的運(yùn)維細(xì)節(jié)。第一探測(cè)結(jié)果的時(shí)間戳必須用統(tǒng)一的時(shí)區(qū)最好直接用 UTC 毫秒時(shí)間戳落盤展示時(shí)再轉(zhuǎn)本地時(shí)間。我就吃過虧監(jiān)測(cè)腳本和告警平臺(tái)用了不同時(shí)區(qū)配置排障時(shí)兩條記錄對(duì)不上白白浪費(fèi)了不少時(shí)間。第二日志文件要輪轉(zhuǎn)。JSON 行格式雖然好用但不輪轉(zhuǎn)會(huì)無限增長。我設(shè)置了按天切割、保留 30 天的策略超過自動(dòng)清理。第三工具要把 TLS 證書剩余天數(shù)作為獨(dú)立字段記錄當(dāng)剩余天數(shù)小于 30 天就單獨(dú)發(fā)一條提示告警。證書過期這種事與其等人告訴你說“突然訪問不了了”不如提前兩周就看到提醒。最后再分享一個(gè)小技巧探測(cè)工具的配置文件一定要用 YAML把每個(gè)目標(biāo)地址、協(xié)議、期望狀態(tài)碼、頻率、重試次數(shù)、告警閾值全部顯式列出來然后寫一段自檢邏輯啟動(dòng)時(shí)檢查配置是否合法。這樣新同事接手時(shí)只需要改配置不用翻代碼整個(gè)工具的維護(hù)成本會(huì)低很多。