Debian部署Nginx后如何监控系统资源？指标、命令与告警设置

在 Debian 上部署 Nginx 后，建议把监控分成三层：先用系统命令确认 CPU、内存、磁盘、网络和文件描述符的实时状态，再通过 Nginx stub_status 观察连接状态，最后由 Prometheus 采集指标并按照“持续时间 + 阈值 + 严重级别”触发告警。这样既能发现资源耗尽，也能区分短时峰值与持续性故障。

以下步骤适用于使用 systemd 的 Debian 服务器，假设 Nginx 已经安装并正常提供服务。示例中的 IP、邮箱和阈值需要根据实际环境调整，命令应在具备 sudo 权限的账号下执行。

一、准备条件与基线检查

1. 确认系统、Nginx和服务状态

先确认系统版本、Nginx 配置路径以及当前服务状态：

cat /etc/debian_version
uname -a
nginx -v
sudo systemctl status nginx --no-pager
sudo nginx -t

预期结果包括：

• nginx -t 显示 syntax is ok 和 test is successful；
• Nginx 服务状态为 active (running)；
• 能够确认当前使用的是 Debian 系统自带的 systemd 服务管理方式。

如果 nginx -t 已经失败，不要继续覆盖配置。先执行以下命令查看具体错误：

sudo journalctl -u nginx -n 80 --no-pager

2. 备份即将修改的配置

本教程会新增 Nginx 状态配置，并可能安装系统指标采集器。修改前先备份 Nginx 配置目录和 Prometheus 配置文件。备份不会影响正在运行的服务，但会占用少量磁盘空间。

sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%F-%H%M%S)

if [ -f /etc/prometheus/prometheus.yml ]; then
    sudo cp -a /etc/prometheus/prometheus.yml \
      /etc/prometheus/prometheus.yml.backup.$(date +%F-%H%M%S)
fi

检查基础资源：

nproc
uptime
free -h
df -hT
df -ih
ss -s

这些结果用于建立正常基线。例如，一台空闲的 Nginx 服务器可能长期保持较低 CPU 使用率，但磁盘空间或 inode 可能因日志增长逐步下降。告警阈值不应只依据某一次查看结果设置，而应参考业务高峰期的正常范围。

二、使用Debian命令检查系统资源

1. 检查CPU、负载和内存

安装常用的系统观察工具：

sudo apt update
sudo apt install -y procps sysstat curl

实时查看 CPU 和内存：

vmstat 1 5
free -h
mpstat -P ALL 1 5

vmstat 重点关注以下字段：

• r：等待运行的进程数量。长时间明显高于 CPU 核数，说明存在运行队列堆积；
• us：用户态 CPU 使用率；
• sy：内核态 CPU 使用率；
• wa：等待磁盘 I/O 的时间比例；
• si、so：交换分区换入、换出。如果持续非零，通常需要进一步检查内存压力；
• st：虚拟化环境中被宿主机“偷走”的 CPU 时间。

free -h 不要只看 free 列，应重点看 available。Linux 会将空闲内存用于缓存，因此“已使用内存较高”并不一定表示内存不足。可以先采用以下参考范围：

负载值不能单独证明 Nginx 已经故障。CPU 密集型任务、磁盘等待和不可中断进程都会推高负载，因此要结合 vmstat、磁盘延迟和 Nginx 请求状态判断。

2. 检查磁盘空间、inode和I/O

查看分区空间与 inode：

df -hT
df -ih

重点检查 /、Nginx 日志所在分区以及存放业务文件的分区。可采用以下参考阈值：

• 磁盘剩余空间低于 15%：预警；
• 磁盘剩余空间低于 8%：严重告警；
• inode 剩余低于 10%：预警；
• inode 剩余低于 5%：严重告警。

空间和 inode 是两个不同指标。大量小文件可能先耗尽 inode，即使 df -h 仍显示有剩余容量。

查看磁盘 I/O：

iostat -xz 1 3

如果提示找不到 iostat，说明 sysstat 未安装。输出中可重点观察：

• await：I/O 请求平均等待时间；
• %util：设备忙碌程度；
• r/s、w/s：读写请求速率；
• rkB/s、wkB/s：读写吞吐量。

%util 长时间接近 100%，同时 await 上升，通常比单独看到磁盘空间不足更能说明 I/O 已成为瓶颈。不要把一次短暂的高 %util 直接设置为告警，否则日志轮转或备份时容易产生噪声。

3. 检查连接数和文件描述符

ss -s
ss -ltnp | grep -E ':(80|443)\b'
cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max

查看 Nginx 进程当前打开的文件描述符：

pidof nginx
sudo ls -l /proc/$(pgrep -o nginx)/fd 2>/dev/null | wc -l

如果文件描述符接近系统上限，常见表现包括无法建立新连接、日志无法打开或上游连接失败。此时应先确认是否存在连接泄漏、异常长连接或配置了过低的 worker_connections，不要直接盲目提高系统限制。

三、启用Nginx连接状态监控

1. 增加本机状态接口

Nginx 的 stub_status 可以提供活动连接、已接受连接、已处理连接和请求数等基础数据。建议只监听本机回环地址，不要直接暴露到公网。

先确认端口没有被占用：

sudo ss -ltnp | grep ':8088'

如果没有输出，在 Debian 的 Nginx 配置目录中创建状态配置：

sudo tee /etc/nginx/conf.d/status.conf >/dev/null <<'EOF'
server {
    listen 127.0.0.1:8088;
    server_name 127.0.0.1;

    location = /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
        access_log off;
    }
}
EOF

检查并加载配置：

sudo nginx -t
sudo systemctl reload nginx

reload 会让 Nginx 平滑加载配置，通常不会中断已有连接；但只有 nginx -t 成功后才应执行。如果端口 8088 已被占用，应更换为未使用的本机端口，并同步修改后续检查命令。

2. 验证状态接口

curl -i http://127.0.0.1:8088/nginx_status

典型返回结构如下，数值仅用于说明字段含义：

Active connections: 12
server accepts handled requests
 1042 1042 3568
Reading: 0 Writing: 2 Waiting: 10

字段解释：

• Active connections：当前活动连接总数；
• accepts：接受过的连接数；
• handled：成功处理的连接数；
• requests：累计请求数；
• Reading：正在读取请求头的连接；
• Writing：正在向客户端发送响应的连接；
• Waiting：保持连接但暂时没有请求处理的连接。

stub_status 不能直接给出 HTTP 200、404 或 5xx 的数量，也不能证明后端应用健康。若需要判断上游错误，还应结合 Nginx access log 中的状态码、响应时间和 upstream 状态进行分析。

如果本机访问返回 403，通常是访问控制规则生效；返回 404，通常是配置未加载、请求路径不一致或实际加载的 Nginx 配置文件不是 /etc/nginx/conf.d/status.conf。可以使用以下命令确认完整配置：

sudo nginx -T | grep -A12 -B2 nginx_status

四、使用Node Exporter采集系统指标

如果只需要人工排查，前面的命令已经足够；如果需要持续记录、绘图和告警，可以在 Debian 主机安装 Node Exporter，并由独立的 Prometheus 服务采集。

1. 安装并验证采集器

在被监控的 Debian Nginx 主机上执行：

sudo apt update
sudo apt install -y prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter

检查服务和监听地址：

sudo systemctl status prometheus-node-exporter --no-pager
sudo ss -ltnp | grep ':9100'
curl -s http://127.0.0.1:9100/metrics | head

预期能看到类似以下指标名称：

node_cpu_seconds_total
node_memory_MemAvailable_bytes
node_filesystem_avail_bytes
node_disk_io_time_seconds_total

不同 Debian 软件包版本的默认监听地址可能不同。若 Prometheus 位于另一台服务器，应先查看实际启动参数：

sudo systemctl cat prometheus-node-exporter

不要将 9100 端口无条件暴露到公网。远程采集时，应只允许 Prometheus 所在的内网地址访问，并保留现有启动参数。修改 systemd 启动参数前，先保存 systemctl cat 的原始内容；修改后执行：

sudo systemctl daemon-reload
sudo systemctl restart prometheus-node-exporter
sudo systemctl status prometheus-node-exporter --no-pager

若重启失败，立即查看：

sudo journalctl -u prometheus-node-exporter -n 80 --no-pager

2. 配置Prometheus抓取目标

在 Prometheus 服务器的配置文件中增加目标。以下示例假设 Debian Nginx 主机内网地址为 10.0.0.20：

scrape_configs:
  - job_name: debian-nginx
    scrape_interval: 15s
    static_configs:
      - targets:
          - 10.0.0.20:9100
        labels:
          role: nginx
          environment: production

确认 Prometheus 服务器能够访问该地址：

curl http://10.0.0.20:9100/metrics

修改 Prometheus 配置后，先检查，再重载：

promtool check config /etc/prometheus/prometheus.yml
sudo systemctl reload prometheus

如果目标状态为 DOWN，按以下顺序排查：

1. Debian 主机上确认 Node Exporter 服务是否运行；
2. 确认 9100 是否只监听了 127.0.0.1；
3. 确认网络策略或防火墙是否允许 Prometheus 服务器访问；
4. 检查目标 IP、端口和 Prometheus 配置缩进；
5. 查看 Prometheus 的目标详情和错误信息。

五、配置Prometheus告警规则

在 Prometheus 服务器创建规则文件：

sudo install -d -m 0755 /etc/prometheus/rules
sudo tee /etc/prometheus/rules/debian-nginx.yml >/dev/null <<'EOF'
groups:
  - name: debian-nginx-resources
    interval: 30s
    rules:
      - alert: NodeExporterDown
        expr: up{job="debian-nginx"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Debian Nginx主机指标采集中断"
          description: "{{ $labels.instance }} 的Node Exporter已连续5分钟无法采集"

      - alert: CpuSaturationWarning
        expr: |
          100 - (avg by (instance) (
            rate(node_cpu_seconds_total{job="debian-nginx",mode="idle"}[5m])
          ) * 100) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU持续繁忙"
          description: "{{ $labels.instance }} CPU使用率超过85%，已持续10分钟"

      - alert: CpuSaturationCritical
        expr: |
          100 - (avg by (instance) (
            rate(node_cpu_seconds_total{job="debian-nginx",mode="idle"}[5m])
          ) * 100) > 95
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "CPU严重繁忙"
          description: "{{ $labels.instance }} CPU使用率超过95%，已持续5分钟"

      - alert: MemoryAvailableLow
        expr: |
          node_memory_MemAvailable_bytes{job="debian-nginx"}
          / node_memory_MemTotal_bytes{job="debian-nginx"} * 100 < 15
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "可用内存偏低"
          description: "{{ $labels.instance }} 可用内存低于15%"

      - alert: RootFilesystemLow
        expr: |
          node_filesystem_avail_bytes{job="debian-nginx",mountpoint="/"}
          / node_filesystem_size_bytes{job="debian-nginx",mountpoint="/"} * 100 < 15
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "根分区空间偏低"
          description: "{{ $labels.instance }} 根分区剩余空间低于15%"

      - alert: RootInodeLow
        expr: |
          node_filesystem_files_free{job="debian-nginx",mountpoint="/"}
          / node_filesystem_files{job="debian-nginx",mountpoint="/"} * 100 < 10
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "根分区inode偏低"
          description: "{{ $labels.instance }} 根分区剩余inode低于10%"

      - alert: FileDescriptorPressure
        expr: |
          node_filefd_allocated{job="debian-nginx"}
          / node_filefd_maximum{job="debian-nginx"} * 100 > 80
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "文件描述符使用率偏高"
          description: "{{ $labels.instance }} 文件描述符使用率超过80%"
EOF

将规则文件加入 Prometheus 主配置的 rule_files：

rule_files:
  - /etc/prometheus/rules/*.yml

检查规则语法并重新加载：

promtool check rules /etc/prometheus/rules/debian-nginx.yml
promtool check config /etc/prometheus/prometheus.yml
sudo systemctl reload prometheus

验证规则是否已经被加载：

curl -s http://127.0.0.1:9090/api/v1/rules | head

也可以在 Prometheus 查询页面分别执行以下表达式，确认有返回数据：

up{job="debian-nginx"}

node_memory_MemAvailable_bytes{job="debian-nginx"}

node_filesystem_avail_bytes{job="debian-nginx",mountpoint="/"}

六、设置告警通知与降噪

Prometheus 负责计算规则，Alertmanager 负责分组、抑制和发送通知。以下是邮件通知示例，邮箱服务器、账号和收件地址必须替换为实际值：

global:
  resolve_timeout: 5m
  smtp_smarthost: "smtp.example.com:587"
  smtp_from: "alert@example.com"
  smtp_auth_username: "alert@example.com"
  smtp_auth_password: "请替换为实际密码"

route:
  group_by:
    - alertname
    - instance
  group_wait: 30s
  group_interval: 10m
  repeat_interval: 4h
  receiver: "ops-email"

receivers:
  - name: "ops-email"
    email_configs:
      - to: "ops@example.com"
        send_resolved: true

inhibit_rules:
  - source_matchers:
      - severity="critical"
    target_matchers:
      - severity="warning"
    equal:
      - alertname
      - instance

降噪时应注意以下原则：

• 使用 for 过滤瞬时尖峰，例如 CPU 告警持续 5～10 分钟后再发送；
• 使用 group_wait 合并同一时间产生的多个告警；
• 使用 repeat_interval 避免同一个故障每分钟重复通知；
• 为预警和严重告警设置不同的 severity；
• 维护窗口内使用 Alertmanager 的静默功能，而不是临时删除规则；
• CPU、负载和 I/O 告警同时出现时，应优先处理具有更高严重级别的告警；
• NodeExporterDown 应视为监控链路故障，不等同于 Nginx 一定停止，仍需通过 systemctl status nginx 和端口检查确认。

Alertmanager 配置包含敏感凭据，保存后应限制权限：

sudo chmod 600 /etc/alertmanager/alertmanager.yml

七、常见故障处理

Nginx配置测试失败

sudo nginx -t
sudo nginx -T | less
sudo journalctl -u nginx -n 100 --no-pager

如果只是新增的 status.conf 引起错误，应先移走该文件，再测试原配置：

sudo mv /etc/nginx/conf.d/status.conf /etc/nginx/conf.d/status.conf.disabled
sudo nginx -t
sudo systemctl reload nginx

确认原服务恢复后，再修正端口、括号或指令拼写。

状态接口无法访问

先确认 Nginx 是否监听了本机端口：

sudo ss -ltnp | grep ':8088'
curl -v http://127.0.0.1:8088/nginx_status

• 没有监听：检查配置是否被 nginx.conf 的 include 加载；
• 返回 403：检查 allow 和 deny 规则；
• 返回 404：检查 URI 是否精确为 /nginx_status；
• Nginx reload 失败：回到 nginx -t 和日志检查，不要反复重启服务。

指标采集目标为DOWN

在 Debian 主机上执行：

sudo systemctl status prometheus-node-exporter --no-pager
sudo ss -ltnp | grep ':9100'
curl -s http://127.0.0.1:9100/metrics | head

如果本机能访问而 Prometheus 访问不到，通常是监听地址、网络访问控制或端口策略问题。若本机也无法访问，应查看服务日志：

sudo journalctl -u prometheus-node-exporter -n 100 --no-pager

告警过多

先检查告警是否由短时峰值触发，再调整 for 和 repeat_interval，不要直接删除规则。例如日志轮转造成短时磁盘 I/O 升高，可以把 I/O 告警持续时间从 5 分钟提高到 10 分钟；但根分区空间不足不应通过延长时间掩盖问题。

八、验收与回滚检查项

部署完成后，至少完成以下验收：

sudo nginx -t
sudo systemctl is-active nginx
curl -s http://127.0.0.1:8088/nginx_status
curl -s http://127.0.0.1:9100/metrics | grep -E 'node_cpu_seconds_total|node_memory_MemAvailable_bytes' | head
promtool check rules /etc/prometheus/rules/debian-nginx.yml

同时在 Prometheus 页面确认：

• up{job="debian-nginx"} == 1；
• CPU、内存、磁盘和 inode 查询有数据；
• 告警规则状态为 inactive 或符合当前测试条件；
• Alertmanager 能收到测试告警和恢复通知；
• 9100 和 8088 没有被意外暴露到公网。

如果需要回滚本次监控改动，可按以下顺序执行：

1. 在 Prometheus 配置中删除 debian-nginx 抓取目标和对应规则文件引用，然后执行 promtool check config；
2. 重载 Prometheus，确认旧目标和告警已消失；
3. 停止或禁用 Node Exporter：

sudo systemctl disable --now prometheus-node-exporter

1. 移除状态配置并恢复 Nginx：

sudo mv /etc/nginx/conf.d/status.conf /etc/nginx/conf.d/status.conf.disabled
sudo nginx -t
sudo systemctl reload nginx

1. 如果误改了原有 Nginx 配置，应从修改前的备份目录恢复对应文件，再次执行 nginx -t，确认测试成功后才重载服务。

这样回滚只移除监控相关配置，不会删除 Nginx 日志、站点文件或业务数据。