7.6.6 性能监控与容量规划指标

本节聚焦以可观测性数据支撑 Nginx 性能监控与容量规划，核心是建立稳定可用的指标体系、采集周期与容量模型，避免单点瓶颈和突发流量冲击，并给出可执行示例与排错路径。

原理与数据流草图

文章图片

关键性能指标（建议全量采集）
- 吞吐类：QPS/RPS、带宽吞吐（in/out）、上游请求速率
- 时延类：P50/P90/P99响应时间、上游连接时延、DNS解析时延
- 连接类：Active/Reading/Writing/Waiting、accepts/handled/requests
- 错误类：4xx/5xx比例、上游超时/重试、连接失败率
- 资源类：CPU使用率（us/si/wa）、内存RSS、上下文切换、fd占用
- 系统瓶颈：磁盘IOPS/延迟、网卡丢包、TCP重传率
- 缓存效果：cache hit/miss/expired、upstream cache status

容量规划核心指标与经验阈值
- CPU：稳定运行区间建议 <60%，告警阈值 70%/85%
- 内存：常驻内存+连接峰值占用，保持可用内存 >20%
- FD：最大连接数预留 2~3 倍峰值，避免“too many open files”
- 带宽：峰值带宽不超过链路能力的 70%，预留突发能力
- 响应时间：P95/P99上升趋势作为扩容信号
- 错误率：5xx >0.5% 持续 5 分钟触发扩容与排障
- 连接数：Waiting 持续高位且增长，表示后端瓶颈或队列拥塞

容量模型与测算方法（含示例）
- 基于峰值模型：按历史峰值×安全系数（1.3~2.0）规划
- 基于SLA模型：结合SLA的P99响应阈值反推可承载QPS
- 基于压测模型：用压测得到“拐点QPS”作为单实例容量上限

示例计算（可直接替换为你的数据）：
- 峰值 QPS=8000，平均响应=40ms
- 理论并发 ≈ 8000 × 0.04 = 320
- 若单实例支持稳定并发 250，则需要实例数 ≈ 320/250=1.28，向上取整 2 台
- 安全系数 1.5：2 × 1.5 = 3 台

监控采集与可视化（安装+配置+验证）

1) 开启 stub_status（Nginx）
文件：/etc/nginx/conf.d/status.conf 

server {
    listen 127.0.0.1:8080;
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

重载并验证： 

nginx -t && systemctl reload nginx
curl -s http://127.0.0.1:8080/nginx_status
# 预期输出包含 Active/Reading/Writing/Waiting

2) 安装 nginx-exporter（示例以 systemd 方式） 

useradd -r -s /sbin/nologin nginxexp
curl -L -o /usr/local/bin/nginx-prometheus-exporter \
  https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v1.1.0/nginx-prometheus-exporter_1.1.0_linux_amd64
chmod +x /usr/local/bin/nginx-prometheus-exporter

cat >/etc/systemd/system/nginx-exp.service <<'EOF'
[Unit]
Description=Nginx Prometheus Exporter
After=network.target

[Service]
User=nginxexp
ExecStart=/usr/local/bin/nginx-prometheus-exporter \
  -nginx.scrape-uri=http://127.0.0.1:8080/nginx_status
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now nginx-exp
curl -s http://127.0.0.1:9113/metrics | head

3) Prometheus 抓取配置
文件：/etc/prometheus/prometheus.yml 

scrape_configs:
  - job_name: "nginx"
    static_configs:
      - targets: ["127.0.0.1:9113"]

重载并检查： 

systemctl reload prometheus
curl -s http://127.0.0.1:9090/api/v1/targets | jq '.data.activeTargets[]|.labels.job,.health'

4) Grafana 查询示例（PromQL） 

# Nginx 当前活跃连接
nginx_connections_active

# QPS（1分钟速率）
rate(nginx_http_requests_total[1m])

# 5xx 错误率（需结合日志/应用指标）
sum(rate(nginx_http_requests_total{status=~"5.."}[5m]))
/
sum(rate(nginx_http_requests_total[5m]))

关键命令解释与定位要点
- curl /nginx_status：验证 Nginx 暴露连接指标是否正常
- ss -s：快速查看 TCP 连接状态分布
- pidstat -u -p $(pidof nginx) 1：定位 CPU 飙升与上下文切换
- nginx -V：确认模块启用情况（如 stub_status）

示例： 

ss -s
# TCP:   123 (estab 80, closed 30, orphaned 0, synrecv 0, timewait 10/0), ports 0

pidstat -u -p $(pidof nginx) 1
# %usr %sys 可用于判定 CPU瓶颈

常见排错清单（症状→定位→处理）
1) 访问 /nginx_status 403
- 定位：确认 allow/deny 是否限制来源
- 处理：将监控端 IP 加入 allow，或使用 127.0.0.1 本地采集

2) Exporter 无数据
- 定位：curl 127.0.0.1:9113/metrics 是否为空
- 处理：确认 -nginx.scrape-uri 正确、stub_status 可访问

3) QPS 正常但 P99 急升
- 定位：查看上游超时、后端连接耗尽
- 处理：增加上游实例、优化 upstream keepalive、限制突发流量

4) 连接数高且 Waiting 持续增长
- 定位：netstat -anp | grep nginx、后端响应慢
- 处理：扩容后端、加缓存、启用限流

容量预警与扩容触发策略（示例规则） 

# Prometheus 告警示例（片段）
- alert: NginxHighP99
  expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.8
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "P99 响应时间过高"

- alert: Nginx5xxRateHigh
  expr: sum(rate(nginx_http_requests_total{status=~"5.."}[5m])) /
        sum(rate(nginx_http_requests_total[5m])) > 0.005
  for: 5m

实践演练（含步骤）
1) 手工压测并找拐点 QPS 

# 安装 wrk
yum install -y epel-release && yum install -y wrk
# 10 并发、持续 60s
wrk -t2 -c10 -d60s http://127.0.0.1/

观察 QPS 与 P99 变化，记录“拐点QPS”。

2) 模拟扩容判断
- 当 P99 > 0.8s 且 5xx >0.5% 持续 5 分钟，扩容 1 台
- 观察扩容后 P99 是否回落并更新容量模型

练习题
1) 用 stub_status 与 nginx-exporter 搭建完整采集链路，截图指标页面。
2) 根据 1 小时监控数据，计算并给出“单实例峰值并发”与“扩容阈值”。
3) 模拟 5xx 升高，写出你的排查步骤与对应命令。

实践要点
- 指标必须与业务峰谷联动，按小时/日/周维度观察趋势
- 高峰前预热缓存与上游连接池，避免冷启动抖动
- 记录扩容与故障数据，反向修正容量模型与阈值