状态码是access_log中反映请求服务质量的核心监控信号，用于识别异常模式、支撑分层告警、关联性能分析；需确保日志格式显式包含$status，并在反向代理场景下合理配置以获取真实上游状态码。
状态码是 access_log 中最核心的监控信号之一，它直接反映每次请求的服务结果质量，是构建可观测性体系的基础字段。
状态码在监控中的实际作用
HTTP 状态码（如 200、301、404、502）不是简单标记“成功”或“失败”，而是服务健康度的即时快照：
- 快速识别异常模式：连续出现大量 500 表示后端应用崩溃；突增的 502/504 指向上游服务不可达或超时；499（客户端主动断连）激增可能意味着前端加载中断或网络抖动
- 支撑分层告警：可按状态码段设置不同级别告警——4xx 告警关注用户侧问题（如错误链接、权限缺失），5xx 告警触发紧急响应（服务不可用）
- 关联性能分析：结合 $request_time 和 $status，能精准定位“慢且失败”的请求（如 status=504 且 request_time 接近 upstream_timeout），避免误判为单纯超时
确保状态码被可靠记录的关键配置
默认 combined 或 main 格式已包含 $status，但需注意两个易忽略点：
- 日志格式定义中必须显式包含 $status 字段，例如：
log_format main '$remote_addr [$time_local] "$request" $status $body_bytes_sent ...'; - 若使用反向代理，Nginx 默认记录的是它自己返回给客户端的状态码。要获取上游真实状态码，需启用 proxy_intercept_errors off 并配合 $upstream_http_x_status_code（需上游透传）或使用 $upstream_status（记录 Nginx 与上游交互的结果码）
从状态码延伸出的有效监控实践
仅看单条日志里的状态码价值有限，真正起效的是聚合与下钻：
- 按分钟统计各状态码数量，绘制折线图——可发现周期性 429（限流）或凌晨批量 401（Token 过期）等规律
- 对 4xx 请求，提取 $request_uri 和 $http_user_agent，快速判断是爬虫试探、旧链接残留，还是新版前端接口调用错误
- 对 5xx 请求，叠加 $upstream_response_time > 2.0 和 $status = 504，可过滤出因上游响应过慢导致的网关超时，而非后端完全宕机
状态码本身不产生指标，但它让每一条日志具备了可分类、可计数、可归因的能力。它是把原始访问流转化为有效监控数据的第一道阀门。
