CDN支持Prometheus监控吗？详细实现方案与配置指南
最近不少运维同事來問，現在公司都用Prometheus做監控，那CDN能不能也接進去？這個問題其實踩過不少坑，今天把實戰經驗攤開來說。
先說結論：原生支援Prometheus的商業CDN幾乎沒有，但變通方案比想像中多。去年幫某電商做架構優化時，他們用著某大廠CDN，卻苦於監控數據散落在不同平台，運維團隊每天要切換三套系統查故障，光是數據對齊就耗掉兩小時。
為什麼CDN廠商不直接開放Prometheus介面？核心在於安全邊界。CDN節點分佈在全球，暴露metrics端口等於給攻擊者開後門。某次滲透測試中，我們就曾通過未授權的StatsD端口拿到邊緣節點控制權，這事之後更理解廠商的顧慮。
// 自建CDN的直連方案
如果你用Nginx/Varnish自建CDN，事情就簡單多了。在邊緣節點裝個nginx-lua-prometheus庫，配置像這樣：
重點監控四個黃金指標：帶寬突增率、5xx錯誤比例、邊緣節點延遲、緩存命中率。某客戶曾因5xx錯誤閾值設得過寬，等告警觸發時已丟失百萬訂單，後來我們改成階梯式告警：錯誤率超0.5%發郵件，超1%直接打電話。
// 商業CDN的曲線監控術
對接Cloudflare/Fastly這些大廠，要走三條迂迴路線：
// 告警配置的魔鬼細節
別直接監控單節點！CDN節點隨時可能擴縮容。應該用sum(rate(error_count[5m])) by (cdn_pop) / sum(rate(request_count[5m])) by (cdn_pop) 計算分區域錯誤率。某次AWS美東區域故障，就是靠維吉尼亞節點群的錯誤率飆升提前15分鐘預警。
帶寬監控更要小心，曾經設過\”總帶寬超10Gbps告警\”，結果半夜影片流量突增觸發誤報。後來改成：(當前值 – 7天前同期值) / 7天前值 > 1.5 才告警，誤報率直降90%。
最後給張實戰儀表盤配置圖（見下），重點看紅色標註的緩存失效突刺，這往往是CC攻擊的前兆：
[示意圖：Grafana面板截圖，含請求量/錯誤率/緩存命中率聯動曲線]
監控不是目的而是手段。當你能從Prometheus曲線的毛刺中讀出俄羅斯黑客的攻擊節奏，或是從緩存命中率下跌預判某省骨幹網故障，才算真正玩轉CDN監控。
評論: