核心思路是通过定制日志格式精准标记静态资源请求，分离存储并实时扫描状态码与上游响应等异常组合；具体分四步：一、定义含$request_uri、$status、$upstream_status等字段的static_detail日志格式；二、用location匹配静态路径（如.js|css或^~/static/）单独记录至static-404-5xx.log；三、用shell脚本每60秒统计该日志中404/5xx数量超10则告警；四、告警后用awk提取高频失败URL及上下文快速定位构建漏传、CDN缓存、权限或磁盘问题。
核心思路是：让日志里能明确区分静态资源请求，并附带状态码、响应时间、上游状态等关键字段，再用脚本或工具持续扫描这些字段的异常组合。
一、先定义带静态特征的日志格式
静态资源路径通常有规律，比如 /static/、/assets/、.js/.css/.png 等。log_format 本身不判断路径，但可通过变量把请求路径和状态信息一起记下来，为后续过滤打基础：
- 在 http 块中定义一个专用格式，例如：
- $request_uri 必须保留，它是后续 grep 或 awk 匹配静态路径的关键；
- $status 和 $upstream_status 要同时记录，5xx 类错误常需比对两者（比如 $status=502 但 $upstream_status=- 表示 upstream 连不上）；
- 如果用了 CDN 或反向代理，加 $http_x_forwarded_for 可辅助定位真实客户端来源。
二、给静态资源路径单独开 access_log
避免和动态接口日志混在一起，提升分析效率。在 server 或 location 块中匹配静态路径并启用该格式：
- 匹配常见静态后缀：
access_log /var/log/nginx/static-404-5xx.log static_detail;
# 其他静态配置如 expires、gzip 等可继续加
}
- 或者按前缀匹配（更稳妥，覆盖构建产物目录）：
access_log /var/log/nginx/static-404-5xx.log static_detail;
}
- 注意：确保该 location 没被更高优先级的 rewrite 或 proxy_pass 覆盖。
三、用轻量脚本实时捕获异常模式
不用上 ELK，一条 shell 管道就能实现分钟级告警：
- 监控最近 1 分钟内，静态日志中 404 或 5xx 出现超过 10 次：
echo "$line" | awk '$4 ~ /^404$|^5[0-9]{2}$/ {print $0}' | if [ $(wc -l) -gt 10 ]; then
echo "$(date): 静态资源异常突增 $(wc -l) 条" | mail -s "ALERT: Nginx static 404/5xx" admin@example.com
fi
done
- 更实用的做法是每 60 秒汇总一次（避免高频触发）：
count=$(awk '$4 ~ /^404$|^5[0-9]{2}$/ {count++} END {print count+0}' /var/log/nginx/static-404-5xx.log)
if [ "$count" -gt 10 ]; then
echo "$(date): $count 个静态异常响应" | logger -t nginx-static-alert
# 此处接企业微信/钉钉 webhook 或短信网关
fi
sleep 60
# 日志轮转后需清空计数或改用 tail -n +$(stat -c %s ...) 定位起始偏移
done
四、定位时直接聚焦问题 URL 和上下文
告警触发后，别只看总数，马上查具体哪几个路径在崩：
- 快速提取高频失败路径（含状态码）：
- 其中 $12 是 $request_uri（按上面 log_format 顺序），若字段序号不同，请先用 head -1 static-404-5xx.log | awk '{print NF; print $0}' 校验；
- 发现大量 /static/js/app.abc123.js 404？立刻检查构建产物是否漏传或 CDN 缓存了旧版本；
- 发现 /assets/logo.png 500？结合 $request_time 和 $upstream_status 判断是文件权限问题还是磁盘满导致读取失败。
