图片缓存监控说复杂也复杂，说简单就两条线：命中率盯着用户等多久，回源比例盯着钱包瘪多快，这两条线放进同一张看板，异常时才能分清是缓存配置翻车，还是流量结构变了。
命中率和回源比，是一对跷跷板
边缘节点每接一个图片请求,只有两个归宿：命中缓存，或者回源站，命中率往下掉，回源流量几乎必然往上顶，源站带宽、回源耗时、首屏时间会跟着一起抖，所以做图片缓存命中率与回源比例的监控，本质是把一次请求的”分叉路口”数清楚。
图片缓存命中率怎么计算
先把口径定死,再谈监控，否则不同报表能差出十几个点。
按请求数算：
命中率 = 命中缓存的请求数 ÷ (命中请求数 + 回源请求数)
按字节数算：
字节命中率 = 命中返回的字节数 ÷ 总输出字节数
图片业务两个口径都要看,一张 2MB 的原图和一张 20KB 的缩略图，在请求口径里权重一样，在字节口径里差了一百倍，多数情况下，运营看的是请求命中率，带宽成本考核看的是字节命中率，混用就会吵架。
Nginx 上直接取变量：
log_format img_cache '$remote_addr - $time_local "$request" '
'$status $body_bytes_sent $request_time '
'$upstream_cache_status $upstream_response_time';
$upstream_cache_status 的取值就是现成的分类器：HIT、MISS、BYPASS、EXPIRED、REVALIDATED、STALE，统计命中率时只把 HIT 和 STALE 算命中，EXPIRED、REVALIDATED 单独列一列，否则你会把”过期后重新校验”美化成命中，看板上好看，源站却在拼命扛。
回源比例容易被算错的地方
回源比例常见定义是回源请求数占总请求数的比例,真正影响账单的是回源流量占比，两个数不要混为一谈。
几个坑：
- 304 响应算回源请求，但响应体很小，按流量口径几乎不计入，按请求口径会让回源比例虚高。
- Range 请求和分片回源，一次图片加载可能拆成多个回源请求，日志里会放大回源次数。
- 中间源（二级缓存）回源和边缘回源要分开统计，边缘回源到中间源，成本很低；中间源打到源站，才是真金白银。
- 预热流量和主动刷新流量要单独打标签,不然大促前的预热会把回源曲线顶出一个假尖峰。
CDN缓存命中率和回源率有什么区别
这两个词在周报里经常被写成一回事,实际上一个是效率指标，一个是成本指标，业内专家指出，把两者放在同一坐标系里观察趋势，比单独盯任何一个都更能定位问题。
| 维度 | 缓存命中率 | 回源比例 |
|---|---|---|
| 衡量对象 | 边缘节点服务请求的效率 | 请求穿透到源站的程度 |
| 主要影响 | 用户首字节时间、可用性 | 源站带宽、回源费用、源站压力 |
| 计算分母 | 边缘总请求 | 边缘总请求或总流量 |
| 异常典型原因 | 缓存键碎片化、TTL 过短、参数污染 | 回源合并缺失、预热不足、源站限速 |
| 优化手段 | 规范 URL、忽略无用参数、延长 TTL | 分层缓存、请求折叠、分级降级 |
为什么图片业务的命中率天然偏低
站的图片有两个特征：长尾和参数化。
长尾意味着大量图片一生只被访问几次,冷图永远占大头，整体命中率被拉低是常态，参数化更麻烦，?w=200&h=200&q=80 这种动态裁剪参数一变，缓存键就变一次，同一张原图能裂出几十个缓存副本，业内共识认为，图片类业务的命中率提升，八成工作量在缓存键治理上，剩下两成才是调 TTL。
排查顺序建议这样走：
- 按 URL 维度拆分，看是不是少数目录拖低了整体。
- 检查缓存键是否带上了
User-Agent、Cookie、随机数参数。 - 检查响应头是否被源站写成了
Cache-Control: no-cache或private。 - 检查
Vary头，Vary: User-Agent基本等于给每个客户端建一份缓存。 - 最后才怀疑节点容量和淘汰策略。
监控落地：字段、链路、看板
一套能用的图片缓存命中率与回源比例监控,链路不长：边缘日志采集 → 消息队列 → 列式存储 → 看板与告警。
边缘日志先抓这几个字段
不管用自建 Nginx 还是商业 CDN，日志里至少要落地这些字段：
- 请求 URL 和归一化后的缓存键
- 响应状态码
X-Cache或$upstream_cache_status- 响应字节数和回源字节数
- 回源耗时、边缘总耗时
- 命中层级（边缘 / 中间源 / 源站）
- 业务标签（商品图、头像、活动图）
URL 归一化这一步别省，把尺寸、质量、格式参数按固定顺序排序，去掉无意义的跟踪参数，否则后面所有统计都建立在流沙上。
用一条curl命令验证缓存有没有生效
上线新规则后,先别急着看大盘，用命令行确认单条链路：
curl -sI "https://img.example.com/p/1001.jpg" | grep -Ei "x-cache|age|via|cache-control|expires"
重点看三个地方：
X-Cache或CF-Cache-Status是否从MISS变为HITAge是否大于 0 且在增长，说明命中的是已缓存副本Cache-Control的max-age是否符合预期
连续请求两次,第二次仍是 MISS，说明缓存键有问题，回到上一步查参数。
报警怎么设才不狼来了
阈值不要拍脑袋,先跑两周历史数据，取分位数做基线：
- 命中率按业务线分别设线,商品图和头像图不能用同一个阈值。
- 用同比和环比双视角,大促当天和上周同日比，比和昨天比更靠谱。
- 回源带宽设水位线而不是绝对值,比如达到源站出口能力的某个比例再告警。
- 加一条”缓存键数量突增”的告警，这往往是参数污染的早期信号。
电商大促期间图片回源带宽怎么监控
大促是图片回源最容易失控的场景,零点一过，短时间内的请求集中打向少数爆款商品图，如果预热没做，边缘节点全部 MISS，回源流量会瞬间打到源站出口上限。
可执行的准备动作：
- 提前按曝光预估推送热门图片到边缘和中间源,预热任务要打独立标签，和自然回源分开统计。
- 开启分层缓存,边缘未命中先问中间源，把源站挡在第二层后面。
- 配置回源合并和请求折叠,同一 URL 的并发回源只放一个出去，其余等待结果。
- 设置回源带宽上限和排队策略,宁可让少量请求多等几百毫秒，也别把源站打挂。
- 准备降级预案：命中率跌破阈值时，自动切换到低分辨率占位图或延长 TTL。
大促期间的看板要单独拉一个,把回源 QPS、回源带宽、回源平均耗时、源站 5xx 四条曲线并排放，只看命中率会漏掉”命中率还行但回源带宽已经顶格”的情况。
北京地区图片缓存监控一年要花多少钱
成本这块,两条路。
自建监控，用开源组件搭：日志采集加消息队列加列式存储加可视化，软件不花钱，花的是人力和机器，中型站点通常需要半个到一个运维的持续投入，机器成本随日志量线性上涨，日志保留 30 天和保留 180 天，成本能差好几倍。
采购商业监控或 CDN 自带报表，按日志量、探针数或请求量计费，开箱即用，但深度定制的空间有限，中小站点年成本多数在几万元量级，大型站点往往自建更划算。
北京地区的团队还要多考虑一层：本地节点覆盖密度高，跨地域回源的情况相对少，但多云和混合云架构下，回源可能跨云厂商，出流量费用要单独核算，做预算时把”回源流量费”和”监控工具费”分开列，别混在一个科目里。
收尾
图片缓存监控的价值不在于把命中率刷到多高,而在于异常发生时你能在十分钟内说清是缓存键、TTL、预热还是源站的问题，把命中率和回源比例绑在一起看，把日志字段和归一化规则提前定死，剩下的就是日常巡检和阈值微调。
关于图片缓存命中率与回源比例监控的常见问题
问：命中率一直上不去，但缓存配置看起来没问题，先查什么？
先查缓存键,把最近一周的回源 URL 抽样一千条，按路径和参数做聚合，看是不是同一张图因为参数顺序不同、跟踪参数不同裂成了多个键，其次查源站响应头，确认没有被应用层写成 private 或 no-store，最后查图片是否本身访问频次极低，冷图占比过高时，命中率有天花板，这时候该做的是预热和长尾图下沉，而不是继续调 TTL。
问：回源比例突然升高，怎么快速定位到具体业务？
按三个维度切片：业务标签、URL 目录、缓存状态码，先看是全局性升高还是局部，再看 MISS 和 EXPIRED 哪个涨得多。EXPIRED 集中上涨通常是 TTL 被改短或批量刷新；MISS 集中上涨多半是缓存键变了或节点扩容后缓存未预热，定位到目录后，用 curl -I 抽几条实际 URL 复现，基本就能锁定原因。
问：小团队没有专职运维，最简可行的监控方案是什么？
用 CDN 厂商自带的分析报表做主看板，把命中率、回源流量占比、回源带宽三条曲线设成周对比，本地再用 Nginx 的 $upstream_cache_status 落到日志，配一个轻量采集脚本每天汇总一次，写进表格或时序库，告警只设两条：命中率周同比跌幅超过预设幅度，回源带宽达到源站出口能力的警戒比例，两条告警加上每周一次的人工抽样核对，足以覆盖大多数中小图片业务的日常风险。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793290.html
