欢迎光临
        找回密码

VPS 上用 Uptime Kuma 自建服务状态监控面板：告别第三方依赖，打造专属可用性监控中心

2026-08-24 分类：VPS和建站 阅读(3) 评论(0)

为什么你需要自建服务状态监控

不管你是运营一台 VPS 还是一群服务器，服务可用性永远是第一优先级。很多站长依赖 UptimeRobot、Pingdom 或者 StatusCake 这类第三方监控服务，虽然起步简单，但免费版限制明显：监控节点少、通知渠道有限、状态页面没法自定义域名和样式。更重要的是，你的服务可用性数据完全掌握在别人手里。

Uptime Kuma 是一个开源的、自托管的监控工具，由 Louislam 开发维护，GitHub 上拥有超过 60k Star。它提供了与 UptimeRobot 几乎一致的功能体验，同时完全免费、无数量限制、数据完全归你所有。本文将从零开始在 VPS 上部署 Uptime Kuma，配置多种监控类型和通知渠道，并搭建一个面向用户的状态页面。

环境准备与 Docker 部署

Uptime Kuma 官方推荐使用 Docker 部署，这是最简单也最稳定的方式。假设你的 VPS 已经安装了 Docker 和 Docker Compose，如果还没有，先执行以下命令安装：



1
2
3
4
5
6
# 安装 Docker（适用于 Ubuntu/Debian）

curl -fsSL https://get.docker.com | sh

sudo systemctl enable docker --now



# 验证安装

docker --version

创建项目目录和

1
docker-compose.yml

：



1
mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma





1
2
3
4
5
6
7
8
9
10
11
12
version: '3.8'

services:

  uptime-kuma:

    image: louislam/uptime-kuma:1

    container_name: uptime-kuma

    ports:

      - '3001:3001'

    volumes:

      - ./data:/app/data

    restart: unless-stopped

    environment:

      - TZ=Asia/Shanghai

这里使用 3001 端口映射，避免与 VPS 上其他服务冲突。

1
TZ

环境变量确保监控时间线显示正确时区。启动服务：



1
docker compose up -d

等待约 30 秒后访问

1
http://你的VPS_IP:3001

，首次进入会要求创建管理员账号。请务必设置一个强密码，这是你整个监控系统的入口。

配置 Nginx 反向代理与 HTTPS

直接暴露 3001 端口不是最佳实践。我们用 Nginx 做反向代理并配上 Let’s Encrypt 证书，这样监控面板和状态页面都能走 HTTPS。



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# /etc/nginx/sites-available/uptime-kuma.conf

server {

    listen 80;

    server_name status.yourdomain.com;



    location / {

        proxy_pass http://127.0.0.1:3001;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;



        # WebSocket 支持（推送通知必需）

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

    }

}

启用配置并申请证书：



1
2
3
4
5
sudo ln -s /etc/nginx/sites-available/uptime-kuma.conf /etc/nginx/sites-enabled/

sudo nginx -t && sudo systemctl reload nginx



# 使用 certbot 申请证书

sudo certbot --nginx -d status.yourdomain.com

注意 WebSocket 的配置非常关键。Uptime Kuma 使用 WebSocket 实现实时推送，如果漏掉

1
Upgrade

和

1
Connection

头，浏览器端的状态更新会中断，通知也会延迟。如果你使用的是 Caddy，这些头会自动处理。

监控类型全解析

Uptime Kuma 支持多种监控类型，远不止简单的 HTTP 检测。以下是每种类型的使用场景和配置要点：

HTTP(s) 监控

最常用的类型，适合监控网站和 API 端点。除了基本的 URL 检测，你还可以：

  • 配置期望的 HTTP 状态码（如只认为 200 是正常）
  • 设置关键词匹配，验证页面内容是否包含特定字符串
  • 自定义请求头和请求体，用于 POST 接口监控
  • 忽略 TLS 证书错误（适用于自签证书场景）


1
2
3
4
5
6
配置示例：

URL: https://api.example.com/health

方法: GET

期望状态码: 200

关键词: "status":"ok"

检查间隔: 60 秒

TCP 端口监控

用于监控非 HTTP 服务，如数据库、Redis、SSH 等：

  • MySQL：监控 3306 端口
  • Redis：监控 6379 端口
  • SSH：监控 22 端口
  • 自定义应用端口

DNS 监控

验证 DNS 解析是否正确，对于域名迁移、CDN 切换等场景非常有用：



1
2
3
4
主机名: example.com

解析类型: A

期望结果: 1.2.3.4

DNS 服务器: 8.8.8.8（可选指定）

Ping 监控

最基础的网络可达性检测，适用于监控 VPS 本身是否在线。注意部分 VPS 提供商禁用了 ICMP，使用前先确认。

关键词监控

HTTP 监控的增强版，不仅检查状态码，还验证响应内容是否包含或排除特定关键词。适合验证 API 返回的业务数据是否正常，比如检查 JSON 响应中的特定字段值。

推送类型

这是一种被动监控模式。你的服务器主动向 Uptime Kuma 发送心跳请求，如果在指定时间内没有收到心跳，就判定为宕机。非常适合以下场景：

  • 内网服务无法被外部直接访问
  • Cron 定时任务的执行确认
  • 批处理作业的完成通知


1
2
3
4
# 在你的 Cron 任务末尾加上

curl -s -o /dev/null "https://status.yourdomain.com/api/push/xxxxx"



# 如果脚本执行失败，不发送推送，Uptime Kuma 就会在超时后报警

Docker 容器监控

直接监控本机 Docker 容器状态，当容器停止或重启时触发告警。需要在 Docker Compose 中挂载 socket：



1
2
volumes:

  - /var/run/docker.sock:/var/run/docker.sock

其他类型

Uptime Kuma 还支持 Steam 游戏服务器监控、Mqtt 物联网协议监控、SQL Server / Postgres / MySQL 数据库查询监控等。对于站长来说，上面几种已经覆盖了 90% 的需求。

通知渠道配置实战

监控发现问题后，通知到达的速度决定了故障响应的效率。Uptime Kuma 支持超过 90 种通知方式，以下是最常用的几种：

Telegram 通知（推荐）

Telegram 通知即时性好、免费无限制、支持消息格式丰富。配置步骤：



1
2
3
4
5
6
7
8
9
10
1. 在 Telegram 中搜索 @BotFather，创建一个新 Bot

2. 获取 Bot Token（格式如 123456789:ABCdefGHIjklMNOpqrsTUVwxyz）

3. 获取你的 Chat ID：

   - 向 @userinfobot 发送任意消息获取 ID

   - 或访问 https://api.telegram.org/bot<TOKEN>/getUpdates

4. 在 Uptime Kuma 中添加 Telegram 通知：

   - 通知类型选择 Telegram

   - 填入 Bot Token

   - 填入 Chat ID

   - 点击测试按钮确认

企业微信 / 钉钉通知

国内用户更常用的选择。Uptime Kuma 支持通过 Webhook 接入企业微信机器人和钉钉机器人：



1
2
3
4
5
# 企业微信 Webhook 地址格式

https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY



# 钉钉机器人 Webhook

https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN

配置时选择 Webhook 通知类型，URL 填入对应地址，请求体格式按照各平台的 API 文档填写即可。

邮件通知

使用 SMTP 发送邮件通知。建议使用专门的告警邮箱配合应用专用密码：



1
2
3
4
5
6
7
SMTP 主机: smtp.gmail.com

SMTP 端口: 587

安全: STARTTLS

用户名: your@gmail.com

密码: 应用专用密码

发件人: your@gmail.com

收件人: admin@yourdomain.com

多级通知策略

实际运维中，建议配置多级通知策略。比如：

  • 首次告警：Telegram 即时通知
  • 持续 5 分钟未恢复：补发邮件通知
  • 重大故障（核心服务宕机）：同时推送到企业微信群

Uptime Kuma 支持为每个监控项配置多个通知渠道，并在通知设置中调整重发间隔。

搭建公开状态页面

Uptime Kuma 内置了精美的状态页面功能，可以向用户公开展示服务运行状态。这在 SaaS 和 VPS 服务商中非常常见。

进入 Uptime Kuma 面板，点击左侧菜单 Status Pages，创建新页面：



1
2
3
名称: 服务状态

Slug: default

域名: status.yourdomain.com

在状态页面中，你可以：

  • 按分组展示不同类别的服务（如「核心服务」「API 接口」「基础设施」）
  • 显示最近 90 天的可用率统计
  • 展示维护计划
  • 自定义 Logo 和主题色

状态页面会自动生成一个公开 URL，你可以直接分享给用户或嵌入到网站中。所有数据实时更新，不需要额外维护。

数据持久化与备份策略

Uptime Kuma 的所有数据存储在

1
/opt/uptime-kuma/data

目录下的 SQLite 数据库中。虽然 SQLite 对于监控这种写多读少的场景足够用，但必须做好备份：



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash

# /opt/uptime-kuma/backup.sh

BACKUP_DIR="/opt/uptime-kuma/backups"

DATA_DIR="/opt/uptime-kuma/data"

DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $BACKUP_DIR



# 安全复制数据库（避免写入时复制导致损坏）

docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup /app/data/backup_temp.db"

docker cp uptime-kuma:/app/data/backup_temp.db "$BACKUP_DIR/kuma_$DATE.db"



# 保留最近 30 天备份

find $BACKUP_DIR -name "*.db" -mtime +30 -delete



echo "Backup completed: kuma_$DATE.db"

将备份脚本加入 Cron：



1
2
# 每天凌晨 3 点备份

0 3 * * * /opt/uptime-kuma/backup.sh >> /opt/uptime-kuma/backups/backup.log 2>&1

同时建议将备份文件同步到异地存储。你可以使用 Rclone 将备份推送到对象存储：



1
2
3
4
5
6
7
8
# 安装 Rclone

curl https://rclone.org/install.sh | sudo bash



# 配置远程存储（以 Backblaze B2 为例）

rclone config



# 在备份脚本末尾追加

rclone copy $BACKUP_DIR/kuma_$DATE.db remote:uptime-kuma-backups/

性能优化与安全加固

监控数量与性能

Uptime Kuma 单实例可以轻松处理 100+ 个监控项。但如果你的监控数量超过 200 个，需要注意：

  • 检查间隔不要设太短（30 秒以下会增加 CPU 和网络负载）
  • 合理使用分组，避免单一通知渠道过载
  • 定期清理过期的监控数据

安全建议

  • 修改默认端口：不用常见的 3001，改用高位随机端口
  • 限制访问 IP：在 Nginx 层面只允许你的 IP 访问管理面板，状态页面保持公开
  • 启用双因素认证：Uptime Kuma 支持 TOTP 两步验证
  • 定期更新镜像：关注 GitHub Release，及时更新版本


1
2
3
4
5
6
7
8
# Nginx 层面限制管理面板访问

location /dashboard {

    allow 1.2.3.4;  # 你的 IP

    allow 5.6.7.8;  # 备用 IP

    deny all;

    proxy_pass http://127.0.0.1:3001;

    # ... 其他 proxy 配置

}

高可用方案

单实例部署对于个人和小团队已经够用。如果需要更高可用性：

  • 使用 Docker Swarm 或 Kubernetes 部署多副本
  • 将 SQLite 数据库迁移到外部 PostgreSQL
  • 前端使用负载均衡器分发流量

对于大多数站长，单实例 + 定期备份已经足够可靠。Uptime Kuma 本身的资源占用很低（通常不到 200MB 内存），运行在一台 512MB 的小鸡上完全没问题。

与现有监控体系的对比

下表对比了 Uptime Kuma 与常见监控方案的差异：

特性 Uptime Kuma UptimeRobot Prometheus + Grafana
自托管 是 否 是
免费监控数量 无限 50 个 无限
状态页面 内置 付费功能 需额外搭建
通知渠道 90+ 6 种 需 Alertmanager
资源占用 低（<200MB） N/A（SaaS） 高（2GB+）
上手难度 极低 极低 较高
数据所有权 完全自有 平台持有 完全自有

可以看到，Uptime Kuma 在自托管、免费、易用性之间取得了非常好的平衡。如果你不需要 Prometheus 那种深度指标采集，Uptime Kuma 就是最佳选择。

常见问题与排障

WebSocket 连接失败

如果仪表盘状态不实时更新、通知延迟，通常是 WebSocket 被阻断。检查：

  • Nginx/Cloudflare 是否正确配置了 WebSocket 代理
  • Cloudflare 需要在 DNS 设置中启用 WebSocket 支持（默认已启用）
  • 防火墙是否放行了 WebSocket 端口

通知发送失败

Telegram Bot 通知失败的常见原因：

  • Bot Token 错误（注意不要包含多余空格）
  • Chat ID 填成 Bot ID（需要填用户 ID）
  • Bot 未向目标用户/群组发送过消息（需先手动发一条）

容器频繁重启

如果 Uptime Kuma 容器反复重启，检查：



1
2
3
4
5
6
7
8
9
# 查看容器日志

docker logs uptime-kuma --tail 50



# 常见原因：

# 1. 数据目录权限问题

sudo chown -R 1000:1000 /opt/uptime-kuma/data



# 2. 端口冲突

ss -tlnp | grep 3001

更新到最新版本



1
2
3
4
5
6
# 拉取最新镜像并重启

cd /opt/uptime-kuma

docker compose pull

docker compose up -d



# 数据会自动迁移，无需额外操作

总结

Uptime Kuma 是目前最优秀的自托管监控方案之一。它用极低的资源开销提供了完整的可用性监控能力：多协议支持、90+ 通知渠道、内置状态页面、精美的 UI，加上完全免费和数据自主的天然优势。对于每一个在 VPS 上跑服务的站长来说，部署一套 Uptime Kuma 应该是服务器初始化的标准流程之一——在你还没出故障的时候就把监控配好，远比出了问题再手忙脚乱查日志要靠谱得多。

整个部署过程不超过 15 分钟：Docker 拉起来、Nginx 反代配上、加几个监控项、接上 Telegram 通知，从此你就能第一时间知道哪个服务出了问题。配合状态页面，你的用户也能实时看到服务健康状况，这才是专业运维该有的样子。

【本站文章皆为原创，未经允许不得转载】：汤不热吧 » VPS 上用 Uptime Kuma 自建服务状态监控面板：告别第三方依赖，打造专属可用性监控中心
分享到： 更多 (0)
标签：

相关推荐