VPSKnow

VPS 运行监控与宕机报警完全指南

中级
35分钟

把网站跑起来只是第一步,如何确保它 24 小时稳定运行才是真功夫。当服务器被 DDoS 攻击、硬盘被日志塞满、数据库突然崩溃时,没有监控的情况下您可能在用户投诉后才发现问题。本指南将教您搭建从"存活监控"到"性能探针"的完整"千里眼"体系。

👀 为什么需要监控?

🚨

故障秒级感知

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

📈

容量与性能预警

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

📊

SLA 历史复盘

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

⚖️ 主流监控方案对比

监控工具分两大流派:只测"死活"的外部存活监控,和深入系统内部查看各项指标的性能探针监控。根据需求选择:

工具 类型 内存占用 核心优势 适合场景
Uptime Kuma 服务存活监控 ~50MB
  • 高颜值 UI,公开状态页
  • HTTP/TCP/DNS/关键字多种检测
  • 轻量,支持 Docker 一键部署
个人网站/API 在线率监控
哪吒探针 (Nezha) 服务器集群监控 ~30MB
  • 多台 VPS 同屏展示资源
  • 内置 WebSSH 和文件管理
  • 支持流量/CPU/内存/硬盘全指标
拥有多台 VPS 的玩家
Prometheus + Grafana 企业级时序监控 ~500MB+
  • 图表最丰富,数据精度最高
  • 告警规则极其灵活
  • 开源生态最完整(Node Exporter 等)
企业生产环境/大型系统
Shell 脚本 + Cron 极简自检脚本 ~0MB
  • 零依赖,任何服务器可用
  • 完全自定义检测逻辑
  • 配合第19篇备份脚本一体化
低配VPS/学习目的/应急

💡 推荐搭配: Uptime Kuma(监控网站存活 + 对外公开状态页)+ 哪吒探针(监控服务器资源指标)。两者互补,前者轻量面向外部,后者深入面向内部。

🟢 实战: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:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"     # 只绑定本地,配合 Nginx 反代对外提供 HTTPS
    volumes:
      - ./kuma-data:/app/data      # 数据持久化(监控配置、历史记录)
    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;
}

⚙️ 登录后首要配置步骤

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

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

当您的 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:latest
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.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:latest
    container_name: node-exporter
    restart: unless-stopped
    network_mode: host                  # 使用宿主机网络,才能采集到准确的网络指标
    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:latest
    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 中设置
      - GF_USERS_ALLOW_SIGN_UP=false                     # 禁止公开注册

volumes:
  prometheus_data:
  grafana_data:

prometheus.yml 抓取配置

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

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: ['localhost:9100']  # Node Exporter 默认端口

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

💡 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<TOKEN>/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=""                    # Telegram Bot Token(留空则只记录日志)
TG_CHAT_ID=""                  # Telegram 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 < <(df -h --output=source,size,used,avail,pcent,target | grep '^/' | tail -n +2)

# ── 检查关键服务 ──────────────────────────────────────────────────────────────
for svc in "${SERVICES[@]}"; do
  if ! systemctl is-active --quiet "$svc"; then
    send_alert "服务 $svc 已停止运行!尝试自动重启..."
    systemctl restart "$svc" || send_alert "服务 $svc 重启失败!需手动介入"
  fi
done

log "自检完成:CPU=${CPU_USAGE}% MEM=${MEM_USAGE}% DISK 检查完成"

# ── 部署(每 5 分钟执行一次)────────────────────────────────────────────────
# chmod +x /root/server-check.sh
# crontab -e 添加:
# */5 * * * * /root/server-check.sh

常见问题解答

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

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

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

可以装在一起,但有单点风险:如果那台机器宕机,两个监控系统同时失效。更好的方案是分开部署:① 哪吒面板和 Uptime Kuma 部署在独立的低配监控机(价格便宜、稳定即可);② 哪吒 Agent 和 Uptime Kuma 的 HTTP 检测目标部署在各业务服务器上。如果只有一台 VPS,装在一起也完全没问题——监控工具宕机本身就说明服务器有问题,您会从其他途径(如用户反馈)得知。资源消耗方面:Uptime Kuma 约 50MB,哪吒面板约 30MB,两者共存在 512MB 内存的服务器上完全没压力。

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 配置正确但抓不到指标,怎么办?

系统性排查:① Node Exporter 是否在运行curl http://localhost:9100/metrics | head -20,应看到大量指标数据;② Prometheus 能否访问 Node Exporter:访问 http://localhost:9090/targets,检查 node 目标的 State 是否是 UP(绿色),DOWN 则表示抓取失败;③ Docker 网络问题:如果 Prometheus 在容器内,而 Node Exporter 使用 network_mode: host,Prometheus 配置中的 target 应该是 host.docker.internal:9100 或宿主机内网 IP,而不是 localhost:9100(容器内的 localhost 是容器自身);④ Grafana 数据源:确认在 Grafana 中添加了 Prometheus 数据源,URL 填写正确(容器间通信用服务名:http://prometheus:9090)。

能否监控 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)可以同时展示宿主机和容器指标。

如何监控备份任务是否按时执行(而不仅仅是服务器在不在线)?

这是"心跳监控"(Heartbeat Monitoring)的典型应用场景。Uptime Kuma 支持"Push"类型监控:① 在 Kuma 中添加新监控,类型选 Push,Kuma 会生成一个专属 URL(如 https://status.yourdomain.com/api/push/xxxx);② 在第 19 篇的备份脚本末尾添加一行:curl -s "https://status.yourdomain.com/api/push/xxxx";③ Kuma 会期望每隔固定时间收到一次 Push 请求,如果超时未收到(说明备份脚本没有正常执行完成),立即触发告警。这样就能监控到"脚本是否跑完"而不仅仅是"服务器在不在线",是保证备份可靠性的重要补充。

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

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

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

Uptime Kuma 使用 SQLite 存储所有配置和历史数据,文件在 Compose 挂载的 ./kuma-data/kuma.db。备份方法:① 定期复制数据目录:将 /opt/uptime-kuma/kuma-data/ 整个目录加入第 19 篇的备份脚本(加一行 tar -czf /backup/kuma_data_\$(date +%Y%m%d).tar.gz /opt/uptime-kuma/kuma-data/);② Uptime Kuma 内置备份导出:面板设置 → 备份,可以导出 JSON 格式的配置文件,导入到新实例时能还原所有监控项配置(不含历史记录);③ 迁移时只需复制数据目录并重启容器,所有监控项、告警历史、通知配置全部保留。

学完监控后,下一步应该怎么进阶?

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

监控告警太频繁(告警风暴),如何降低误报率?

告警风暴通常由以下原因导致,逐一处理:① 检测频率太高 + 判定次数太少:将 Uptime Kuma 的检测间隔从 30 秒改为 60 秒,失败判定次数从 1 次改为 3 次——这样需要连续 3 分钟都失败才告警,排除短暂抖动;② 超时时间太短:部分网站响应本来就慢(如冷启动),将超时阈值从 5 秒提高到 10-15 秒;③ Shell 脚本阈值设置太低:CPU 阈值 85% 在正常压力测试时会触发,调高到 95% 或改为"持续 10 分钟超过 90% 才告警"(在脚本中加计数器逻辑);④ 告警恢复通知:Uptime Kuma 支持"恢复时也发通知",这样您能知道服务已自动恢复,不需要持续跟进;⑤ 维护时段静默:Uptime Kuma 的"维护"功能可以设置计划维护时间窗口,期间不发告警。