Nginx 本身不内置响应时间阈值告警机制，但可通过日志分析 + 外部工具（如 Prometheus + Grafana 或 ELK）实现高延时请求的监控与告警；核心是记录 $request_time，用 map 标记慢请求，再接入监控系统触发告警，并需结合 $upstream_response_time 等指标区分真实瓶颈。
Nginx 本身不内置响应时间阈值告警机制，但可通过日志分析 + 外部工具（如 Prometheus + Grafana 或 ELK）实现高延时请求的监控与告警。核心思路是：记录每个请求的处理时间，提取超阈值请求，再由监控系统触发告警。
1. 启用并配置 $request_time 日志变量
Nginx 提供 $request_time 变量（单位：秒，精度为毫秒），表示从接收客户端第一个字节到发送完最后一个字节的总耗时。需在 log_format 中显式记录：
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time';
access_log /var/log/nginx/access.log main;
注意：$request_time 包含网络传输时间（如客户端慢速上传），若只关注服务端处理耗时，可搭配 $upstream_response_time（仅 upstream 处理时间）对比使用。
2. 定义响应时间阈值并标记异常请求
可在日志中直接标记超时请求，便于后续过滤。例如，定义阈值为 1 秒，用 map 指令生成标记字段：
map $request_time $slow_request {
~^[1-9]\d*\.\d+|0\.[2-9]\d*|1\.0 "1"; # >1.0s 或 0.2–0.999s（按需调整）
default "0";
}
log_format main_ext '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$request_time $slow_request';
access_log /var/log/nginx/access.log main_ext;
这样每行日志末尾会多一个 0 或 1，方便用日志采集器（如 Filebeat、Fluent Bit）按 $slow_request == "1" 过滤高延时事件。
3. 接入监控告警系统
单纯写日志不够，需闭环告警。常见方案：
-
Prometheus + nginx-vts-exporter：通过 vts 模块暴露实时指标（含平均/分位响应时间），设置 PromQL 告警规则，例如：
nginx_vhost_request_seconds_sum{vhost=~".+"} / nginx_vhost_request_seconds_count > 1（均值超 1s） -
ELK（Elasticsearch + Logstash + Kibana）：Logstash 解析 access log 中
$request_time字段，建立数值型字段；Kibana 设置阈值告警（Watcher 或 Alerting）或看板高亮慢请求 - 轻量级脚本轮询：用 awk/grep 实时扫描 access.log，发现连续 5 分钟内超时率 > 5% 则调用 webhook 发送企业微信/钉钉告警（适合小规模场景）
4. 补充建议：区分真实瓶颈与干扰因素
高延时不等于后端问题，需结合上下文判断：
- 检查
$upstream_response_time是否也高：若远小于$request_time，说明延时主要来自客户端（如弱网上传大文件）或 Nginx 自身（SSL 握手、大量 rewrite） - 开启
error_log的 warn 级别，观察是否有upstream timed out或worker process is shutting down等线索 - 对特定 location 设置
proxy_read_timeout和send_timeout，避免单个慢请求阻塞 worker
不复杂但容易忽略：阈值设定要结合业务实际（API 接口通常 200ms 内，文件下载可放宽），且告警需配静默期和分级（如 1s 告警、3s 严重），避免噪音。
