详解如何通过监控 Prometheus 系统实现自建高防 CDN 的实时预警
摘要：# 当高防CDN遇上Prometheus：你的流量防线需要一双“眼睛” 前两天跟一个做游戏的朋友聊天，他说自己花大价钱上了高防CDN，结果半夜三点被DDoS打穿，报警短信还是第二天早上才看到的。我问他：“你的防护系统有实时监控吗？”他愣了一下，说：“厂商…
当高防CDN遇上Prometheus：你的流量防线需要一双“眼睛”
前两天跟一个做游戏的朋友聊天，他说自己花大价钱上了高防CDN，结果半夜三点被DDoS打穿，报警短信还是第二天早上才看到的。我问他：“你的防护系统有实时监控吗？”他愣了一下，说：“厂商那边应该有吧？”
问题就出在这儿了。
很多人在自建或采购高防CDN时，把注意力全放在了“防护能力”上——多少G的清洗能力、多少秒的响应速度、支持哪些协议。这些当然重要，但防护系统本身就像个黑盒子：攻击来了，它在里面忙活，你在外面干着急。
今天咱们不聊怎么选高防CDN，也不讲那些复杂的防护原理。就说一件事：怎么给你的高防CDN装上一双“眼睛”，让它实时告诉你“现在正在发生什么”。
而Prometheus，就是目前最合适的那双眼睛。
一、为什么你的高防CDN需要“自检”？
先泼盆冷水：市面上不少高防CDN服务商，给你看的监控面板都是“美化”过的。我见过最离谱的，攻击流量都冲到200Gbps了，控制台还显示“当前网络状况良好”。
这不是说厂商故意骗你，而是他们的监控维度往往太宏观了——只告诉你整体流量、整体请求数。但真正要命的，往往是那些微观的异常：
- 某个边缘节点突然延迟飙升，但整体平均延迟看起来还行
- 针对特定API接口的CC攻击，被淹没在总请求数里
- 回源带宽被占满，导致正常用户访问超时
- SSL握手失败率悄悄上升，预示着可能的新型攻击
说白了，你不能完全依赖厂商给你的“成绩单”。你得有自己的“监考老师”。
二、Prometheus在高防CDN里能看什么？
很多人一听Prometheus就觉得头大，以为要搞什么复杂的运维体系。其实没那么玄乎，你就把它理解成一个24小时不睡觉的保安，专门盯着几个关键位置：
1. 流量层面的“异常脉搏”
- 入向流量突变：正常情况你的业务流量是有规律的，比如游戏服晚上8-10点是高峰。如果凌晨3点突然暴涨，Prometheus的
rate()函数能第一时间捕捉到 - 协议分布异常：突然冒出大量UDP包（可能是反射攻击），或者TCP SYN洪水，这些在Prometheus的指标里会特别明显
- 地域流量异常：某个地区的请求量突然激增，而你的业务在那个地区根本没用户
我自己的一个电商站就遇到过这种情况：突然从某个东欧小国涌来大量请求，Prometheus告警响了，一看就知道是扫描器在找漏洞。
2. 性能层面的“健康指标”
- 边缘节点延迟：每个CDN节点都有响应时间指标，Prometheus可以设置“如果超过50ms的节点比例大于10%”就告警
- 缓存命中率骤降：说明大量请求绕过了缓存，直接打到了源站——这很可能是攻击特征
- 5xx错误率上升：高防CDN本身如果扛不住，也会返回错误，这个指标比什么都直接
3. 业务层面的“真实体验”
这是最容易被忽略的。很多高防方案只防护“网络层”，但用户的实际体验呢？
- 关键API的可用性：用Prometheus的Blackbox Exporter模拟用户请求，监控登录、支付这些关键接口
- 首字节时间（TTFB）：攻击来了，清洗设备在干活，但这个处理过程会增加延迟。延迟多长用户会流失？你得知道
- SSL证书有效期：别笑，我真见过因为证书过期导致整个高防链路失效的
三、实战配置：别被YAML文件吓到
我知道，一看到Prometheus的配置文件很多人就头疼。其实核心就几块：
# 1. 先抓取高防CDN边缘节点的基础指标
# 假设你的CDN节点暴露了/metrics接口
- job_name: 'cdn_nodes'
static_configs:
- targets: ['node1.yourcdn.com:9100', 'node2.yourcdn.com:9100']
# 2. 监控业务层面的关键指标
- job_name: 'business_apis'
metrics_path: '/probe'
params:
module: [http_2xx] # 检查HTTP 200响应
static_configs:
- targets:
- 'https://api.yourdomain.com/login' # 登录接口
- 'https://api.yourdomain.com/pay' # 支付接口
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: blackbox-exporter:9115 # Blackbox Exporter地址关键告警规则示例：
groups:
- name: cdn_alerts
rules:
# 规则1：入向流量突增告警
- alert: CDNInboundTrafficSpike
expr: rate(node_network_receive_bytes_total{device="eth0"}[5m]) > 1000000000 # 1Gbps
for: 1m
annotations:
description: "入站流量超过1Gbps，可能存在攻击"
# 规则2：节点延迟异常
- alert: CDNNodeHighLatency
expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 0.5
for: 2m
annotations:
description: "95%的请求延迟超过500ms"
# 规则3：错误率升高
- alert: HighErrorRate
expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
for: 1m
annotations:
description: "HTTP 5xx错误率超过5%"四、那些“坑”我帮你踩过了
坑1：指标太多，告警疲劳
刚开始搞监控时，我恨不得把所有指标都告警一遍。结果就是半夜被吵醒三次，都是无关紧要的小波动。
我的建议：分三级告警
- P0（立即打电话）：业务完全不可用、源站被打穿
- P1（30分钟内处理）：性能严重下降、部分用户受影响
- P2（上班后处理）：异常趋势需要关注
坑2：忽略了“正常基线”
没有基线，告警就是瞎报。你得知道自己的业务：
- 工作日的流量模式 vs 周末的流量模式
- 促销期间 vs 平常时期
- 国内用户 vs 海外用户的访问规律
Prometheus的recording rules可以帮你建立这些基线。
坑3：监控了，但没人响应
这是最尴尬的。告警响了，但值班人员不知道该怎么处理。所以你的告警信息里必须包含：
- 这是什么问题？（用人类能看懂的语言）
- 可能的原因是什么？
- 第一步该做什么？（比如：先切流量到备用节点）
- 联系谁？（附上对应负责人的联系方式）
五、最后说点实在的
我知道，看到这里你可能觉得：“太复杂了，我还是用厂商的监控算了。”
但你想过没有：当攻击真的来临时，时间是以秒计算的。厂商的客服响应要多久？工单处理要多久？等你把问题描述清楚，攻击可能已经结束了——你的业务也结束了。
自己搭建Prometheus监控，前期确实要花点时间。但一旦跑起来，它就像给你的高防CDN装上了自动驾驶系统：
- 异常流量来了？自动触发清洗规则
- 某个节点挂了？自动从负载均衡池摘除
- 回源带宽满了？自动限流或降级
而且，这套监控体系不挑食。无论你用阿里云高防、腾讯云高防，还是自建Anycast网络，Prometheus都能接上去。数据在你手里，告警规则你定义，响应流程你控制。
说到底，高防CDN是你的盾牌，但监控系统是你的眼睛。没有眼睛的盾牌，只能被动挨打。
对了，如果你刚开始搞，别追求大而全。先从最核心的三个指标开始：
- 业务可用性（关键接口能不能通）
- 用户延迟（TTFB是否正常）
- 错误率（5xx是否激增）
把这三点监控好了，你就能比90%的人更早发现问题。
至于那些复杂的QPS、带宽、连接数监控……等业务真需要的时候再加也不迟。监控系统是长出来的，不是设计出来的。
好了，不废话了。如果你正在为高防CDN的“黑盒”问题头疼，今天就去装个Prometheus试试。第一个告警响起来的时候，你会感谢我的。