如果你的 CDN 命中率从 90% 跌到 70% 你能在 5 分钟内发现吗？多数团队的回答是：等用户投诉或者下个月看账单回源费用突然涨了才意识到。CDN 命中率监控 不是锦上添花，而是发现配置变更、源站头变化、爬虫爆破第一时间能拉响警报的关键防线。本文将教你如何从零搭建一套覆盖采集、聚合、告警与排障的 CDN 监控体系，帮你解决”命中率下跌没人知道、回源带宽暴涨才发现已经晚了”这类问题。
一、为什么需要主动监控
CDN 厂商控制台都自带命中率仪表盘，但它们有三个共同缺陷：刷新粒度大（通常 15 分钟到 1 小时）、不能跨厂商对齐、无法配置精细化告警。自建监控的价值在于：
- 粒度细：分钟级甚至秒级聚合，能捕捉短时突发。
- 维度全：可按路径、Host、地区、状态码切片，定位问题更快。
- 告警可控：阈值、静默时段、多通道（Slack、邮件、电话）自由组合。
- 历史可追溯：保留 30 天以上原始日志便于复盘。
判断你的业务是否值得引入主动监控，可以参考三点：单月 CDN 流量超 1 TB、回源费用占总账单 10% 以上、业务有发布回滚回调需求。命中其一就值得做。
如果你的源站布在跨境链路上，命中率每下降 5% 都会显著推高回源带宽与时延。源站线路选型可参考 WordPress 香港主机选购指南 与 云服务器选购指南 中关于出口带宽与 BGP 多线的章节。
二、关键指标设计
一个最小可用的 CDN 监控指标集应包含五个维度：
- 命中率（Cache Hit Rate）：命中数 / 总请求数。基线通常 85% 以上，跌破 75% 应告警。
- 回源带宽：Mbps 或 GB/小时。突增 50% 应告警。
- 回源延迟（Origin Latency P95）：边缘到源站的耗时 P95。超过 500ms 应关注。
- 状态码分布：4xx、5xx 占比。5xx 超过 1% 立即告警。
- 请求来源：按 Country、ASN 切片，定位异常爬虫与攻击。
进一步可叠加按 URL 路径切片的命中率，发现某个目录被误配 Cache-Control: no-cache 等情况。
三、日志采集方式
主流 CDN 都支持把访问日志推送到第三方：
- Cloudflare：Enterprise 方案可用 Logpush 推到 S3、GCS、HTTP endpoint；免费方案仅有汇总 Analytics API，分钟级。
- CloudFront：Standard Logging 写到 S3，Real-time Logs 推到 Kinesis Data Streams。
- Fastly：Real-Time Log Streaming 支持 20 多种接收端。
- BunnyCDN：Log Forwarding 支持 S3 与自定义 HTTP endpoint。
- KeyCDN：Raw Log Forwarding 推到 Storage Zone 或 SFTP。
对中小站点，建议直接选 HTTP endpoint 模式，把日志推到 Logtail、Vector 或自建 FluentBit。日志解析与字段映射在接收端完成，下游存到 ClickHouse 或 Elasticsearch 都可以。
字段层面至少保留：timestamp、host、url、status、cache_status、bytes_sent、origin_time、country、user_agent。cache_status 是计算命中率的核心，各厂商命名略有差异：Cloudflare 是 CacheStatus、CloudFront 是 x-edge-result-type、Fastly 是 fastly_info.state，处理时需要做映射。
四、Prometheus 指标与告警规则
把原始日志聚合成 Prometheus 指标的常见做法是用 Vector 或 FluentBit 在采集层做计数，暴露 /metrics 给 Prometheus 抓取。最小指标集：
cdn_requests_total{provider, host, status, cache_status}
cdn_origin_bytes_total{provider, host}
cdn_origin_duration_seconds_bucket{provider, host, le}
告警规则示例（Prometheus AlertManager）：
groups:
- name: cdn_hit_rate
rules:
- alert: CDNHitRateLow
expr: |
sum(rate(cdn_requests_total{cache_status="HIT"}[5m])) by (provider, host)
/
sum(rate(cdn_requests_total[5m])) by (provider, host)
< 0.75
for: 10m
labels:
severity: warning
annotations:
summary: "CDN 命中率低于 75%"
- alert: CDN5xxBurst
expr: |
sum(rate(cdn_requests_total{status=~"5.."}[5m])) by (provider, host)
/
sum(rate(cdn_requests_total[5m])) by (provider, host)
> 0.01
for: 5m
labels:
severity: critical
for: 10m 这种持续条件能避免毛刺误报。WordPress 站点的命中率与本地缓存策略强相关，可参考 WordPress W3 Total Cache 调优实战 中关于源站头与边缘缓存协作的章节，避免本地插件误发 no-cache 拉低 CDN 命中率。更多 WordPress 加速场景可在 WordPress 分类 下查阅相关文章。
五、告警与发布联动
监控的最终目的是触发动作，不是被动看图。常见联动场景：
- 告警到 Slack/钉钉：AlertManager 的 webhook 直接推送，附 Grafana 截图链接。
- 发布回调：CI/CD 流水线发布完成后调用 CDN Purge API，并在 60 秒内对比发布前后的命中率，回退到稳定基线则二次确认。
- 自动屏蔽：检测到某 IP 段 5xx 率异常时，自动调用 CDN WAF API 临时封禁。
- 限流降级：源站回源带宽突增时，自动把部分非关键路径切到长 TTL Bypass。
对自建主机的故障联动，建议结合 美国 VPS 部署教程 中的健康检查脚本，让告警触发后能自动收集 MTR、tcpdump 等现场信息。
六、典型故障排查路径
命中率突降的常见根因与排查顺序：
- 发布触发：先看最近一次发布时间，是否在告警前 30 分钟。常因 cache-control 头变更或 query string 策略调整。
- 源站头变化：在边缘日志按 URL 看 MISS 占比，再用
curl -I直接拉源站，看Cache-Control、Vary、Set-Cookie是否被改写。 - 爬虫爆破：观察 user_agent 与 country 维度，单一爬虫请求大量不同 URL 会让命中率断崖式下跌。
- CDN 配置变更：检查 CDN 控制台的最近变更日志，错误的 Cache Rule 也会导致命中率突降。
- 回源链路异常：边缘节点连续回源失败会让 cache 无法刷新，配合 MTR 与 CDN 厂商工单一起排查。
七、Grafana 看板设计要点
把数据接入 Prometheus 后，最终消费这些指标的是值班同学。一个易用的 Grafana 看板比一份完美的指标表更重要。看板设计推荐：顶部用单值面板展示当前命中率、5xx 率、回源带宽三个核心数字，并配以阈值染色；中部用时间序列展示最近 24 小时趋势，叠加发布事件标记；底部用 Top N 表格展示命中率最低的 10 个路径、5xx 最多的 10 个 Host、回源带宽最高的 10 个 URL。
值班 SOP 也要同步建立：告警触发后第一步看看板找异常路径或 Host，第二步直接到 CDN 厂商日志验证，第三步联系业务方判断是否近期有变更。把这套流程写进运行手册，能让新人在 30 分钟内学会处理常见告警，而不是每次都靠老员工口口相传。
总结与建议
CDN 命中率监控 的核心思路是”在 CDN 控制台之外建立独立的真实数据视图”，不要把命中率的眼睛只交给厂商。建议中小团队从最小可用指标集起步：把命中率、5xx、回源带宽三个指标先跑稳，再扩展到按路径与按地区切片。如果你已经有 Prometheus 监控栈，把 CDN 数据接入只需 1 到 2 周；如果还没有监控栈，可以考虑先用厂商原生告警凑合两个月，再逐步迁移到自建方案。整体来看，主动监控是把”被动等用户反馈”变成”主动捕捉异常”的关键基础设施，对任何流量超过 1 TB 的站点都强烈推荐尽早部署。