要实时展示http状态码分布，需解析access.log中的$status字段或启用nginx-vts模块获取分组统计，再通过kibana、grafana或sls等工具可视化，须区分4xx/5xx、按虚拟主机拆分，并关联响应时间与上游地址进行根因分析。
直接用 Nginx 自带的 /nginx_status 页面只能看到连接数和请求总数，没法看状态码分布。要实时展示 200、404、500 这类状态码的占比和趋势，得靠日志解析 + 可视化工具组合实现。
状态码数据从哪来
两种主流路径：
-
访问日志解析：把
access.log中的$status字段提取出来，转成结构化数据（比如 JSON 格式），再送入 Elasticsearch / Loki / SLS 等日志系统 -
vts 模块统计：启用
nginx-module-vts后，通过/status接口可直接获取各虚拟主机、各 location 的状态码汇总（含 2xx/3xx/4xx/5xx 分组），支持 JSON 输出，适合对接 Prometheus 或 Grafana
可视化面板怎么配
以常见组合 ELK 和 Grafana 为例：
-
Kibana Dashboard：在 Visualize 里建饼图，字段选
status，聚合方式为 Count；再加一个柱状图，X 轴是时间，Y 轴是count()，过滤条件加status: 500就能盯住错误突增 -
Grafana + Prometheus：用
nginx-vts-exporter抓取 vts 数据后，在 Grafana 里用nginx_vts_server_zone_code_2xx_total这类指标画折线图，叠加 4xx/5xx 曲线，设置告警阈值（如 5xx 占比超 1% 持续 2 分钟） -
阿里云 SLS：开启索引后，直接写分析语句：
* | SELECT status, count(*) AS cnt GROUP BY status ORDER BY cnt DESC，结果自动渲染成饼图或表格，支持下钻到具体 URI
关键细节别漏掉
光有图不够，得让数据真正反映问题：
- 区分 客户端错误（4xx） 和 服务端错误（5xx）：404 多可能是配置或链接失效；502/504 往往指向上游超时或不可达
- 按 虚拟主机或 upstream 名称 维度拆分，能快速定位是哪个业务或后端出问题
- 状态码统计要和 响应时间、上游地址 关联查，比如 504 高发时同步看
upstream_response_time是否飙升 - 日志格式建议统一用 JSON，避免正则解析不稳定，尤其在高并发场景下
