Muliminty Note

Nginx status 监控与指标采集

5分钟阅读

Nginx status 监控与指标采集

1. 先理解这件事

日志更适合回看历史，监控更适合实时观察状态。

对新手来说，可以先记住：

  • 日志回答“刚才发生了什么”
  • 监控回答“现在系统怎么样”

Nginx 自带的 stub_status 可以让我们快速看到一些基础运行指标，比如：

  • 当前活跃连接数
  • 已接受连接总数
  • 已处理请求总数
  • 正在读取、写回、保持等待的连接数

对有经验的读者，更值得关注的是：

  • 这些指标如何与系统层监控、上游应用监控拼成完整可观测性链路
  • 哪些指标适合做告警，哪些只适合做趋势观察

2. 最小可用配置

server {
    listen 127.0.0.1:8080;
    server_name localhost;
 
    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

这段配置的重点有两个：

  • stub_status; 开启状态页
  • allow / deny 限制访问来源，避免直接暴露到公网

访问后常见输出大致如下：

Active connections: 3
server accepts handled requests
 100 100 180
Reading: 0 Writing: 1 Waiting: 2

3. 这些指标怎么理解

  • Active connections：当前活跃连接总数
  • accepts：总共接受过多少连接
  • handled：总共处理过多少连接，通常与 accepts 接近
  • requests：总共处理过多少请求
  • Reading：正在读取请求头的连接数
  • Writing：正在向客户端回写响应的连接数
  • Waiting：处于 keep-alive 等待中的空闲连接数

新手先看两件事就够了：

  • 活跃连接是否异常飙升
  • 请求总量是否持续增长

进阶再结合：

  • 连接状态结构是否异常偏向 Writing
  • 请求增长是否和访问日志、系统负载同步变化

4. 更适合生产的监控思路

仅有 stub_status 还不够，它更像最低成本的基础状态页。

更完整的思路通常是：

  1. 用 stub_status 看 Nginx 基础连接状态。
  2. 用访问日志看请求分布、状态码和耗时。
  3. 用系统监控看 CPU、内存、磁盘和网络。
  4. 用上游应用监控看接口耗时、错误率和线程池状态。

这样才能回答完整问题：

  • 是 Nginx 自己顶不住了
  • 还是上游应用慢了
  • 还是系统资源先打满了

5. 告警要怎么设

不建议一开始就把所有指标都做成告警。

更实用的做法是先围绕下面几类异常：

  • 活跃连接数持续异常升高
  • 5xx 状态码比例升高
  • 请求耗时显著上升
  • 上游连接失败或超时明显增多

也就是说：

  • stub_status 负责“看当前”
  • 访问日志和错误日志负责“看细节”
  • 告警负责“第一时间提醒”

6. 实践建议

  1. status 页面只允许内网、堡垒机或采集器访问。
  2. 不要把状态页直接暴露到公网。
  3. 监控指标要和日志字段设计一起考虑，避免各看各的。
  4. 基础监控先做起来，再慢慢补充趋势图、告警和容量观察。

7. 排查清单

  • stub_status 已正常开启
  • 状态页已限制访问来源
  • 已明确谁来采集这些指标
  • 已把状态页监控与访问日志、错误日志联合使用
  • 已选定少量高价值指标做初始告警

8. 相关笔记

关系图谱

反向链接