如何通过 log_format 引入 $request_time 建立网关层面的 SLO 业务服务等级监控-Nginx-PHP中文网

Nginx网关层通过log_format记录$request_time等字段，可构建轻量实时SLO监控体系；需包含$request_time、$status、$upstream_status，推荐补充$api_name、$http_x_request_id等业务维度字段，再经日志解析提取latency_seconds等指标用于P95/P99、错误率等计算。

如何通过 log_format 引入 $request_time 建立网关层面的 slo 业务服务等级监控

在 Nginx 网关层通过 log_format 记录 $request_time，是构建轻量、实时、可观测的 SLO（Service Level Objective）监控体系的关键一步。它不依赖应用代码改造，直接从请求入口捕获端到端延迟，为 P95/P99 延迟、错误率、可用性等核心 SLO 指标提供原始数据支撑。

配置 log_format 包含 $request_time 和关键业务字段

$request_time 是 Nginx 处理请求的总耗时（单位：秒，精度为毫秒），从接收到第一个字节开始，到发送完最后一个字节结束。要让日志具备 SLO 分析价值，需同时记录可区分业务维度的字段：

必须包含：$request_time（真实服务耗时）、$status（HTTP 状态码，用于计算错误率）、$upstream_status（上游状态，区分网关超时还是后端失败）
推荐补充：$http_x_request_id（链路追踪 ID）、$request_uri 或自定义 $api_name（通过 map 指令提取 API 路径，如 /v1/users → users_read）、$http_user_agent（识别客户端类型）
示例配置：

map $request_uri $api_name {
    ~^/v1/users$              users_list;
    ~^/v1/users/[0-9]+$        users_detail;
    ~^/v1/orders$              orders_create;
    default                    unknown;
}
<p>log_format slo_log '$time_iso8601\t'
'$remote_addr\t'
'$api_name\t'
'$status\t'
'$upstream_status\t'
'$request_time\t'
'$bytes_sent\t'
'$http_x_request_id';</p>

然后在 server 或 location 块中启用：access_log /var/log/nginx/slo_access.log slo_log;

用日志解析构建 SLO 核心指标管道

原始日志需经结构化处理才能计算 SLO。推荐使用轻量方案（如 Filebeat + Logstash 或直接用 Loki + Promtail）完成解析与打标：

将 $request_time 解析为浮点数字段（如 latency_seconds），单位统一为秒
基于 $api_name 和 $status 打出标签，例如：api=users_list status_code=200
定义“成功请求”语义：通常为 status >= 200 && status （或按业务排除 401/403）；若需区分网关失败（如 502/504）和上游失败（$upstream_status == 500），可额外打标 error_type=gateway_timeout 或 error_type=upstream_error

在 Prometheus/Loki 中定义 SLO 表达式

以 Prometheus 为例（配合 Promtail 抓取日志并暴露指标）：

延迟 SLO（如 P95 ≤ 800ms）：
histogram_quantile(0.95, sum(rate(latency_seconds_bucket{job="nginx-slo", api="users_list"}[1h])) by (le)) * 1000
可用性 SLO（如 99.9%）：
sum(rate(http_requests_total{job="nginx-slo", api="users_list", status=~"2..|3.."}[7d])) / sum(rate(http_requests_total{job="nginx-slo", api="users_list"}[7d])) > 0.999
错误预算消耗速率：用 rate(slo_error_seconds_total[1h]) 对比误差允许速率，驱动告警与复盘

注意边界与常见陷阱

$request_time 反映的是 Nginx 视角的完整请求生命周期，但不是纯后端耗时：

它包含网络传输时间（客户端→Nginx、Nginx→上游、Nginx→客户端），也包含 Nginx 自身处理开销（如 rewrite、limit_req）。若需精准后端耗时，应配合 $upstream_response_time 并做差值分析
对长连接、流式响应（如 SSE、gRPC-Web），$request_time 是整个连接关闭时才写入，可能滞后；建议对这类接口单独标记并监控 $upstream_header_time
日志采样不可少：高 QPS 场景下全量记录 I/O 压力大，可用 access_log ... slo_log buffer=64k flush=1s 缓冲，或加 if=$loggable 条件日志（如仅记录慢请求或错误请求）