nginx静态资源状态分析需主动构造可监控路径：一用location隔离静态请求并独立记录日志；二定制log_format包含$status和$upstream_status；三通过awk实时统计或prometheus长期监控状态码分布。
要在 Nginx 中对静态资源请求做状态分类分析，关键不是“自动识别”，而是主动构造可区分、可提取、可统计的监控路径。核心动作有三步：先隔离静态请求，再确保状态码准确落日志，最后按需聚合分析。
用 location 精准圈出静态请求
静态资源没有内置标签，Nginx 不会自己判断哪个是 JS、哪个是图片。必须靠显式配置把它们“框出来”：
- 用前缀匹配常见静态路径，比如
location /static/、location /assets/ - 用正则匹配文件后缀，例如
location ~* .(js|css|png|jpg|woff2|svg)$（注意大小写不敏感） - 在这些 location 块里启用独立 access_log，如
access_log /var/log/nginx/static.log static;，避免和动态日志混在一起 - 可加一行
set $req_type "static";，后续日志格式中就能带入该标识，方便多维度筛选
定制日志格式，让状态码可定位、可分离
默认日志里的 $status 是 Nginx 返回给客户端的状态，但若静态资源走 CDN 或对象存储回源，还需知道上游返回码（$upstream_status）。推荐定义专用格式：
在 http 块中添加：
log_format static '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$upstream_status $request_time $upstream_response_time';
-
$status：最终响应码（如 200、304、404），反映客户端实际收到的结果 -
$upstream_status：后端（CDN/源站）返回码（如 502、504），用于排查回源失败 - 保留
$request_time和$upstream_response_time，可交叉判断慢响应是否卡在上游 - 字段顺序固定后，
awk '{print $9}'就能稳定取到$status（按上例是第9列）
实时统计与异常模式识别
日志有了，下一步就是快速看分布。不用等攒满一天，用管道命令就能滚动分析：
- 每秒输出当前分钟的状态码频次：
tail -n 0 -f /var/log/nginx/static.log | awk '{print $9}' | awk '{c[$1]++} END{for(i in c) print i, c[i]}' - 重点关注异常信号：
→304比例突然下降，说明缓存未生效（ETag 失效或 Last-Modified 生成异常）
→403/404集中出现，大概率是权限配置错误或前端构建路径变更未同步
→502/504上升，需检查 CDN 回源健康或源站静态文件服务是否挂掉 - 配合
grep可快速定位某类问题，例如：grep ' 404 ' /var/log/nginx/static.log | awk '{print $7}' | sort | uniq -c | sort -nr查看哪些 URL 被频繁 404
长期指标化：接入 Prometheus + Grafana
命令行适合应急，长期监控需要结构化指标。可通过 nginx-vts-module 或官方 stub_status 搭配 exporter 实现：
- 启用
ngx_http_vhost_traffic_status_module，它能按 server、upstream、location 维度统计请求数、响应码、流量等 - 配合
nginx-exporter抓取指标，暴露为 Prometheus 可采集的 endpoint - 在 Grafana 中建面板，按
status标签聚合，画出 2xx/3xx/4xx/5xx 的小时级趋势图，设置 4xx > 1% 触发告警 - 若已用 location 区分静态路径，指标天然带
location="/static/"或location="~*\.js$"标签，无需额外过滤
