监控静态资源访问热点需构建“日志采集→频次聚合→热度映射→缓存联动”闭环：nginx输出独立静态日志，按小时聚合uri频次生成hotmap.map，通过map变量$cache_ttl动态控制expires，并结合proxy_cache inactive与stub_status验证命中率。
要监控静态资源的访问热点，关键不是实时抓每个请求，而是建立“日志采集 → 频次聚合 → 热度映射 → 缓存联动”的闭环。Nginx 本身不计算热度，但能高效输出原始访问数据，再配合轻量配置和外部分析，就能识别出哪些 JS、图片或 CSS 正在被高频访问。
单独记录静态请求日志
避免把静态和动态日志混在一起，否则后续统计会失真。在匹配静态资源的 location 块中启用独立日志：
- 用正则或路径前缀精准拦截静态请求，例如：
location ~* \.(js|css|png|jpg|woff2|svg)$ { ... } - 为该 location 配置专用 access_log，格式建议包含时间、URI、状态码和响应时间：
access_log /var/log/nginx/hot_access.log hotlog; - 在
http块中定义对应格式：log_format hotlog '$time_iso8601 $uri $status $body_bytes_sent $request_time';
按周期统计 URI 访问频次
热度本质是单位时间内的访问密度。不需要秒级实时，按小时或每天聚合更稳定、开销更低：
- 用简单脚本统计最近一小时最热的 20 个资源：
awk '$1 > strftime("%Y-%m-%d %H:00:00", systime()-3600) {print $2}' /var/log/nginx/hot_access.log | sort | uniq -c | sort -nr | head -20 - 把结果写入一个 map 文件（如
/etc/nginx/conf.d/hotmap.map），将高频 URI 映射为长缓存时间，低频的设为短缓存或跳过缓存 - 示例内容：
map $uri $cache_ttl {<br> default "10m";<br> "~^/static/js/vendor\..*\.js$" "1d";<br> "~^/static/img/avatar\.webp$" "4h";<br>}
用 map 变量驱动缓存策略
热度不能只看一眼报表，要让它真正影响服务行为。通过 $cache_ttl 控制不同资源的缓存有效期：
- 在静态资源 location 中引用该变量：
expires $cache_ttl;<br>add_header X-Cache-TTL $cache_ttl;
- 每次更新 map 文件后执行
nginx -t && nginx -s reload，配置即刻生效 - 搭配
proxy_cache_path ... inactive=15m，冷资源 15 分钟无访问自动淘汰，不占磁盘
辅助验证：用 stub_status 观察缓存效果
光看日志频次不够，还要确认“热资源是否真被缓存住了”：
- 开启
stub_status，并用nginx-vts-exporter抓取指标 - 重点关注：
nginx_http_cache_hits_total{zone="static_cache"}（缓存命中数）nginx_http_requests_total{handler="static"}（总静态请求数） - 计算缓存命中率 = hits / requests，若热资源命中率长期低于 85%，说明
inactive设置过短或proxy_cache_valid不匹配
