必须用 $upstream_response_time 而非 $request_time，因其仅反映 nginx 与后端间的真实处理耗时，排除客户端网络、大文件传输等无关干扰，避免误报。
直接用 $upstream_response_time 做分级告警最有效——它剥离了客户端网络抖动和响应体传输开销，只反映后端真实处理能力。别拿 $request_time 告警，容易误报。
为什么必须用 $upstream_response_time 而不是 $request_time
因为 $request_time 包含了不可控变量：用户带宽差、手机弱网、大文件下载、POST body 缓存等待等，这些和后端性能完全无关。而 $upstream_response_time 从 Nginx 发出请求那一刻起计时，到收完上游响应头（或全部响应体）为止，只覆盖「Nginx ↔ 后端」这段链路。
常见误判场景：
- 移动端上传大图，
$request_time高达 8s，但$upstream_response_time只有 120ms → 实际后端毫发无损 - CDN 回源失败触发重试，
$request_time累加两次超时，$upstream_response_time却只记录最后一次成功响应 - HTTP/2 多路复用下，单个连接承载多个请求，
$request_time受队首阻塞影响，$upstream_response_time仍能准确反映单次后端调用耗时
$upstream_response_time 在日志格式中怎么写才不丢精度
Nginx 默认用秒级浮点数输出 $upstream_response_time，但小数点后只保留 3 位（如 0.045），对 P99 分析或毫秒级告警不够用。必须显式启用高精度支持：
- 确认 Nginx 版本 ≥ 1.13.5（低版本不支持毫秒级格式）
- 在
log_format中使用$upstream_response_time的毫秒变体：$upstream_response_time本身仍是秒单位，但可通过log_format拼接实现毫秒输出：log_format upstream_with_ms '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time $upstream_addr';
- 更稳妥的做法是改用
$upstream_connect_time、$upstream_header_time、$upstream_response_time三者拆分记录，便于定位慢在哪一环（建连？首字节？收全？）
分级告警阈值怎么设才不吵人
不能一刀切设「>500ms 告警」——不同接口类型、SLA 要求、上下游依赖差异巨大。推荐按接口路径 + 状态码组合打标后分级：
-
/api/order/create且$status == 200→ P95$upstream_response_time> 300ms 触发中等级别告警 -
/healthz或/metrics→ P99 > 50ms 就该立刻响铃（这类接口本应亚毫秒级） -
$upstream_response_time为空（即未转发到上游）但$status是 502/503 → 属于连接失败类问题，应单独归为「上游不可达」告警，不参与耗时统计 - 避免对
$upstream_response_time为-（短路未走 upstream）或0.000（极快响应）的请求做耗时告警，它们会污染统计基线
容易被忽略的采样与聚合陷阱
直接对原始 access.log 按行告警会爆炸——每秒几千条日志根本没法实时计算 P95。必须前置聚合：
- 用 Logstash / Fluent Bit / Vector 做 10 秒窗口聚合，输出
path+status+upstream_p95_ms到时序库（如 Prometheus、VictoriaMetrics） - 警惕
$upstream_response_time的单位混淆：它本质是秒，但很多监控系统（如 Grafana）默认当毫秒渲染，导致图表显示为「0.045ms」而非「45ms」 - 如果用了 keepalive 连接池，同一 upstream_addr 可能复用多次，
$upstream_response_time仍按每次请求独立记录，无需额外去重
真正难的是把「慢」和「异常」区分开：连续 5 分钟 P95 上升 30% 是趋势性退化；单次突增至 2s 但前后都正常，大概率是后端 GC 或锁竞争抖动——后者更适合用异常检测模型，而不是固定阈值。
