nginx缓存监控需依托vts模块暴露指标，经nginx-vts-exporter采集并打标关联业务维度，再结合多指标交叉告警实现闭环。
要让 Nginx 缓存状态真正发挥监控价值，关键不是“能查到”，而是“能进系统、可下钻、会告警”。Nginx 本身不直接输出缓存命中率等指标，必须借助模块暴露结构化数据，再经采集器转成监控系统能理解的格式。
确认缓存指标来源：vts 模块是刚需
内置 stub_status 完全不提供缓存相关数据。必须启用 nginx-module-vts（Vhost Traffic Status），它原生支持 FastCGI、proxy、uwsgi 等各类缓存的统计维度，包括：
-
缓存命中/未命中/过期/绕过次数（如
cache_hits,cache_misses） - 各缓存区域的大小与使用率
- 按 upstream 或 server_name 维度拆分的缓存行为
配置示例（在 http 块中）：
vhost_traffic_status_zone;vhost_traffic_status_cache_zone;
并在 location 中启用 JSON 输出：
location /status {vhost_traffic_status_display;
vhost_traffic_status_display_format json;
}
采集器选择：优先用 nginx-vts-exporter
它专为 VTS 设计，开箱即得缓存指标，无需额外解析或映射。启动时指定状态页地址即可：
暴露的指标形如：nginx_vts_cache_hits_total{cache="proxy",zone="default"}nginx_vts_cache_bytes_total{cache="fastcgi",zone="php_pool"}
若已用 Prometheus，直接在 scrape_configs 中添加该 exporter 地址；若用 Telegraf，需启用 inputs.nginx_vts 插件并指向同一 /status 接口。
打标与关联：让缓存数据带身份
单看“总命中率”意义有限。必须把缓存指标和业务上下文绑定：
- 为每台 Nginx 实例配置唯一
instance标签（如nginx-edge-prod-01） - 通过 relabel 或静态配置，注入
env="prod"、role="edge"、upstream="api_backend"等标签 - 在 Grafana 查询中，用
sum by (upstream, cache) (rate(nginx_vts_cache_hits_total[5m]))快速定位哪个后端+哪种缓存异常
告警与基线：从数字到行动
缓存命中率低于阈值只是表象，需结合其他指标交叉判断：
- 命中率骤降 +
nginx_vts_upstream_requests_total激增 → 后端压力大，缓存穿透风险 - 命中率稳定但
nginx_vts_cache_bytes_total持续增长 → 缓存污染或 key 设计不合理 - 某 upstream 的
cache_misses突增，而其他正常 → 该服务返回了不可缓存响应头（如 Cache-Control: no-store）
在 Prometheus 中配置类似规则：
groups:- name: nginx-cache-alerts
rules:
- alert: LowCacheHitRate
expr: 100 * sum(rate(nginx_vts_cache_hits_total[10m])) by (instance) / sum(rate(nginx_vts_cache_requests_total[10m])) by (instance) for: 5m
