用便宜 VPS 自建监控告警：Uptime Kuma 部署与宕机 Telegram 推送 2026

延伸阅读

更多相关攻略推荐：连云厂商也看不到你的数据？机密计算（Confidential Com、被割裂的"云上互联网"：数据主权（GDPR）、本地化存储与主权云（S、为什么你自己 VPS 发的邮件总进垃圾箱？邮件协议（SPF、DKIM、百兆带宽如何流畅看 4K？视频切片（HLS/DASH）、AVIF 压、告别繁琐密码：OAuth 2.0、SSO 单点登录与 Passkey。

为什么是「独立监控机」而不是「再来一台业务机」

很多人买 VPS 之后最容易忽略的一件事是：机器挂了，你可能是最后一个知道的人。一个网站半夜证书续期失败、Nginx 直接不工作，第二天早上打开后台才发现已经挂了几小时，这种事几乎每个站长都经历过。与其等用户来投诉，不如让一台机器专门盯着其余所有机器。这就是「监控机」的定位：它不参与业务，唯一职责是告诉你「谁挂了、为什么挂了」。

但有个常识很多人会踩：如果你把网站和监控面板都跑在同一台 VPS 上，那么机器一旦宕机，监控面板也跟着一起挂，它自然没法通知你。所以真正有用的监控机，应当是一台独立的、和你主业务不同机房甚至不同商家的小机器。好消息是，这种机器对性能要求极低，一台年付十几美元的低价 VPS 就完全够用，这也正是本站反复推荐便宜 VPS 的理由——它不只是用来建站，更是运维的「保险丝」。

Uptime Kuma 到底是什么

Uptime Kuma 是一个开源（MIT 协议）的自托管监控面板，作者 Louis Lam，目前在 GitHub 上星标超过 8 万。它可以监控 HTTP/HTTPS 网站、TCP 端口、Ping（ICMP）、DNS 记录、Docker 容器、SSL 证书到期时间，还支持关键词监控（页面里必须出现某个词，否则判异常）和 JSON 查询监控（检查 API 返回值是否符合预期）。当某个监控项异常时，它通过 90 多种通知渠道推送告警：Telegram、Discord、Slack、Email（SMTP）、Webhook、企业微信、Pushover 等。它还内置了公开状态页，你可以把服务在线情况分享给用户看。

简单说，它是 Pingdom、UptimeRobot 这类付费 SaaS 的免费自托管替代品。区别在于：Pingdom 起步价约 15 美元/月只给 10 个监控项，监控项越多越贵；而 Uptime Kuma 本身免费、监控项不限量、检查间隔最低可到 20 秒、状态页不限量、通知渠道全免费。代价是你需要自己准备一台机器并维护它。对个人站长、小团队和自托管玩家来说，这笔账很清楚。

监控机选址：三件最容易忽略的事

选监控机的位置，比选监控机配置更重要。结合社区经验，有三点值得先说清楚：

• 别和主业务同机：这是底线。主业务宕机时，监控机必须还活着，否则告警毫无意义。
• 尽量不同商家、不同机房：如果你主站在商家 A 的洛杉矶机房，监控机放商家 B 的纽约或水牛城，能避免「同一商家大面积故障导致监控和业务一起失联」。
• 地理视角要匹配你的用户：监控机看到的是它到自己服务器的网络质量，不等于你用户的体验。如果你的用户主要在国内，把监控机放在欧洲，它看到的「正常」未必代表国内用户能正常访问。这种场景下，监控机更适合用来发现「彻底宕机 / 端口不通 / 证书过期」这类硬故障，而不是用来衡量国内访问速度。

另外要诚实提醒：Uptime Kuma 是单点部署，它本身如果完全宕机，就没人通知你了。后面的章节会讲怎么用「监控机互监」或第三方兜底来补这个洞。

四家低价 VPS 做监控机的真实配置与价格

下面这张表汇总了 2026 年常见促销下，四家适合做监控机的低价方案。Uptime Kuma 非常轻量：少量监控项占用内存不到 100MB，v2.x 版本约 80–120MB，跑在 512MB 内存的机器上都没问题。所以下面这些 1GB 入门款都绰绰有余，甚至 512MB 也能带。

从「做监控机」的角度看：RackNerd 和 CloudCone 年付十几美元最省心；ColoCrossing 的 40TB 流量对你监控机本身用不上那么多，但价格同样低；Vultr 胜在机房多、能挑离你用户近的位置，且按小时计费，适合临时开一台就近探测。具体促销以商家页面为准，上面是常见促销区间，不代表任何时候都能买到。

动手前准备

本文默认环境是 Ubuntu 22.04 / 24.04 或 Debian 12，已经安装好 Docker 和 Docker Compose。先确认环境可用：

docker version
docker compose version

如果你打算用域名访问监控面板（推荐），还需要一个解析到这台 VPS 的域名，例如 status.example.com，并且 80/443 端口可访问。确认解析生效：

dig status.example.com +short

一行命令跑起来（Docker run）

最快的方式是官方一条 docker run 命令。它会自动拉取镜像、创建一个名为 uptime-kuma 的容器，并把数据存到名为 uptime-kuma 的卷里：

docker run -d --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:2

注意这里指定了 :2 这个主版本标签，而不是直接用 latest，这样升级更可控。跑起来后浏览器打开 http://你的IP:3001 就能创建管理员账号。但这种方式把 3001 端口直接暴露公网，仅适合临时测试，正式用请看下一个 Compose 方案。

更稳妥的 Compose 部署（数据持久化 + 只绑 localhost）

生产环境我更推荐用 Docker Compose，原因是数据持久化更清晰，且可以把端口只绑在 127.0.0.1，不让 3001 直接暴露公网。先建目录：

sudo mkdir -p /opt/uptime-kuma
sudo chown -R "$USER":"$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
mkdir -p data

然后写 docker-compose.yml：

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

注意 127.0.0.1:3001:3001 这一行：它让容器只监听本机回环地址。如果不写 127.0.0.1 前缀，Docker 会把端口发布到所有网卡，等于绕过了你的防火墙。启动并查看状态：

docker compose up -d
docker compose ps
docker compose logs -f --tail=100

本机测试一下是否通：

curl -I http://127.0.0.1:3001

如果你还想用 Uptime Kuma 监控同一台 VPS 上的 Docker 容器，需要额外挂 Docker socket。但这是高敏感入口，只在确实需要时开启，并且务必保持 3001 只走 HTTPS：

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "127.0.0.1:3001:3001"

用 Caddy 套一层 HTTPS（强烈建议）

监控面板里会保存通知渠道的 Token、Webhook 地址和服务信息，裸奔在公网风险很大。用 Caddy 做反向代理，能自动申请 Let's Encrypt 证书，几行配置搞定 HTTPS。编辑 Caddyfile：

status.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:3001
}

检查并重载：

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

之后浏览器打开 https://status.example.com，第一次访问会让你创建管理员账号。请务必使用强密码，并建议进入 Settings → Security 开启两步验证（2FA）。

加第一个监控项：网站 / 端口 / 证书

登录后点 Add New Monitor。对大多数站长，先从 HTTP(s) 网站监控开始：

• Monitor Type：HTTP(s)
• Friendly Name：主站
• URL：https://example.com
• Heartbeat Interval：60 秒或 120 秒
• Retries：2–3 次
• Accepted Status Codes：200–299

我一般不把间隔设成最短的 20 秒。便宜 VPS、海外线路偶尔抖一下很正常，设太激进最后可能是自己吓自己。比较稳的设置是间隔 60 秒 + 重试 3 次，能过滤掉短暂网络抖动。

另外值得监控的几类：TCP 端口（22、443、5432、6379 看端口是否存活）、Ping（VPS IP 看机器或线路是否通）、Keyword 关键词（页面必须出现某个固定词，避免「返回 200 但页面已变成错误页」的假正常）、以及SSL 证书到期（提前 14 天告警，防止红色警告页）。这些类型在添加监控时下拉切换即可，无需改部署。

接入 Telegram 宕机推送

Telegram 是我最推荐的告警渠道：免费、快、配置简单。整体分三步。

第一步，用 BotFather 创建机器人。在 Telegram 搜索 @BotFather，发送 /newbot，按提示给机器人起名（如 My Server Monitor）和用户名（必须以 _bot 结尾，如 myservermonitor_bot）。BotFather 会回你一个形如 1234567890:ABCdefGHIjklMNOpqrsTUVwxyz 的 API Token，保存好。

第二步，拿到 Chat ID。先给你的新机器人发一条任意消息，然后在浏览器打开：

https://api.telegram.org/bot你的TOKEN/getUpdates

返回 JSON 里的 chat.id 字段就是你的 Chat ID。嫌麻烦也可以直接在 Telegram 里搜 @userinfobot，它会立刻告诉你自己的 ID。

第三步，在 Uptime Kuma 里填。进入 Settings → Notifications → Setup Notification，类型选 Telegram，填入 Bot Token 和 Chat ID，点 Test。成功后会立刻收到一条测试消息。然后把这个通知渠道绑定到重要监控项（编辑监控项，下拉选通知渠道并保存），或设为默认。之后某监控宕机，Telegram 会收到含名称、状态码和错误详情的消息；恢复时也会收到恢复消息。

再配一个邮件兜底

Telegram 偶尔会被手机系统静音，邮件至少能留记录。常见 SMTP 配置：

Host: smtp.example.com
Port: 587
Security: STARTTLS
Username: monitor@example.com
Password: 邮箱授权码（不是登录密码）
From: monitor@example.com
To: you@example.com

注意几个坑：很多邮箱不能用登录密码，要用应用专用密码；VPS 商可能限制 25 端口，优先用 587 或 465；发件邮箱最好配好 SPF、DKIM、DMARC，否则容易进垃圾箱；不要把个人主邮箱密码填进去。个人项目用「Telegram + 邮件」已经足够稳妥。

做一个公开状态页

Uptime Kuma 的状态页很实用。侧边栏进入 Status Page → New Status Page，起个标题、勾选要展示的监控项，就能生成一个公开链接，例如 https://status.example.com/status/main，用户能看到哪些服务正常、哪些故障。但我建议只放用户需要知道的东西（官网、API、下载站），数据库、Redis、内部后台不要公开，没必要暴露你的内部结构。

监控面板自己也要被监控

这点很多人会忘。如果 Uptime Kuma 只监控别人，自己挂了没人知道，那它就成了单点故障。更稳的做法有几种：

• 用另一个免费监控服务（如 UptimeRobot、Healthchecks、Better Stack）盯着你的 status.example.com；
• 再开一台低价 VPS 跑第二个 Kuma，两台互监；
• 或者拿主业务机反过来监控监控机本身（前提是主业务机还活着时能报警）。

个人项目不用搞太复杂，但至少要知道一个事实：单点监控只能发现别人的问题，发现不了自己完全宕机的问题。

备份与升级

Uptime Kuma 的数据全在 /opt/uptime-kuma/data 目录（含 kuma.db 和上传文件）。备份这个目录即可：

cd /opt/uptime-kuma
tar czf /opt/backups/uptime-kuma-$(date +%F-%H%M).tar.gz data

升级前同样先备份，然后拉新镜像重启：

docker compose pull
docker compose up -d
docker compose logs -f --tail=100

如果你不想每次追最新版，固定用 louislam/uptime-kuma:2 这种主版本标签最省心；生产环境更建议先在测试机升一遍再上生产。

常见误报与排查

• 访问域名出现 502：先 docker compose ps 看容器是否活着，再 curl -I 127.0.0.1:3001 本机测试，活着的话问题通常在 Caddy 反代端口写错。
• 通知测试成功但故障时没提醒：九成是忘了把通知渠道绑定到监控项。Uptime Kuma 的通知可以设默认，也可以只绑某几个监控项。
• 经常误报：多半是检测太激进。把间隔从 20 秒改 60 秒、Retries 设 2–3、超时放宽；不要用单个海外节点去衡量国内线路质量。
• 页面返回 200 但实际坏了：用 Keyword 监控，要求页面必须含某个固定词，错误页/空白页即便状态码 200 也能被发现。
• Docker Container 监控连不上：检查 Compose 是否挂载了 /var/run/docker.sock，没挂就加一行重启。

老实说几个缺点

Uptime Kuma 不是万能的，写文章不能只夸。它有几个诚实的局限：

• 单点部署：它只从一个位置探测，不像 Pingdom 那样从全球多个探针检查。需要多地监控就得自己开多台。
• SQLite 上限：所有数据存在一个本地 SQLite 文件里。监控项冲到几百个之后，仪表盘响应会变慢，社区里有人反馈加载 600 个 URL 后基本卡住。
• 没有真正的配置即代码：它没有完整 REST API，监控项基本只能在点界面里一个个加，没法方便地写进 Git 做版本管理或批量变更。
• 不是指标监控：它告诉你「服务挂没挂」，但不告诉你「为什么慢」。CPU、内存、磁盘、慢查询趋势要看 Prometheus + Grafana 或 Beszel 这类工具。
• 你要自己维护：备份、升级、HTTPS、被扫端口的风险都得自己扛。免费的前提是你要花一点时间。

小结

用一台年付十几美元的便宜 VPS 跑 Uptime Kuma，是性价比极高的「第一层监控」：网站打不开、API 挂了、端口不通、证书快过期、关键词消失，它都能很快推一条 Telegram 给你。把它放在和主业务不同商家、不同机房的独立小机器上，再补一个邮件兜底和「监控机互监」，你的基础设施就有了一道低成本的保险。对于只是想「宕机有人立刻通知我」的个人站长和小团队，这已经完全够用，不必一上来就上 Prometheus 那套重武器。

文中四家商家的价格为 2026 年常见促销区间，具体促销以商家页面为准，库存和价格随时变动，下单前请以官网实时显示为准。