监控不是一块好看的大屏,而是“发现异常、通知到人、保留证据、确认恢复”的闭环。至少从另一台机器或托管探针检查真实业务路径,再用主机指标解释原因;监控系统本身也需要外部心跳、配置备份和定期通知演练。
👀 为什么需要监控?
故障秒级感知
网站打不开?数据库挂了?监控系统能在 1 分钟内通过 Telegram 发警报到您手机——比用户投诉早几小时。
容量与性能预警
硬盘用了 90%?内存持续爆满?提前发现瓶颈,在系统彻底卡死前进行清理或扩容。
SLA 历史复盘
记录 VPS 真实在线率(Uptime)。服务商频繁断网?有数据截图才能申请退款或换机。
⚖️ 主流监控方案对比
监控至少包含两层:从故障域之外验证 DNS、TLS、HTTP 内容和真实操作是否可用,以及在服务器内部采集资源与应用指标解释原因。两层应分开部署并互相补充。
| 工具 | 类型 | 内存占用 | 核心优势 | 适合场景 |
|---|---|---|---|---|
| Uptime Kuma | 外部可用性监控 | 按实例实测 |
| 网站/API/证书与任务心跳 |
| 哪吒探针 (Nezha) | 服务器集群监控 | ~30MB |
| 拥有多台 VPS 的玩家 |
| Prometheus + Grafana | 企业级时序监控 | ~500MB+ |
| 企业生产环境/大型系统 |
| 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
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
# 将 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:${PROMETHEUS_VERSION}
container_name: prometheus
restart: unless-stopped
ports:
- "127.0.0.1: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:${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
# 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: ['node-exporter:9100'] # Compose 网络内使用服务名
# 如需监控其他服务器,添加更多 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:?请通过受限环境文件提供 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 < <(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 已停止运行,需要人工确认日志、依赖和最近变更"
fi
done
log "自检完成:CPU=${CPU_USAGE}% MEM=${MEM_USAGE}% DISK 检查完成"
# ── 部署(每 5 分钟执行一次)────────────────────────────────────────────────
# chmod +x /root/server-check.sh
# crontab -e 添加:
# 使用权限为 600 的 EnvironmentFile 向 systemd timer 提供令牌;
# 不要把令牌直接写进脚本或 crontab,也不要静默自动重启未知故障 ❓ 常见问题解答
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 加速和路由优化来解决。三篇构成"保护→建站→加速"的完整站长成长路径。
监控告警太频繁(告警风暴),如何降低误报率?
先按用户影响定义等级,再处理噪声:对瞬时抖动设置连续失败或持续时间,对同一故障的下游告警做分组和抑制,维护窗口只静默已知变更,并保留恢复通知。CPU 等资源指标应结合持续时间和业务错误率,不能只提高阈值隐藏问题。每条关键告警都要有负责人、可执行说明和去重键;定期测试通知渠道,并对“长时间完全没有任何告警或心跳”单独报警。