把网站跑起来只是第一步,如何确保它 24 小时稳定运行才是真功夫。当服务器被 DDoS 攻击、硬盘被日志塞满、数据库突然崩溃时,没有监控的情况下您可能在用户投诉后才发现问题。本指南将教您搭建从"存活监控"到"性能探针"的完整"千里眼"体系。
👀 为什么需要监控?
故障秒级感知
网站打不开?数据库挂了?监控系统能在 1 分钟内通过 Telegram 发警报到您手机——比用户投诉早几小时。
容量与性能预警
硬盘用了 90%?内存持续爆满?提前发现瓶颈,在系统彻底卡死前进行清理或扩容。
SLA 历史复盘
记录 VPS 真实在线率(Uptime)。服务商频繁断网?有数据截图才能申请退款或换机。
⚖️ 主流监控方案对比
监控工具分两大流派:只测"死活"的外部存活监控,和深入系统内部查看各项指标的性能探针监控。根据需求选择:
| 工具 | 类型 | 内存占用 | 核心优势 | 适合场景 |
|---|---|---|---|---|
| Uptime Kuma | 服务存活监控 | ~50MB |
| 个人网站/API 在线率监控 |
| 哪吒探针 (Nezha) | 服务器集群监控 | ~30MB |
| 拥有多台 VPS 的玩家 |
| Prometheus + Grafana | 企业级时序监控 | ~500MB+ |
| 企业生产环境/大型系统 |
| Shell 脚本 + Cron | 极简自检脚本 | ~0MB |
| 低配VPS/学习目的/应急 |
💡 推荐搭配: Uptime Kuma(监控网站存活 + 对外公开状态页)+ 哪吒探针(监控服务器资源指标)。两者互补,前者轻量面向外部,后者深入面向内部。
🟢 实战:Uptime Kuma 部署与配置
Uptime Kuma 被誉为"自托管版 UptimeRobot",UI 极具现代感,支持 HTTP/TCP/DNS/关键字等多种检测方式,可以生成公开的状态页面(如 status.yourdomain.com)供用户查看服务状态。
Docker Compose 部署
# 文件路径:/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
# 将 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
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 面板后台:节点管理 → 添加节点,复制生成的安装命令
# 命令格式类似:
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
# 完整监控栈: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
# 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 机器人(个人最推荐)
# ── 通过 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 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 支持的通知渠道(部分)
在 Uptime Kuma 面板内直接图形化配置,无需手写代码。
📝 轻量:Shell 监控脚本(无 Docker)
如果您的 VPS 内存不足以跑 Docker 监控工具,或者只是想学习监控的底层原理,可以用一个简单的 Shell 脚本配合 Cron 实现基本的自动巡检和告警。
#!/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 的"维护"功能可以设置计划维护时间窗口,期间不发告警。