应通过nginx增强模块（如nginx-module-vts）暴露带path、status、cache_status等标签的直方图指标，结合prometheus分位数计算与grafana可视化，实现按路径、状态码、缓存行为细分的响应时间分布分析。
直接看响应时间分布，关键不是堆指标，而是让每个请求的耗时能按路径、按状态、按缓存行为打上标签，再交由支持直方图和分位数计算的看板渲染。
用带 path 和 status 标签的直方图指标
Nginx 原生不暴露路径级响应时间分布，必须依赖增强模块。nginx-module-vts 是目前最成熟的选择——它会在 /vts/status/format/prometheus 接口暴露形如nginx_vts_server_request_seconds_bucket{server="default",path="/api/order",le="0.2"} 的指标。
其中 path 标签对应 location 或 URI 前缀，le 是响应时间上限（秒），这是绘制分布曲线的基础。
确保 Nginx 已编译并启用该模块，且在相关 server 或 location 块中开启统计：
location /api/ {
vhost_traffic_status on;
}
Prometheus 抓取后用 PromQL 拆解分布
在 Prometheus 中配置 job 抓取 http://nginx-host/vts/status/format/prometheus。
要查看 /login 路径的响应时间分布，可用：
- P95 趋势：
histogram_quantile(0.95, sum(rate(nginx_vts_server_request_seconds_bucket{path="/login"}[5m])) by (le)) - 多路径对比（叠加直方图）：
sum(rate(nginx_vts_server_request_seconds_bucket{path=~"/login|/static/.*"}[5m])) by (le, path)这样能在 Grafana 中画出不同路径的累计分布曲线（CDF），一眼看出哪个路径尾部延迟更重。
补充静态资源专用视角
静态请求不走 upstream，$upstream_response_time 无效。若只关心 .js/.css 等文件，建议配合 nginx-prometheus-exporter 的 --enable-static-stats 模式，它会单独暴露 nginx_static_request_seconds_bucket 指标，并自动标记 cache_status="HIT" 或 "MISS"。
在 Grafana 中加过滤：nginx_static_request_seconds_bucket{cache_status="MISS"}
可聚焦未命中缓存的真实磁盘 I/O 延迟，避免被高频 HIT 数据掩盖问题。
别忽略响应码维度
高延迟常集中在特定状态码。比如 304 请求本应极快，若 P95 > 100ms，说明 ETag 计算或文件元数据读取异常；499（客户端关闭）大量出现，则可能是前端超时设置过短，而非 Nginx 性能问题。
在指标中保留 $status 并关联到直方图（VTS 默认含此标签），就能做：histogram_quantile(0.90, sum(rate(nginx_vts_server_request_seconds_bucket{status="304"}[5m])) by (le))
不复杂但容易忽略
