在 linux 中监控 nginx 缓存失效后的回源请求流量，核心做法是配置 nginx 的 log_format 以记录缓存状态变量 $upstream_cache_status，并通过日志分析工具（如 awk、grep 或 elk）筛选出状态为 miss 的请求。当缓存未命中时，nginx 会向后端服务器发起回源请求，此时 $upstream_cache_status 的值通常为 miss。通过统计这些 miss 记录的频率和来源 ip，即可量化回源流量。
Nginx 如何配置日志格式以捕获缓存状态
要获取缓存状态，必须在 Nginx 配置文件（通常是 nginx.conf 或站点配置）中定义包含 $upstream_cache_status 变量的日志格式。默认日志格式不包含此字段，因此需要自定义。配置完成后，Nginx 会在每次处理请求时，根据缓存是否命中、是否过期或是否被主动清除来更新该变量的值。对于回源请求，该值为 MISS；若命中则为 HIT；若因强制刷新等策略导致失效后重新获取，也为 MISS。正确配置日志格式是监控的基础。
server {
listen 80;
server_name example.com;
# 定义包含缓存状态的日志格式
log_format cache_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'cache_status=$upstream_cache_status';
access_log /var/log/nginx/cache_access.log cache_log;
location / {
proxy_pass http://backend;
# 启用缓存
proxy_cache my_cache;
# 设置缓存键
proxy_cache_key $scheme$request_method$host$request_uri;
}
}
上述配置将日志输出到 /var/log/nginx/cache_access.log，每行末尾附加 cache_status=MISS 或 cache_status=HIT。重启 Nginx 后，新的访问日志将包含所需信息。可通过 tail -f /var/log/nginx/cache_access.log 实时观察。
如何使用命令行工具统计回源流量
配置好日志后，可使用 Linux 命令行工具对日志文件进行统计分析。最常用的方法是结合 grep 和 awk 提取状态为 MISS 的行，并进一步统计请求数量、带宽或来源 IP。例如，统计过去一小时内所有回源请求的数量，可以使用 awk 解析时间戳和状态字段。这种方法无需额外安装软件，适合快速排查和实时监控。
# 统计最近1小时内的MISS请求总数
awk -v now=$(date +%s) '
$4 ~ /\[/ {
# 提取时间戳部分，假设格式为 [DD/Mon/YYYY:HH:MM:SS +ZZZZ]
gsub(/\[|]/, "", $4);
cmd = "date -d \"" $4 "\" +%s";
cmd | getline ts;
close(cmd);
if (now - ts <= 3600 && $NF == "cache_status=MISS") {
count++;
}
}
END { print "Total MISS in last hour:", count+0; }' /var/log/nginx/cache_access.log
# 统计每个IP的回源请求次数
awk '$NF == "cache_status=MISS" { ip[$1]++ } END { for (i in ip) print ip[i], i }' /var/log/nginx/cache_access.log | sort -nr
第一段命令计算最近一小时的 MISS 请求数，第二段命令按 IP 统计回源频次。结果可直接用于判断是否存在异常回源（如某个 IP 高频触发缓存失效）。若需更复杂的分析，可将日志导入 Prometheus + Grafana 或 ELK Stack，通过正则匹配 cache_status=MISS 构建指标面板。
缓存失效后回源请求的具体触发条件有哪些
回源请求（即 $upstream_cache_status 为 MISS）不仅发生在首次访问时，还由多种缓存失效条件触发。常见条件包括：缓存条目 TTL（生存时间）到期、后端返回 Cache-Control: no-cache 或 no-store、客户端发送 Cache-Control: no-cache 请求头、使用 proxy_cache_purge 模块主动清除缓存、或缓存空间不足导致 LRU 淘汰。在这些情况下，Nginx 无法提供缓存副本，必须向后端发起新请求。理解这些条件有助于优化缓存策略，减少不必要的回源压力。
