nginx监控响应时间需配置access log记录$request_time变量，结合日志分析工具或prometheus、elk等平台实现统计与告警；$request_time仅反映服务端处理耗时，不含网络延迟。
在 Nginx 中监控响应时间，核心是启用并解析 access log 中的 $request_time 变量，再结合日志分析工具或外部监控系统实现可视化与告警。
配置 access log 记录响应时间
Nginx 默认 access log 不包含响应时间，需手动添加 $request_time（单位：秒，精度毫秒）到日志格式中：
- 编辑 Nginx 配置（如
/etc/nginx/nginx.conf或站点 conf），在http块中定义自定义日志格式：
- 确保对应
server或location块中启用了该格式：access_log /var/log/nginx/access.log main; -
$request_time是从接收客户端请求头开始，到发送完响应头结束的总耗时；$upstream_response_time（可选）仅记录与上游服务（如 FastCGI、proxy）交互的时间，便于定位瓶颈是否在后端。
实时观察与简单统计
利用 Linux 命令快速查看响应时间分布：
- 查看最近 100 条请求的响应时间（按降序）：
tail -100 /var/log/nginx/access.log | awk '{print $NF}' | sort -nr | head -10 - 计算平均/最长/95 分位响应时间（需安装
awk扩展或用脚本）；例如用goaccess或ngxtop工具可直接解析日志生成统计报表。 - 注意：
$request_time是字符串字段，日志中可能含小数（如0.023），需确保 awk 处理时按数值排序而非字典序。
接入专业监控平台
单靠日志文本难以持续追踪趋势或设置告警，推荐对接成熟监控方案：
-
Prometheus + nginx-vts-exporter：通过 Nginx 的
stub_status或第三方模块（如nginx-vts-module）暴露指标，其中nginx_vts_server_request_seconds_total等直方图指标支持按区间统计响应时间（如 0.1s、0.5s、1s 等 bucket）。 -
ELK / Grafana Loki：将 access log 推送到 Elasticsearch 或 Loki，用 Kibana / Grafana 查询
request_time > 1.0的慢请求，并做聚合分析（如 P95、P99）。 - 若使用 OpenTelemetry，可通过 Nginx 的
opentelemetry_module（需编译）直接上报 trace 和 metrics，实现链路级响应时间下钻。
常见误区与注意事项
响应时间监控容易忽略的关键点：
-
$request_time不包含网络传输延迟（即客户端接收完整响应的时间），只反映 Nginx 服务端处理耗时。 - 开启日志记录本身有轻微性能开销，高并发场景建议异步写日志（
access_log /path main buffer=32k flush=1s;）。 - 如果 Nginx 做了多层代理（如 CDN → Nginx → Upstream），需配合
X-Request-Start或自定义 header 传递原始请求发起时间，才能估算端到端延迟。
