应使用 $upstream_response_time 构建动态基线，按接口维度打标（如 business_tag="order"），通过滚动1小时P95+7天漂移检测（均值+2σ）实现自适应阈值，并过滤异常时段与低质流量。
对核心接口响应时间建立基线监控，不是设一个固定阈值，而是让系统自己学出“正常波动范围”。关键在三点：选准指标、用对窗口、动态更新。
明确用哪个响应时间指标
别直接用 $request_time 做基线——它含网络传输、SSL、Nginx 重写等干扰项。真正反映后端健康度的是 $upstream_response_time（即后端真实处理耗时）。如果日志里没这个字段，要在 Nginx 配置中显式记录：
- 在 log_format 中加入
$upstream_response_time，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time'; - 确保后端服务返回了
X-Response-Time头，Nginx 可通过proxy_pass_request_headers on;透传并记录
按业务路径打标，隔离核心接口
基线必须按接口维度建，不能全站混算。推荐两种打标方式：
- 用
nginx-prometheus-exporter解析 access log，配合自定义字段如$http_x_business_tag或正则提取 URI 路径（如/api/v1/order/create），导出为 Prometheus 标签business_tag="order" - 若使用 VTS 模块，直接在 location 块中加
vhost_traffic_status_filter_by_set_key $uri /api/v1/(order|pay|refund);，天然带标签
用滚动分位数 + 时间窗口构建动态基线
静态 P95=800ms 很容易误报。应基于近期稳定流量自动计算“当前合理上限”：
- 在 Prometheus 中写基线表达式：
histogram_quantile(0.95, sum(rate(nginx_upstream_response_msecs_bucket{business_tag="order"}[1h])) by (le))，用过去 1 小时数据算 P95 - 再叠加一个“基线漂移检测”：比如
avg_over_time(histogram_quantile(0.95, sum(rate(...[1h])) by (le))[7d:1h])算 7 天内每小时 P95 的均值与标准差，当实时 P95 > 均值 + 2σ 时触发告警 - Grafana 面板中，把这条基线作为虚线叠加在实时 P95 曲线上，一目了然是否越界
排除异常时段，让基线更干净
发布、大促、定时任务都会拉高延迟，直接纳入会污染基线。建议：
- 在 Prometheus 抓取时加 relabel 规则，过滤掉已知低价值流量（如健康检查路径
/healthz、爬虫 UA） - 用 Grafana 变量或 PromQL 的
unless逻辑，在计算基线前剔除 5xx 错误率 > 5% 的分钟窗口 - 对新上线接口，先跑 3–5 天冷启动期，用
count_over_time确保每分钟有效请求数 ≥ 100，再启用基线计算
