CDN 日志分析与监控：实时了解 CDN 运行状态
CDN 日志是了解网站加速效果的窗口。通过日志分析，你可以发现缓存优化空间、识别异常流量、追踪用户访问模式。很多团队把日志"开起来就不管"，等到出问题才想起来翻——其实一组好的日志分析看板，能在问题发生前就把苗头暴露出来。本文从日志里有什么、怎么采集、看哪些指标、怎么设告警四个层面展开。
一、CDN 日志包含的信息
不同的 CDN 提供的日志格式略有差异，但通常包含：
| 字段 | 说明 | 示例 |
|---|---|---|
| 请求时间 | 请求到达时间 | 2026-07-15T10:30:00Z |
| 客户端 IP | 用户 IP 地址 | 203.0.113.1 |
| 请求方法 | GET/POST 等 | GET |
| 请求 URI | 请求路径 | /images/logo.png |
| 状态码 | HTTP 状态码 | 200, 304, 404 |
| 响应大小 | 响应字节数 | 10240 |
| 缓存状态 | HIT/MISS/EXPIRED | HIT |
| User-Agent | 客户端标识 | Mozilla/5.0... |
| Referer | 来源地址 | https://google.com |
| 响应时间 | CDN 处理耗时 | 15ms |
一条真实的 Cloudflare 日志行大致长这样：
2026-07-15T10:30:00Z 203.0.113.1 GET /images/logo.png 200 10240 15ms HIT "Mozilla/5.0..."
只看这一行就能回答三个问题：这个请求有没有命中缓存（HIT）、多快（15ms）、谁在访问（IP 与 UA）。把成千上万行这样的日志聚合起来，就是整站的流量全貌。
日志的价值不止于"事后排查"，它和成本、安全直接挂钩：缓存命中率低意味着更多回源流量，也就是更高的 CDN 账单；连续 4xx/5xx 突增往往指向配置错误或攻击；异常 UA 和来源可能暗示爬虫或刷量。把日志当作业务信号而不是"留着备查的原始数据"，整套监控才算真正用起来。
二、日志采集方案
各 CDN 的日志导出
| CDN 服务商 | 日志导出方式 | 频率 |
|---|---|---|
| Cloudflare | Logpush → R2/S3/Splunk | 按分钟 |
| AWS CloudFront | 标准日志 → S3 | 按小时 |
| 阿里云 CDN | 离线日志 → OSS | 按小时 |
| 腾讯云 CDN | 实时日志 → CLS | 实时 |
| Fastly | 实时日志流 | 实时 |
以 Cloudflare Logpush 为例，把日志推到自己的 S3 存储只需要一条 API 配置：
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/logpush/jobs" \
-H "Authorization: Bearer $API_TOKEN" \
-d '{
"dataset": "http_requests",
"logpull_options": "fields=ClientIP,CacheStatus,EdgeResponseTime",
"destination_conf": "s3://my-bucket/logs/{DATE}"
}'
日志分析架构
CDN 日志 → S3/OSS → ETL → 分析引擎 → 可视化
├── 缓存命中率看板
├── 流量趋势图
├── 异常告警
└── 成本分析
推荐工具栈
- 采集：Logstash / Fluentd / Vector
- 存储：Elasticsearch / ClickHouse / S3 + Athena
- 分析：Spark / Presto / Trino
- 可视化：Grafana / Kibana / Tableau
三、关键监控指标
缓存命中率
缓存命中率是 CDN 效率的核心指标。
| 指标 | 说明 | 健康值 |
|---|---|---|
| 字节命中率 | CDN 直接响应的流量占比 | > 85% |
| 请求命中率 | CDN 直接处理的请求占比 | > 90% |
| 静态资源命中率 | 图片/CSS/JS 命中率 | > 95% |
性能指标
- P50/P95/P99 响应时间：观察延迟分布
- 首字节时间 (TTFB)：CDN 响应速度
- 下载速度：大文件传输速度
错误和异常
- 4xx/5xx 状态码：异常请求监控
- 回源比：回源请求过多说明缓存策略需要优化
- 带宽：实时带宽使用和趋势
四、一个实际分析场景
某站点在监控中发现：P95 响应时间突然从 300ms 跳到 1.2s，但缓存命中率没有下降。翻日志后发现，某条接口路径的 URL 带时间戳参数，导致每条请求都算 MISS，大量流量回源。修正缓存键规则（忽略时间戳参数）后，命中率回到 90% 以上，P95 也回落。这类"缓存键没配好"的问题，几乎只能靠日志分析定位。可配合CDN 日志分析脚本做批量扫描。
日志查询示例
日志进了分析引擎之后，最常用的几类查询：
-- 统计一天内各缓存状态占比（ClickHouse 示例）
SELECT CacheStatus, count() AS cnt
FROM cdn_logs
WHERE date = '2026-07-15'
GROUP BY CacheStatus
ORDER BY cnt DESC;
-- 找出回源最多的 10 个 URI（MISS 说明缓存策略有问题）
SELECT RequestURI, count() AS misses
FROM cdn_logs
WHERE date = '2026-07-15' AND CacheStatus = 'MISS'
GROUP BY RequestURI
ORDER BY misses DESC
LIMIT 10;
这两条查询分别回答"缓存整体健不健康"和"哪些路径在漏缓存"。把结果接进 Grafana 做成定时看板，就能在每天早上自动看到前一天的缓存分布，省去手动翻日志的功夫。
五、Grafana 看板示例
一个完整的 CDN 监控看板应包含：
- 实时带宽和请求数
- 缓存命中率趋势
- 热门 URI 排名
- 状态码分布
- 地理分布
- 响应时间热力图
六、告警规则
| 触发条件 | 严重级别 | 响应 |
|---|---|---|
| 缓存命中率 < 70% | 警告 | 检查缓存配置 |
| 错误率 > 1% | 警告 | 检查源站和 CDN |
| 回源带宽突增 5x | 严重 | 检查是否有攻击 |
| CDN 节点大面积故障 | 严重 | 启用备用 CDN |
落地建议
- 小流量站点不需要一开始就上完整 ELK/ClickHouse，先让 CDN 服务商把日志推到对象存储，用 Athena 或 DuckDB 按需查询即可；
- 命中率类指标建议按月对比基线，而不是盯着单日数字——促销、节假日会带来正常波动；
- 日志字段尽量在接入时就规划好保留周期（建议 90 天以上），避免需要回溯时发现已经过期被清理；
- 告警要区分"该通知人"和"先看板即可"两类：命中率、错误率这种高频指标默认只上看板，严重级别（如回源突增 5x）才走即时通知，避免告警疲劳。
参考：https://developers.cloudflare.com/logs/ / https://clickhouse.com/docs