香港服务器监控告警体系怎么搭建？CPU、带宽与磁盘异常实时通知教程

香港服务器的监控告警体系，建议拆成“指标采集、规则判断、通知发送、故障复核”四层：在被监控服务器部署 Node Exporter，由 Prometheus 定时采集 CPU、网卡流量、网络错误、文件系统空间和 inode；再由 Alertmanager 按告警级别合并并发送邮件或企业内部 Webhook。实际部署时，先确认采集端可访问，再验证 Prometheus 目标状态，最后测试告警通知链路，避免把“通知服务故障”误判成“服务器没有异常”。

排查顺序应固定为：Exporter 是否存活 → 9100 端口是否可达 → Prometheus 目标是否为 UP → 告警规则是否加载 → Alertmanager 是否接收到告警 → 邮件或 Webhook 是否送达。CPU、带宽、磁盘告警分别需要持续时间和阈值，不能只根据一次瞬时峰值判断故障。

一、适用环境与准备条件

下面以以下环境为例：

• 被监控端：Ubuntu 22.04/24.04 或 Debian 12，使用 systemd。
• 监控端：一台能够访问香港服务器 9100/TCP 的 Linux 主机。
• 采集组件：Node Exporter。
• 规则与存储：Prometheus。
• 通知组件：Alertmanager。
• 通知方式：SMTP 邮件，或替换为企业内部能够接收 Alertmanager 请求的 Webhook。
• 监控间隔：15 秒。
• 示例配置：使用 Prometheus 和 Alertmanager 的容器运行，版本号仅作为可复现示例，不代表当前版本推荐或官方规格。

生产环境中，Prometheus 和 Alertmanager 不建议与被监控业务共用同一台服务器。若只有一台香港服务器，也可以先在同机验证流程，但需要知道：服务器宕机时，同机运行的监控服务也会同时中断，无法发送宕机通知。

准备以下信息：

1. 香港服务器的管理地址或可访问地址。
2. 监控端的固定 IP，后续只允许该地址访问 Node Exporter。
3. 香港服务器实际使用的网卡名称。
4. Prometheus 和 Alertmanager 配置文件的备份位置。
5. SMTP 服务器地址、端口、发件人、收件人及认证信息；如果使用 Webhook，则准备接收地址和认证方式。
6. 服务器当前防火墙规则和远程登录方式。

在香港服务器上先查看网卡、挂载点和当前资源状态：

ip -br link
df -hT
df -ih
nproc
ss -lntp

示例输出可能类似：

NAME      STATE    MAC
lo        UNKNOWN  ...
eth0      UP       ...

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/vda1      ext4   80G   42G   34G  56% /

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/vda1       5.1M  210K  4.9M    5% /

4

这里需要记录 eth0 或实际业务网卡名称。不要直接假设网卡一定叫 eth0，因为系统也可能使用 ens3、enp1s0 等命名。df -hT 用于确认文件系统类型和挂载点，df -ih 用于发现 inode 耗尽问题。

二、部署并验证 Node Exporter

1. 安装系统包

在 Ubuntu 或 Debian 被监控端执行：

sudo apt update
sudo apt install -y prometheus-node-exporter

确认服务名称和运行状态：

systemctl list-unit-files | grep -E 'node.*exporter|prometheus-node-exporter'
systemctl status prometheus-node-exporter --no-pager

如果服务名称不是 prometheus-node-exporter，以第一条命令实际列出的服务名为准，不要盲目执行固定的 systemctl 命令。

启动并设置开机启动：

sudo systemctl enable --now prometheus-node-exporter

本机验证指标接口：

curl --max-time 5 -fsS http://127.0.0.1:9100/metrics \
  | grep -E 'node_cpu_seconds_total|node_network_receive_bytes_total|node_filesystem_avail_bytes' \
  | head

正常情况下应看到类似以下指标名称：

node_cpu_seconds_total{cpu="0",mode="idle"} ...
node_network_receive_bytes_total{device="eth0"} ...
node_filesystem_avail_bytes{device="/dev/vda1",mountpoint="/",fstype="ext4"} ...

这些数值会持续变化，示例中的具体数值不代表某台服务器的实际运行数据。只要能返回指标名，说明 Node Exporter 已经可以采集基础 CPU、网络和磁盘数据。

2. 确认监听地址

查看 9100 的监听情况：

ss -lntp | grep ':9100'
systemctl cat prometheus-node-exporter

如果显示监听在 0.0.0.0:9100 或香港服务器的管理地址上，监控端可以访问。如果只监听 127.0.0.1:9100，Prometheus 在另一台机器上无法抓取。

修改监听地址前，先保存当前服务配置：

sudo systemctl cat prometheus-node-exporter \
  | sudo tee /root/prometheus-node-exporter.service.before-monitoring.txt >/dev/null

如果软件包使用默认二进制路径，可以创建 systemd 覆盖配置。将 替换为香港服务器实际管理地址；如果没有独立管理地址，再使用 0.0.0.0，但必须配合来源地址限制的防火墙规则。

sudo systemctl edit prometheus-node-exporter

写入：

[Service]
ExecStart=
ExecStart=/usr/bin/prometheus-node-exporter --web.listen-address=:9100

执行：

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

如果 command -v 返回的路径不是 /usr/bin/prometheus-node-exporter，应将覆盖配置中的路径替换为实际路径。覆盖 ExecStart 会替换软件包原有启动参数，修改前应结合 systemctl cat 检查是否存在其他必须保留的参数。

3. 限制 9100 访问来源

如果香港服务器使用 UFW，先查看现有规则：

sudo ufw status numbered

确认不会影响现有 SSH 或业务规则后，只允许监控端 IP 访问 9100/TCP：

sudo ufw allow from  to any port 9100 proto tcp

该命令会修改防火墙规则，执行前必须把 替换成监控端真实 IP，不要直接把 9100 对所有公网地址开放。如果服务器没有使用 UFW，应使用现有防火墙的等效规则，原则仍然是“仅允许监控端访问”。

从监控端验证：

curl --max-time 5 -fsS http://:9100/metrics \
  | grep -m 1 '^node_cpu_seconds_total'

结果含义如下：

三、配置 Prometheus 和 Alertmanager

1. 创建监控目录

在监控端创建目录：

sudo mkdir -p /opt/hk-monitoring
sudo chown -R "$USER":"$USER" /opt/hk-monitoring
cd /opt/hk-monitoring

创建 Prometheus 配置文件 prometheus.yml：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/rules.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - alertmanager:9093

scrape_configs:
  - job_name: hong-kong-server
    scrape_interval: 15s
    static_configs:
      - targets:
          - ":9100"
        labels:
          role: hong-kong-server

将 替换成真实地址。不要把尖括号保留在配置中。job_name 后面告警规则会使用同名标签，因此不要随意改名；如果修改了，需要同步修改规则中的 job="hong-kong-server"。

2. 编写 CPU、带宽和磁盘告警规则

创建 rules.yml：

groups:
  - name: hong-kong-server-health
    rules:
      - alert: HongKongExporterDown
        expr: up{job="hong-kong-server"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "香港服务器监控目标不可抓取"
          description: "Prometheus 连续 2 分钟无法抓取 {{ $labels.instance }} 的 Node Exporter。"

      - alert: HongKongCPUHigh
        expr: 100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{job="hong-kong-server",mode="idle"}[5m]))) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器 CPU 持续偏高"
          description: "{{ $labels.instance }} CPU 使用率在 5 分钟窗口内持续高于 85%，已超过 10 分钟。"

      - alert: HongKongCPUCritical
        expr: 100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{job="hong-kong-server",mode="idle"}[5m]))) > 95
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "香港服务器 CPU 接近饱和"
          description: "{{ $labels.instance }} CPU 使用率在 5 分钟窗口内持续高于 95%。"

      - alert: HongKongCPUStolen
        expr: 100 * avg by (instance) (rate(node_cpu_seconds_total{job="hong-kong-server",mode="steal"}[5m])) > 10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器存在较高 CPU steal"
          description: "{{ $labels.instance }} 的 CPU steal 时间持续高于 10%，需要结合业务负载判断。"

      - alert: HongKongNetworkReceiveHigh
        expr: sum by (instance, device) (rate(node_network_receive_bytes_total{job="hong-kong-server",device!="lo",device!~"docker.*|veth.*|br-.*"}[5m])) > 10000000
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器入站带宽持续偏高"
          description: "{{ $labels.instance }} 网卡 {{ $labels.device }} 入站速率持续高于示例阈值 10,000,000 bytes/s。"

      - alert: HongKongNetworkSendHigh
        expr: sum by (instance, device) (rate(node_network_transmit_bytes_total{job="hong-kong-server",device!="lo",device!~"docker.*|veth.*|br-.*"}[5m])) > 10000000
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器出站带宽持续偏高"
          description: "{{ $labels.instance }} 网卡 {{ $labels.device }} 出站速率持续高于示例阈值 10,000,000 bytes/s。"

      - alert: HongKongNetworkErrors
        expr: sum by (instance, device) (rate(node_network_receive_errs_total{job="hong-kong-server",device!="lo"}[5m]) + rate(node_network_transmit_errs_total{job="hong-kong-server",device!="lo"}[5m])) > 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器网卡错误持续增加"
          description: "{{ $labels.instance }} 网卡 {{ $labels.device }} 的收发错误率持续高于 0.1 次/秒。"

      - alert: HongKongFilesystemLow
        expr: 100 * node_filesystem_avail_bytes{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"} / node_filesystem_size_bytes{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"} < 15
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器文件系统可用空间不足"
          description: "{{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} 可用空间低于 15%。"

      - alert: HongKongFilesystemCritical
        expr: 100 * node_filesystem_avail_bytes{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"} / node_filesystem_size_bytes{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"} < 8
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "香港服务器文件系统空间严重不足"
          description: "{{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} 可用空间低于 8%。"

      - alert: HongKongFilesystemInodesLow
        expr: 100 * node_filesystem_files_free{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"} / node_filesystem_files{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"} < 10
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器 inode 余量不足"
          description: "{{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} inode 可用比例低于 10%。"

      - alert: HongKongFilesystemReadonly
        expr: node_filesystem_readonly{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*"} == 1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "香港服务器文件系统变为只读"
          description: "{{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} 被检测为只读。"

      - alert: HongKongDiskFillingSoon
        expr: predict_linear(node_filesystem_avail_bytes{job="hong-kong-server",fstype!~"tmpfs|overlay|squashfs|proc|sysfs|devtmpfs|cgroup.*",mountpoint!~"/(proc|sys|dev|run)(/.*)?$"}[6h], 24 * 60 * 60) < 0
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "香港服务器磁盘可能在 24 小时内耗尽"
          description: "{{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} 按近 6 小时趋势估算，可能在未来 24 小时内用尽空间。"

这组规则中的带宽阈值是示例值，不是香港服务器的线路规格或服务承诺。10,000,000 bytes/s 按十进制换算为：

• 10,000,000 bytes/s × 8 = 80,000,000 bits/s。
• 80,000,000 bits/s ÷ 1,000,000 = 80 Mbps。
• 因此该示例相当于持续约 80 Mbps。

如果实际带宽上限按 100 Mbps 计算，可以把 80% 的示例阈值设置为 80 Mbps，也就是 10,000,000 bytes/s。如果目标是 1 Gbps，则 80% 对应 800 Mbps，即 100,000,000 bytes/s。换算时要区分 MB、Mb 和 Mbps，不能把 10 MB/s 直接写成 10 Mbps。

3. 配置通知方式

创建 alertmanager.yml。下面以 SMTP 邮件为主，Webhook 为可选项：

global:
  resolve_timeout: 5m
  smtp_smarthost: "smtp.example.com:587"
  smtp_from: "monitor@example.com"
  smtp_auth_username: "monitor@example.com"
  smtp_auth_password: "REPLACE_WITH_SMTP_PASSWORD"
  smtp_require_tls: true

route:
  group_by:
    - alertname
    - instance
    - device
    - mountpoint
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  receiver: hong-kong-ops

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

    # 如果使用内部 Webhook，替换为真实地址后取消注释。
    # webhook_configs:
    #   - url: "https://notify.example.com/alertmanager"
    #     send_resolved: true

必须替换以下内容：

• smtp.example.com:587：实际 SMTP 地址和端口。
• monitor@example.com：发件账号及发件地址。
• REPLACE_WITH_SMTP_PASSWORD：SMTP 密码或专用授权凭据。
• ops@example.com：告警接收邮箱。
• Webhook 地址：必须是实际能够接收 Alertmanager 请求的内部接口。

SMTP 密码属于敏感信息，设置文件权限：

chmod 600 alertmanager.yml

group_wait: 30s 表示首次告警一般会等待约 30 秒，用于合并同一时间产生的相关告警；group_interval: 5m 用于限制同一组告警的更新频率；repeat_interval: 2h 用于防止故障未恢复时每隔十几秒重复发送。

4. 创建 Compose 文件

创建 compose.yaml：

services:
  prometheus:
    image: prom/prometheus:v2.53.0
    container_name: hk-prometheus
    restart: unless-stopped
    ports:
      - "127.0.0.1:9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./rules.yml:/etc/prometheus/rules.yml:ro
      - prometheus_/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--web.enable-lifecycle"
    depends_on:
      - alertmanager

  alertmanager:
    image: prom/alertmanager:v0.27.0
    container_name: hk-alertmanager
    restart: unless-stopped
    ports:
      - "127.0.0.1:9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
      - alertmanager_/alertmanager
    command:
      - "--config.file=/etc/alertmanager/alertmanager.yml"
      - "--storage.path=/alertmanager"
      - "--web.enable-lifecycle"

volumes:
  prometheus_
  alertmanager_

示例中的容器版本是固定示例。若内部已有经过验证的镜像版本，可以替换镜像标签，但应先在测试环境验证配置语法和组件兼容性。Prometheus 和 Alertmanager 仅绑定到监控端的 127.0.0.1，不会直接暴露到公网。

四、启动前验证配置

启动前先检查文件：

cd /opt/hk-monitoring
docker compose config

如果配置正确，会输出合并后的 Compose 配置；如果出现 YAML 缩进错误、文件路径错误或字段错误，应先修复，不要直接启动。

检查 Prometheus 配置和规则：

docker compose run --rm prometheus \
  promtool check config /etc/prometheus/prometheus.yml

docker compose run --rm prometheus \
  promtool check rules /etc/prometheus/rules.yml

检查 Alertmanager 配置：

docker compose run --rm alertmanager \
  amtool check-config /etc/alertmanager/alertmanager.yml

常见错误包括：

• yaml: unmarshal errors：缩进、冒号或字段格式错误。
• file not found：Compose 挂载路径或文件名不一致。
• unknown field：使用了当前镜像不支持的字段。
• 规则检查失败：PromQL 表达式括号、标签选择器或指标名称错误。
• SMTP 配置检查通过但无法发信：配置语法正常，不代表账号、TLS、DNS 或出口连接正常。

验证通过后启动：

docker compose up -d
docker compose ps

查看日志：

docker compose logs --tail=100 prometheus
docker compose logs --tail=100 alertmanager

五、逐层验证采集、规则和通知

1. 验证 Prometheus 是否就绪

在监控端执行：

curl --max-time 5 -fsS http://127.0.0.1:9090/-/ready

预期结果：

Prometheus is Ready.

检查 Alertmanager：

curl --max-time 5 -fsS http://127.0.0.1:9093/-/ready

预期结果：

Alertmanager is Ready.

如果 Prometheus 未就绪，先处理 Prometheus 日志；如果 Prometheus 正常但 Alertmanager 未就绪，则 Prometheus 的规则可以评估，但无法完成告警发送。

2. 验证目标是否为 UP

打开监控端的 Prometheus 页面：

http://127.0.0.1:9090/targets

在 hong-kong-server 目标中应看到：

State: UP
Last Scrape: a few seconds ago

也可以直接查询目标状态：

curl --max-time 5 -fsS http://127.0.0.1:9090/api/v1/targets

判断重点：

• health: "up"：Prometheus 已成功抓取。
• health: "down"：查看返回的 lastError。
• lastError 中出现 connection refused：Node Exporter 未监听或监听地址不对。
• lastError 中出现 context deadline exceeded：网络、防火墙或服务器响应异常。
• 目标没有出现在列表：检查 prometheus.yml 是否加载成功，或者 job_name、目标地址是否写错。

3. 验证核心查询结果

在 Prometheus 查询页面分别执行：

up{job="hong-kong-server"}

100 * (1 - avg by (instance) (rate(node_cpu_seconds_total{job="hong-kong-server",mode="idle"}[5m])))

sum by (instance, device) (rate(node_network_receive_bytes_total{job="hong-kong-server",device!="lo"}[5m]))

100 * node_filesystem_avail_bytes{job="hong-kong-server"} / node_filesystem_size_bytes{job="hong-kong-server"}

预期结果分别是：

• up 返回 1。
• CPU 查询返回当前 CPU 使用率百分比。
• 网络查询返回每秒字节数。
• 磁盘查询返回文件系统可用空间百分比。

如果 CPU 查询没有数据，优先检查 node_cpu_seconds_total 是否存在；如果磁盘查询出现多个挂载点，属于正常现象，应结合 mountpoint 标签判断具体目录。

4. 验证规则是否已经加载

执行：

curl --max-time 5 -fsS http://127.0.0.1:9090/api/v1/rules

或者打开：

http://127.0.0.1:9090/rules

应能看到 HongKongCPUHigh、HongKongNetworkReceiveHigh、HongKongFilesystemLow 等规则。

修改 rules.yml 或 prometheus.yml 后，通过生命周期接口重新加载：

curl --max-time 5 -fsS -X POST http://127.0.0.1:9090/-/reload

如果返回错误，查看日志：

docker compose logs --tail=100 prometheus

生命周期接口只绑定在 127.0.0.1，仍应避免把 Prometheus 的管理端口暴露到公网。

5. 不制造高负载，直接测试通知链路

可以向本机 Alertmanager 注入一条短时测试告警，不需要人为占满 CPU 或制造大量网络流量。

START=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
END=$(date -u -d "+2 minutes" +"%Y-%m-%dT%H:%M:%SZ")

curl --max-time 10 -fsS \
  -H 'Content-Type: application/json' \
  -X POST \
  http://127.0.0.1:9093/api/v2/alerts \
  -d "[{
    \"labels\": {
      \"alertname\": \"HongKongNotificationTest\",
      \"severity\": \"warning\",
      \"instance\": \"notification-test\"
    },
    \"annotations\": {
      \"summary\": \"香港服务器告警通知测试\",
      \"description\": \"这是一条两分钟后自动结束的通知链路测试告警。\"
    },
    \"startsAt\": \"$START\",
    \"endsAt\": \"$END\"
  }]"

随后检查：

docker compose logs --tail=100 alertmanager

应依次确认：

1. Alertmanager 接收到测试告警。
2. 等待约 30 秒后触发路由。
3. 邮箱收到测试通知，或 Webhook 返回成功。
4. 两分钟后收到恢复通知，前提是 send_resolved: true 且通知渠道支持恢复消息。

这条测试告警只验证 Alertmanager 到通知渠道的链路，不能证明香港服务器的 CPU、带宽和磁盘规则一定会触发。

六、阈值、告警降噪与故障前兆判断

CPU：看持续使用率，也要看 steal

CPU 告警使用 5 分钟平均值，而不是单次采样值。合理的初始参考如下：

CPU 高并不一定意味着服务器故障。先执行：

top -H
ps -eo pid,ppid,comm,%cpu,%mem --sort=-%cpu | head -n 15

检查结果：

• 某个进程长期占用一个或多个核心：优先定位该进程对应的业务任务。
• CPU 使用率高但业务响应正常：可能是正常计算任务，应结合历史基线调整阈值。
• steal 长期偏高而业务进程并不繁忙：需要把重点放到虚拟 CPU 调度等待，而不是盲目重启业务。
• 告警只出现几十秒：通常应由 for 条件过滤，不应立即升级为故障。

带宽：区分持续吞吐、错误和接口选择

node_network_receive_bytes_total 是服务器收到的字节数，node_network_transmit_bytes_total 是服务器发出的字节数。通过 rate(...[5m]) 得到每秒平均字节数。

固定阈值适合发现“持续接近上限”的问题，但不适合直接代表所有异常。建议同时观察：

ip -s link show dev <实际网卡名>

重点检查：

• RX 或 TX 是否持续接近设定阈值。
• errors、dropped 是否同步增加。
• 告警是否出现在真实业务网卡，而不是 lo、veth、容器桥接网卡。
• 多网卡环境下是否需要分别设置阈值。

如果服务器带宽并未接近上限，却出现流量告警，常见原因是把虚拟网卡纳入了统计，或者多个接口被求和。应先根据 ip -br link 和 Prometheus 中的 device 标签修正过滤条件。

磁盘：空间、inode、只读和增长趋势要分开看

磁盘异常至少包括四种情况：

1. 可用容量低：日志、缓存或业务数据可能继续增长。
2. inode 低：大量小文件可能导致即使还有容量也无法创建新文件。
3. 文件系统只读：写入会失败，常见表现比“空间不足”更紧急。
4. 增长速度过快：当前空间尚未耗尽，但可能在未来一段时间内耗尽。

执行以下检查：

df -hT
df -ih
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

如果确认某个目录快速增长，可在确认影响范围后执行：

sudo du -xhd1 /var 2>/dev/null | sort -h

该命令可能需要较长时间，并会遍历目录，不建议在磁盘 I/O 已经很高时反复执行。不要直接删除日志或业务文件，先确认文件用途、保留周期和恢复方式。

如果 df 显示空间已使用，但 du 汇总明显偏小，可以检查已删除但仍被进程占用的文件：

sudo lsof +L1

发现只读告警时，先查看内核和挂载信息：

dmesg -T | tail -n 100
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

不要直接执行卸载、强制修复或删除文件操作。文件系统修复通常需要业务停机、快照或备份，并且必须结合具体文件系统和维护窗口处理。

七、常见失败分支与处理顺序

Prometheus 显示目标 DOWN

按低风险到高风险顺序检查：

curl --max-time 5 http://:9100/metrics

sudo systemctl status prometheus-node-exporter --no-pager

ss -lntp | grep ':9100'

如果香港服务器本机能够访问，而监控端不能访问，说明问题主要在监听地址、防火墙或网络路径；如果本机也不能访问，则先修复 Node Exporter 服务。

有 CPU 告警，但进程 CPU 不高

先检查告警查询的时间窗口是否仍然满足，再查看：

100 * avg by (instance) (rate(node_cpu_seconds_total{job="hong-kong-server",mode="steal"}[5m]))

如果 steal 高，CPU 告警可能来自调度等待；如果 steal 低而业务进程也不高，检查是否存在多个 Prometheus 目标使用相同 instance 标签、时间序列标签异常或规则筛选范围过大。

带宽告警频繁出现和恢复

先确认网卡过滤条件，再把 for 从 10 分钟调整到更符合业务的持续时间。不要只把阈值无限提高，否则可能掩盖真实拥塞。对于正常的定时任务，可以单独设置更长的持续时间，或按照实际业务高峰设置分时阈值。

磁盘告警一直不恢复

确认空间是否真的恢复：

df -hT
df -ih

如果已经删除大文件但空间没有释放，检查：

sudo lsof +L1

进程仍然打开已删除文件时，空间通常要等进程关闭文件描述符后才释放。此时应优先采用业务支持的重载或重启方式，并先确认影响范围和回滚办法，不要直接结束未知进程。

告警规则存在，但邮箱没有收到通知

检查以下内容：

docker compose logs --tail=200 alertmanager

重点关注：

• SMTP 主机和端口是否正确。
• DNS 是否能解析 SMTP 主机。
• TLS 证书验证是否失败。
• 发件账号是否允许当前认证方式。
• 发件人和收件人是否被邮件系统拒收。
• Alertmanager 是否因为 group_wait 仍在等待。
• 测试告警是否使用了预期的 severity 和标签。

如果 Prometheus 页面显示告警处于 FIRING，但 Alertmanager 没有对应记录，检查 Prometheus 的 alerting.alertmanagers 地址；如果 Alertmanager 有记录但邮件失败，则重点处理 SMTP 配置和出口连接。

告警数量过多

先不要删除规则，按以下方式降噪：

• 给瞬时波动增加 for 持续时间。
• 使用 group_by 合并同一服务器、同一网卡或同一挂载点的告警。
• 将 warning 和 critical 分开处理。
• 排除 lo、容器虚拟网卡、临时文件系统等无关对象。
• 保留 ExporterDown 和文件系统只读告警等高优先级告警。
• 对磁盘趋势预测设置较长观察窗口，避免一次性文件生成造成误报。

八、修改后的结果检查

完成部署后，至少保留以下验收记录：

• Node Exporter 服务处于 active (running)。
• 监控端访问 9100/metrics 成功。
• Prometheus /targets 页面中香港服务器为 UP。
• Prometheus 能查询到 CPU、网卡和文件系统指标。
• CPU、带宽和磁盘规则均显示为 Loaded。
• Alertmanager /api/v2/status 可以返回状态。
• 测试告警能够发送到邮件或 Webhook。
• 测试告警结束后能够收到恢复通知。
• 9100 端口只允许监控端访问。
• Prometheus 和 Alertmanager 管理端口没有直接暴露到公网。
• alertmanager.yml 权限不会让普通用户读取 SMTP 密码。
• 已记录实际网卡名、挂载点、带宽阈值和阈值调整依据。

可以使用以下命令做一次最终状态检查：

systemctl is-active prometheus-node-exporter

curl --max-time 5 -fsS http://:9100/metrics >/dev/null \
  && echo "exporter reachable"

curl --max-time 5 -fsS http://127.0.0.1:9090/-/ready

curl --max-time 5 -fsS http://127.0.0.1:9093/-/ready

docker compose ps

告警延迟应按链路计算，而不是把 15 秒采集间隔理解成即时通知。例如 CPU 告警设置 for: 10m，Prometheus 每 15 秒评估一次，Alertmanager 再等待 30 秒分组，因此首次通知通常约为 10 分钟加几十秒。这样可以过滤短时尖峰，但无法做到零延迟。

九、配置回滚与安全收尾

回滚 Node Exporter 监听配置

修改 systemd 覆盖配置前已经保存原始服务定义。回滚时先查看覆盖文件：

sudo systemctl cat prometheus-node-exporter

如果覆盖文件位于 /etc/systemd/system/prometheus-node-exporter.service.d/override.conf，可以先移动而不是直接删除：

sudo mv \
  /etc/systemd/system/prometheus-node-exporter.service.d/override.conf \
  /etc/systemd/system/prometheus-node-exporter.service.d/override.conf.disabled

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

确认服务恢复后，再决定是否清理备份文件。该操作会改变监听地址，回滚后监控端可能重新无法访问 9100，需要同步检查防火墙。

回滚防火墙规则

只删除本次新增的精确规则，不要使用清空全部规则的命令：

sudo ufw status numbered
sudo ufw delete allow from  to any port 9100 proto tcp

执行前确认 与新增规则完全一致，避免误删其他服务规则。

回滚 Prometheus 和 Alertmanager 配置

修改前先备份：

cd /opt/hk-monitoring

cp -a prometheus.yml "prometheus.yml.$(date +%Y%m%d%H%M%S).bak"
cp -a rules.yml "rules.yml.$(date +%Y%m%d%H%M%S).bak"
cp -a alertmanager.yml "alertmanager.yml.$(date +%Y%m%d%H%M%S).bak"

如果新配置导致加载失败，恢复对应备份文件后重新检查：

docker compose run --rm prometheus \
  promtool check config /etc/prometheus/prometheus.yml

docker compose run --rm prometheus \
  promtool check rules /etc/prometheus/rules.yml

docker compose run --rm alertmanager \
  amtool check-config /etc/alertmanager/alertmanager.yml

确认无误后重新加载：

curl --max-time 5 -fsS -X POST http://127.0.0.1:9090/-/reload
curl --max-time 5 -fsS -X POST http://127.0.0.1:9093/-/reload

如果需要停止监控容器，可以执行：

docker compose down

该命令不会删除命名卷中的历史数据。不要随意执行 docker compose down -v，因为它会删除 Prometheus 和 Alertmanager 的命名卷，可能导致历史监控数据和通知状态丢失；只有在已经完成数据备份并明确需要清空监控数据时，才应考虑删除卷。