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