监控不是一块好看的大屏，而是“发现异常、通知到人、保留证据、确认恢复”的闭环。至少从另一台机器或托管探针检查真实业务路径，再用主机指标解释原因；监控系统本身也需要外部心跳、配置备份和定期通知演练。

👀 为什么需要监控？

🚨

故障秒级感知

网站打不开？数据库挂了？监控系统能在 1 分钟内通过 Telegram 发警报到您手机——比用户投诉早几小时。 📈

容量与性能预警

硬盘用了 90%？内存持续爆满？提前发现瓶颈，在系统彻底卡死前进行清理或扩容。 📊

SLA 历史复盘

记录 VPS 真实在线率（Uptime）。服务商频繁断网？有数据截图才能申请退款或换机。

⚖️ 主流监控方案对比

监控至少包含两层：从故障域之外验证 DNS、TLS、HTTP 内容和真实操作是否可用，以及在服务器内部采集资源与应用指标解释原因。两层应分开部署并互相补充。 工具 类型 内存占用 核心优势 适合场景 Uptime Kuma 外部可用性监控 按实例实测

• HTTP/TCP/DNS/关键字检测

• 支持状态页与通知

• 可监控定时任务心跳

  网站/API/证书与任务心跳 哪吒探针 (Nezha) 服务器集群监控 ~30MB

• 多台 VPS 同屏展示资源

• 内置 WebSSH 和文件管理

• 支持流量/CPU/内存/硬盘全指标

  拥有多台 VPS 的玩家 Prometheus + Grafana 企业级时序监控 ~500MB+

• 图表最丰富，数据精度最高

• 告警规则极其灵活

• 开源生态最完整（Node Exporter 等）

  企业生产环境/大型系统 Shell 脚本 + Cron 本机补充检查 接近零常驻

• 逻辑可审阅

• 适合特定业务检查

• 可接入现有通知

  低配 VPS 的补充与应急

💡 最小可用搭配： 把 Uptime Kuma 或托管探针放在不同故障域，检查 HTTPS 状态、响应内容、证书和关键任务心跳；业务机安装哪吒 Agent 或 Node Exporter 查看资源指标。状态页可以与内部管理面分开，避免公开敏感主机信息。

🟢 实战：Uptime Kuma 部署与配置

Uptime Kuma 被誉为”自托管版 UptimeRobot”，UI 极具现代感，支持 HTTP/TCP/DNS/关键字等多种检测方式，可以生成公开的状态页面（如 status.yourdomain.com）供用户查看服务状态。

Docker Compose 部署

  /opt/uptime-kuma/docker-compose.yml  

# 文件路径：/opt/uptime-kuma/docker-compose.yml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:${KUMA_VERSION} # .env 固定已复核版本，如 2.3.2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"     # 只绑定本地，配合 Nginx 反代
    volumes:
      - ./kuma-data:/app/data      # 必须使用本地文件系统，不使用 NFS
    environment:
      - TZ=Asia/Shanghai           # 时区设置，确保日志时间正确

Nginx 反代配置（开启 HTTPS + WebSocket）

  /etc/nginx/conf.d/status.conf  

# 文件路径：/etc/nginx/conf.d/status.conf
# 将 Uptime Kuma 暴露为 status.yourdomain.com

server {
    listen 443 ssl;
    http2 on;
    server_name status.yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/status.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.yourdomain.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3001;
        proxy_http_version 1.1;
        # WebSocket 支持（Uptime Kuma 实时推送依赖 WS）
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 86400;   # 长连接超时
    }
}

server {
    listen 80;
    server_name status.yourdomain.com;
    return 301 https://$host$request_uri;
}

⚙️ 登录后首要配置步骤

• 访问 https://status.yourdomain.com，首次访问创建管理员账号
• 点击”添加新的监控”→ 类型选 HTTP(s)，填入您的网站 URL
• 设置检测间隔（建议 60 秒），连续失败次数（建议 3 次才告警，避免误报）
• 在”设置 → 通知”中配置 Telegram 告警（见本文第6章）
• 在”状态页”中创建公开页面，分享给用户查看实时状态

👦 实战：哪吒探针多机监控

当您的 VPS 超过 3 台时就需要哪吒探针了。它分为面板端（Panel）（一台机器，负责展示和管理）和探针端（Agent）（每台被监控的机器，负责采集数据上报）。

面板端部署

  哪吒面板端安装  

# ── 面板端部署（选择一台专用机器作为控制中心）──────────────────────────────
# 前提：在 GitHub 创建 OAuth App（Settings → Developer settings → OAuth Apps）
# Homepage URL: https://nezha.yourdomain.com
# Callback URL: https://nezha.yourdomain.com/oauth2/callback

# 一键安装脚本
curl -L https://raw.githubusercontent.com/naiba/nezha/master/script/install.sh   -o nezha.sh && chmod +x nezha.sh && sudo ./nezha.sh
# 选择 [1] 安装面板端，按提示输入：
# - GitHub OAuth Client ID 和 Client Secret
# - 管理员 GitHub 用户名

# 安装完成后面板访问：https://nezha.yourdomain.com
# 默认不需要密码，用 GitHub 账号登录即是管理员

被控端 Agent 部署

  每台被监控服务器执行  

# ── 被控端 Agent 部署（在每台需要被监控的服务器上执行）──────────────────
# 在哪吒面板后台：服务器 → 添加服务器，系统会生成一条安装命令，如：

curl -L https://raw.githubusercontent.com/naiba/nezha/master/script/install.sh   -o nezha.sh && chmod +x nezha.sh && sudo ./nezha.sh
# 选择 [8] 安装 Agent
# 输入面板域名：nezha.yourdomain.com
# 输入 Agent 密钥：面板后台生成的密钥（每台机器独立）

# Agent 安装后会自动注册，在面板上实时显示：
# CPU 占用率、内存使用、磁盘剩余、网络流入/流出、进程数等

⚠️ 架构建议： 面板端机器最好专用，不要跑高负载应用——如果面板机器挂了，所有被控端的状态都看不到了。可以选一台低配但稳定的 VPS（如 $3/月 的小鸡）专门跑哪吒面板。

🌸 实战：Komari 探针轻量部署

Komari 是近年来备受关注的新一代服务器监控探针，由国人开发，界面简洁美观，部署极其简单。相比哪吒探针，Komari 的 Agent 更轻量，面板端无需 GitHub OAuth 认证，配置门槛更低，非常适合只想快速上手的用户。

哪吒探针

• 功能最完整（WebSSH/文件管理/任务）
• 社区最活跃，文档丰富
• 需要 GitHub OAuth 登录认证

Komari ⭐

• 界面更简洁现代，颜值更高
• 部署更简单，账密直接登录
• 轻量省资源，响应速度快

面板端 Docker Compose 部署

  /opt/komari/docker-compose.yml  

# 文件路径：/opt/komari/docker-compose.yml

services:
  komari:
    image: ghcr.io/komari-monitor/komari:latest
    container_name: komari
    restart: unless-stopped
    ports:
      - "25565:25565"   # 只绑定本地，配合 Nginx 反代
    volumes:
      - ./data:/app/data           # 数据持久化（配置、节点信息）
    environment:
      - TZ=Asia/Shanghai

# 启动：docker compose up -d
# 首次访问 http://服务器IP:25565 创建管理员账号（直接账密登录，无需 OAuth）

被控端 Agent 安装（每台被监控的服务器执行）

  Komari Agent 安装  

# 在 Komari 面板后台：节点管理 → 添加节点，复制生成的安装命令
# 命令格式类似：
curl -fsSL https://raw.githubusercontent.com/komari-monitor/komari-agent/main/install.sh \
  | bash -s -- --server https://komari.yourdomain.com --token 你的节点Token

# Agent 会自动注册为系统服务（systemd），开机自启
# 安装成功后几秒内即可在面板上看到该节点的实时指标

💡 Komari 与哪吒可以共存： 两者的 Agent 互不冲突，可以同时安装在同一台服务器上。哪吒用于日常运维（WebSSH 远程登录很方便），Komari 用于对外展示美观的公开状态页。

📊 进阶：Prometheus + Grafana 企业级监控

如果您需要更精细的时序数据（如每秒 CPU 波动、HTTP 请求延迟分布），Prometheus + Grafana 是业界标准方案。代价是资源占用较高（约 500MB 内存），适合 2GB+ 内存的服务器。

docker-compose.yml（三服务全栈）

  /opt/monitoring/docker-compose.yml  

# 文件路径：/opt/monitoring/docker-compose.yml
# 完整监控栈：Prometheus + Grafana + Node Exporter

services:

  # ── Prometheus：时序数据收集与存储 ──────────────────────────────────────────
  prometheus:
    image: prom/prometheus:${PROMETHEUS_VERSION}
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "127.0.0.1:9090:9090"      # 不向公网暴露管理与查询接口
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml  # 配置文件
      - ./alert.rules.yml:/etc/prometheus/alert.rules.yml # 告警规则
      - prometheus_data:/prometheus                       # 数据持久化
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.retention.time=15d                 # 保留 15 天数据

  # ── Node Exporter：采集宿主机系统指标 ────────────────────────────────────────
  node-exporter:
    image: prom/node-exporter:${NODE_EXPORTER_VERSION}
    container_name: node-exporter
    restart: unless-stopped
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - --path.procfs=/host/proc
      - --path.sysfs=/host/sys

  # ── Grafana：数据可视化仪表盘 ────────────────────────────────────────────────
  grafana:
    image: grafana/grafana:${GRAFANA_VERSION}
    container_name: grafana
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}  # .env 权限设为 600
      - GF_USERS_ALLOW_SIGN_UP=false                     # 禁止公开注册

volumes:
  prometheus_data:
  grafana_data:

prometheus.yml 抓取配置

  /opt/monitoring/prometheus.yml  

# 文件路径：/opt/monitoring/prometheus.yml
# Prometheus 抓取配置

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

global:
  scrape_interval: 15s      # 每 15 秒抓取一次指标
  evaluation_interval: 15s

scrape_configs:
  # 采集 Prometheus 自身指标
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # 采集宿主机系统指标（通过 Node Exporter）
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100'] # Compose 网络内使用服务名

  # 如需监控其他服务器，添加更多 targets：
  # - job_name: 'remote-server'
  #   static_configs:
  #     - targets: ['服务器IP:9100']

把“持续异常”和“暂时没数据”分开

只写 expr: up == 0 会在单次抓取失败时立刻进入 pending；生产环境通常还要设置 for，让异常持续一段时间后再通知。Prometheus 官方当前也支持 keep_firing_for：条件刚恢复或短暂丢失时，告警可以继续保持一小段时间，减少抖动造成的反复恢复/触发。它不是“证明服务已经恢复”的证据，恢复仍要结合外部探测、应用日志和最近部署记录。 /opt/monitoring/alert.rules.yml

# 文件路径：/opt/monitoring/alert.rules.yml
# 在 prometheus.yml 中加入 rule_files: ["/etc/prometheus/alert.rules.yml"]
# 先 pending 一段时间，再决定是否通知；避免瞬时抖动制造告警风暴
groups:
  - name: vps-basics
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 5m
        keep_firing_for: 5m
        labels:
          severity: page
        annotations:
          summary: "实例 {{ $labels.instance }} 无法抓取"
          description: "Prometheus 连续 5 分钟抓取失败；先区分主机宕机、网络隔离和 exporter 故障。"

      - alert: DiskAlmostFull
        expr: (node_filesystem_avail_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes{fstype!="tmpfs"})   

⚠️ **三个容易误判的边界：**（1）`up == 0` 表示 Prometheus 没抓到目标，不等于整台 VPS 已宕机；（2）指标暂时消失可能是标签变化、服务重启或抓取配置错误，不应直接当作恢复；（3）Prometheus 负责判断规则，通知分组、限流、静默和依赖关系应交给 Alertmanager。先在 Prometheus Targets / Alerts 页面核对原始状态，再处理通知。

  
### 官方文档与版本边界
 
 - [Prometheus Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)：核对 `for`、`keep_firing_for`、标签和 annotation 的当前语义。
 - [Prometheus Alerting overview](https://prometheus.io/docs/alerting/latest/overview/)：理解 Prometheus 规则判断与 Alertmanager 通知编排的分工。
 - [Prometheus configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)：确认 `rule_files`、抓取目标和 Alertmanager 配置是否与当前版本一致。
 
 
本文示例只适合单机或小规模 VPS 起步。Prometheus、Node Exporter、Grafana 和 Alertmanager 的镜像版本、存储保留期、权限及资源占用应在部署前按官方文档和实际负载复核；不要把示例中的阈值当成所有业务的 SLA。
  

💡 **Grafana 仪表盘快速导入：** 登录 Grafana（默认 admin / 您设置的密码）→ Dashboards → Import → 输入 Dashboard ID `1860`（Node Exporter Full）→ 选择 Prometheus 数据源 → 导入。这是社区最流行的 Linux 系统监控仪表盘，覆盖 CPU/内存/磁盘/网络全部指标，开箱即用。

   
##  📱 进阶：多渠道告警通知配置

 
监控的目的是及时通知。相比邮件，即时通讯工具推送速度更快、到达率更高。以下是最常用的告警渠道：
 
### Telegram 机器人（个人最推荐）
      Telegram Bot 创建与测试  

── 通过 BotFather 创建 Telegram 机器人 ─────────────────────────────────────

1. 在 Telegram 搜索 @BotFather，发送 /newbot

2. 输入机器人名称（如 MyVPS Monitor Bot）

3. 输入机器人用户名（必须以 bot 结尾，如 myvps_monitor_bot）

4. BotFather 返回 HTTP API Token（格式：1234567890:ABCdef…）

── 获取 Chat ID ──────────────────────────────────────────────────────────────

方法一：搜索 @userinfobot，发送任意消息，它会回复您的 User ID

方法二：将机器人加入群组，发送消息后访问：

https://api.telegram.org/bot/getUpdates

在返回的 JSON 中找到 “chat”:{“id”: 你的Chat_ID}

── 测试发送消息（替换 TOKEN 和 CHAT_ID）────────────────────────────────────

BOT_TOKEN=“你的Bot_Token” CHAT_ID=“你的Chat_ID”

curl -s -X POST “https://api.telegram.org/bot${BOT_TOKEN}/sendMessage” -d “chat_id=${CHAT_ID}” -d “parse_mode=Markdown” -d “text=✅ 测试消息 服务器：$(hostname) 时间：$(date ’+%Y-%m-%d %H:%M:%S’) CPU：$(top -bn1 | grep ‘Cpu(s)’ | awk ‘{print $2}’)%“

如果手机收到消息，配置成功！

  
### 企业微信 / 飞书 / 钉钉 Webhook（团队场景）
      企业微信 / 飞书 / 钉钉 Webhook  

── 企业微信机器人 Webhook ───────────────────────────────────────────────────

在企业微信群聊 → 群设置 → 群机器人 → 添加 → 自定义机器人 → 复制 Webhook URL

curl -s -X POST “https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的KEY” -H “Content-Type: application/json” -d ’{ “msgtype”: “text”, “text”: { “content”: “⚠️ 服务器告警 主机：yourdomain.com 状态：CPU 使用率超过 90%” } }’

── 飞书机器人 Webhook ────────────────────────────────────────────────────────

飞书群聊 → 设置 → 群机器人 → 添加机器人 → 自定义机器人 → 复制 Webhook URL

curl -s -X POST “https://open.feishu.cn/open-apis/bot/v2/hook/你的Token” -H “Content-Type: application/json” -d ’{ “msg_type”: “text”, “content”: { “text”: “⚠️ 服务器告警：CPU 使用率超过 90%” } }’

── 钉钉机器人 Webhook ────────────────────────────────────────────────────────

钉钉群聊 → 群设置 → 智能群助手 → 添加机器人 → 自定义 → 复制 Webhook URL

curl -s -X POST “https://oapi.dingtalk.com/robot/send?access_token=你的Token” -H “Content-Type: application/json” -d ’{ “msgtype”: “text”, “text”: { “content”: “⚠️ 服务器告警：磁盘使用率超过 85%” } }’

   
#### 📋 Uptime Kuma 支持的通知渠道（部分）
  Telegram企业微信飞书钉钉SlackDiscordEmailPushoverLineWhatsAppPagerDutyWebhook  
在 Uptime Kuma 面板内直接图形化配置，无需手写代码。
   
##  📝 轻量：Shell 监控脚本（无 Docker）

 
如果您的 VPS 内存不足以跑 Docker 监控工具，或者只是想学习监控的底层原理，可以用一个简单的 Shell 脚本配合 Cron 实现基本的自动巡检和告警。
      /root/server-check.sh  

#!/bin/bash

════════════════════════════════════════════════════════════════════

轻量服务器自检脚本（无需 Docker，适合低配 VPS）

功能：检查 CPU/内存/磁盘/关键服务，超阈值发送 Telegram 告警

════════════════════════════════════════════════════════════════════

set -euo pipefail

── 配置区 ────────────────────────────────────────────────────────────────────

: ”${TG_TOKEN:?请通过受限环境文件提供 TG_TOKEN}” : ”${TG_CHAT_ID:?请通过受限环境文件提供 TG_CHAT_ID}” CPU_THRESHOLD=85 # CPU 使用率告警阈值（%） MEM_THRESHOLD=90 # 内存使用率告警阈值（%） DISK_THRESHOLD=85 # 磁盘使用率告警阈值（%） SERVICES=(“nginx” “mysql”) # 需要检查状态的系统服务 LOG_FILE=“/var/log/server-check.log”

── 工具函数 ──────────────────────────────────────────────────────────────────

log() { echo ”[$(date ’+%Y-%m-%d %H:%M:%S’)] $*” | tee -a “$LOG_FILE”; }

send_alert() { local msg=“$1” log “ALERT: $msg” if [[ -n “$TG_TOKEN” && -n “$TG_CHAT_ID” ]]; then curl -s -X POST “https://api.telegram.org/bot${TG_TOKEN}/sendMessage” -d “chat_id=${TG_CHAT_ID}” -d “text=⚠️ $(hostname): $msg” > /dev/null 2>&1 || true fi }

── 检查 CPU ──────────────────────────────────────────────────────────────────

CPU_USAGE=$(top -bn1 | grep “Cpu(s)” | awk ‘{print int($2)}’) if (( CPU_USAGE > CPU_THRESHOLD )); then send_alert “CPU 使用率 ${CPU_USAGE}%，超过阈值 ${CPU_THRESHOLD}%” fi

── 检查内存 ──────────────────────────────────────────────────────────────────

MEM_TOTAL=$(free | awk ‘/Mem:/ {print $2}’) MEM_USED=$(free | awk ‘/Mem:/ {print $3}’) MEM_USAGE=$(( MEM_USED * 100 / MEM_TOTAL )) if (( MEM_USAGE > MEM_THRESHOLD )); then send_alert “内存使用率 ${MEM_USAGE}%，超过阈值 ${MEM_THRESHOLD}%” fi

── 检查磁盘（检查所有已挂载的本地文件系统）──────────────────────────────────

while IFS= read -r line; do USAGE=$(echo “$line” | awk ‘{print $5}’ | tr -d ’%’) MOUNT=$(echo “$line” | awk ‘{print $6}’) if (( USAGE > DISK_THRESHOLD )); then send_alert “磁盘 ${MOUNT} 使用率 ${USAGE}%，超过阈值 ${DISK_THRESHOLD}%” fi done

❓ 常见问题解答

Uptime Kuma 的检测间隔设多少合适？设太短会有问题吗？   

建议设置 60 秒作为通用值。设置太短（如 10 秒）会增加被监控服务器的请求压力，同时 Uptime Kuma 自身也需要更多 CPU 处理高频检测。对于关键 API 或支付页面等高优先级服务可以降到 30 秒，普通内容站点 120 秒完全够用。另一个重要参数是”判定宕机的失败次数”——建议设为 3 次（即连续 3 次检测失败才触发告警），避免因短暂网络波动导致误报。Uptime Kuma 还支持”心跳监控”模式，适合监控定时任务是否按时执行（配合第 19 篇备份脚本完成后 curl 一个 Kuma 提供的心跳 URL）。

哪吒探针和 Uptime Kuma 应该装在同一台服务器上吗？   

可以同机学习，但不能把它当作可靠宕机告警：主机断电、网络隔离或 Docker 故障时，监控和通知会同时消失。生产环境至少保留一个不同提供商、区域或托管平台的外部探测，并让它监控监控面板自身。资源占用应以实际监控数量、保留周期和插件测量，不用固定内存数字承诺低配机器一定无压力。

Telegram 机器人无法收到通知，如何排查？   

按顺序排查：① Bot Token 和 Chat ID 是否正确：用本文的 curl 命令手动测试发送，看是否收到消息；② 是否先给机器人发过消息：Telegram Bot 只能向主动开启对话的用户发消息，先搜索机器人用户名，点击 Start 发一条消息；③ Chat ID 是否正确：用 @userinfobot 获取的是您自己的 User ID（正确）；如果是群组 Chat ID，通常是负数（如 -1001234567890），确认格式；④ 服务器能否访问 Telegram API：部分服务器的防火墙或网络策略限制了 api.telegram.org 的访问，用 curl https://api.telegram.org/bot你的TOKEN/getMe 测试连通性；⑤ Uptime Kuma 内的通知设置：确认通知已关联到具体的监控项（添加/编辑监控时勾选通知）。

Grafana 仪表盘显示没有数据，Prometheus 配置正确但抓不到指标，怎么办？   

系统性排查：① docker compose ps 和日志确认 Node Exporter 正常；② 从 Prometheus 容器内请求 http://node-exporter:9100/metrics，验证服务名、端口和网络，而不是用容器内的 localhost；③ 查看 Prometheus Targets 页面中的错误信息，但只通过本机隧道或受保护反代访问；④ Grafana 数据源在 Compose 网络内使用 http://prometheus:9090。不要为了排查把 9090/9100 临时开放到公网。

能否监控 Docker 容器的 CPU/内存，而不仅仅是宿主机？   

可以，有多种方案：① cAdvisor（容器顾问）：Google 开源的 Docker 容器监控工具，以容器方式运行，自动发现并采集所有容器的 CPU/内存/网络/磁盘指标，可以直接被 Prometheus 抓取。在 docker-compose.yml 中添加 cadvisor 服务，配置 Prometheus 抓取 cadvisor:8080 端口；② 哪吒探针：Agent 本身就能采集宿主机上所有 Docker 容器的资源使用情况，在面板中按容器维度查看；③ docker stats 命令：docker stats --no-stream 可以快速查看所有容器的实时资源使用，适合临时排查，不适合持续监控。对于 Prometheus + Grafana 方案，导入 Grafana Dashboard ID 14282（Docker Container & Host Metrics）可以同时展示宿主机和容器指标。

如何监控备份任务是否按时执行（而不仅仅是服务器在不在线）？   

使用 Push/Heartbeat 监控，但只能在任务完整成功后发送成功心跳：备份生成、上传、校验任一步失败都必须以非零状态退出，不能由无条件执行的最后一行伪造成功。为任务设置合理宽限期，并另报运行时长、备份时间戳和校验结果。心跳 URL 等同密钥，应存放在受限环境文件；它能证明任务报告过成功，仍不能替代定期恢复演练。

哪吒探针的 Agent 占用多少资源？会影响被监控服务器的性能吗？   

哪吒 Agent 非常轻量：内存占用约 5-15MB，CPU 占用通常低于 0.1%（每隔几秒采集一次系统指标），对被监控服务器几乎没有感知到的性能影响。Agent 以二进制程序方式运行（不需要 Docker），通过 systemd 管理，支持开机自启。网络方面：Agent 会持续与面板端建立一条长连接，带宽消耗微乎其微（约每秒几百字节的心跳数据）。与 Prometheus Node Exporter（约 20MB 内存）相比，哪吒 Agent 更轻量，且提供了更友好的多机管理界面。结论：即使是 512MB 内存的低配 VPS，安装哪吒 Agent 也不会有任何明显影响。

Uptime Kuma 的数据存储在哪里？如何备份监控配置？   

Uptime Kuma 的完整状态位于挂载的 /app/data，官方当前更建议备份整个本地卷或数据目录；界面导出功能不能视为完整备份。为获得一致副本，应在维护窗口停止容器或使用支持 SQLite 一致性的快照方式，再加密复制到异地。恢复时使用相同受支持版本，在隔离实例还原数据目录，验证登录、监控项、通知配置和一次真实测试告警后再切换；不要在运行中直接打包数据库，也不要把数据目录放到 NFS。

学完监控后，下一步应该怎么进阶？   

按本站基础运维 30 篇路径，**第 20 篇（本篇）→ 第 21 篇（low-code-website-build）→ 第 22 篇（network-performance-and-optimization）**是最自然的延伸。关联逻辑：完成了备份（第 19 篇）和监控（本篇），您的服务器基础设施已经相当完善——第 21 篇的 WordPress/Halo 建站可以放心部署，因为有了监控告警和数据备份双重保障；第 22 篇的网络性能优化则解决了另一个常见问题：哪吒探针的流量图显示延迟高或带宽不满，通过 BBR 加速和路由优化来解决。三篇构成”保护→建站→加速”的完整站长成长路径。

监控告警太频繁（告警风暴），如何降低误报率？   

先按用户影响定义等级，再处理噪声：在 Prometheus 规则中用 for 过滤瞬时抖动，必要时用 keep_firing_for 避免短暂丢数造成假恢复；对同一故障的下游告警交给 Alertmanager 分组和抑制，维护窗口只静默已知变更，并保留恢复通知。CPU 等资源指标应结合持续时间和业务错误率，不能只提高阈值隐藏问题。每条关键告警都要有负责人、可执行说明和去重键；定期测试通知渠道，并对“长时间完全没有任何告警或心跳”单独报警。

🚀 下一步行动

监控体系建立完毕，接下来快速建站并进入网络优化： [ 🌐

零代码快速建站

WordPress / Halo 一键上线，配合监控和备份策略让博客稳定运行。 开始学习 ](/guides/low-code-website-build)[ 📡

网络性能测试与优化

探针显示延迟高？学习 BBR 加速与 iPerf3 测速，找出真正的网络瓶颈。 开始学习 ](/guides/network-performance-and-optimization)[ ⭐

VPS 推荐榜单

查看 VPS 实测与服务商索引，先看结论再去官网。 查看推荐 ](/vps-recommendations)[ 📚

浏览更多教程

继续探索服务器安全、网站搭建、性能优化和 AI 环境主题。 探索教程 ](/guides)
读完后建议 先验证，再选择 把判断落到具体选择 准备购买 VPS 时，先对照推荐榜单和真实测评确认线路、价格、用途与风险；只是继续学习，可以回到教程索引按主题往下看。 查看推荐榜单 回到教程索引