Uptime Kuma 在 DigitalOcean 上自托管指南 2026

Uptime Kuma 是一个热门的开源监控工具，用于自托管而不是支付 UptimeRobot 等 SaaS 服务的费用，因为你完全控制数据，可以运行无限数量的监控。本指南将指导你选择合适的 Droplet 大小、使用 Docker 安装、配置第一个监控、设置告警以及为生产环境创建公共状态页面。

什么是 Uptime Kuma 以及它与 DigitalOcean 监控的区别

Uptime Kuma 是一个用 Node.js 和 Vue.js 编写的自托管监控软件，开源供任何人在自己的服务器上免费运行。它的主要职责是持续检查网站、API 或其他服务的状态，检查间隔设置为一定的时间，并在出现问题时发送告警。突出的特点是在一个应用程序中支持许多监控类型：HTTP(s)、TCP Port、Ping、DNS Record、Docker Container、gRPC、Push（用于带死人开关的 cron 作业）以及 Keyword/JSON Query 来检查特定内容是否完全按预期出现在网页或 API 响应中。由于它运行在你自己的服务器上，除了你的 Droplet 资源外，监控的数量没有限制。同时，DigitalOcean 本身为 Droplet 免费提供内置的监控功能，涵盖 CPU、内存、磁盘和磁盘 I/O 等指标的收集，并包含告警策略。它还为每个账户提供 1 个免费的正常运行时间检查来验证端点（如你的主要网站）是否仍在响应。优点是不需要额外的设置或服务器管理，但限制是每个账户只有 1 个免费检查。如果你需要同时监控多个端点、想要自己的品牌状态页面或需要更多的告警渠道，自托管 Uptime Kuma 更合适，尽管这样做需要承担维护和保护自己的 Droplet 的负担。简而言之，它们不是直接竞争关系，而是相互补充。例如，你可以使用 DO 的免费正常运行时间检查来监控 Uptime Kuma 实例本身，防止当 Droplet 崩溃时无法发送告警的"谁监控监控者"问题。

• Uptime Kuma：自托管，监控数量不限制（在 Droplet 资源范围内）
• DO 监控：免费内置，无需设置，但每个账户只有 1 个免费正常运行时间检查
• Uptime Kuma 支持多种监控类型：HTTP(s)、TCP、Ping、DNS、Docker、gRPC、Push、Keyword/JSON Query
• 可以一起使用：利用 DO 的免费正常运行时间检查来监控运行 Uptime Kuma 的 Droplet 本身，防止单点故障

使用 Docker 部署

首先你需要一个 Droplet 来运行 Uptime Kuma。对于只有几十个监控的初学者，基础共享 CPU 包（1 GiB RAM / 1 vCPU / 25 GB SSD / 1,000 GiB 传输，$6/月）已经足够舒适，因为 Uptime Kuma 不消耗太多 RAM，并使用 SQLite 作为其内置数据库。如果你想省钱，512 MiB 的包（$4/月）也可以运行，但同时打开许多监控会很紧张。对于泰国用户，我们建议 sgp1（新加坡）区域具有最低的延迟，blr1（班加罗尔）作为备选方案。创建 Droplet 后，SSH 进入并安装 Docker（创建 Droplet 时可以选择"Docker on Ubuntu"市场镜像，或稍后通过 apt 自己安装），然后运行一个命令启动 Uptime Kuma：docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 这个命令创建一个名为 uptime-kuma 的容器，暴露端口 3001，重要的是附加一个名为 uptime-kuma:/app/data 的卷来持久化 SQLite 数据库，与容器分开存储，这样删除和重新创建容器时数据不会消失。如果你更喜欢用 docker compose 管理，创建一个包含这个单一服务的 docker-compose.yml 文件，然后用 docker compose up -d 运行它。容器运行后，配置 DigitalOcean 的 Cloud Firewall（免费使用，无需额外费用）只打开端口 22（SSH）、80/443（用于反向代理），并从外部互联网阻止端口 3001。然后设置 Nginx 作为指向 127.0.0.1:3001 的反向代理，并使用 Certbot 为指向 Droplet 的域名颁发免费 SSL 证书，这样你只能通过 HTTPS 访问仪表板，不会通过端口 3001 直接以明文方式发送密码。

• 推荐 $6/月 Droplet（1 GiB RAM、1 vCPU、25 GB SSD、1,000 GiB 传输）用于典型使用
• 区域 sgp1（新加坡）对泰国用户延迟最低，其次是 blr1（班加罗尔）
• 主要命令：docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

配置网站/API 监控

首次通过配置的域名访问仪表板时，系统会要求你先创建一个管理员账户（设置一个强密码，因为这控制所有的告警）。然后点击"添加新监控"开始添加你想要监控的项目。最常用的监控类型是 HTTP(s)，用于检查网站或 API 端点是否以正确的状态进行响应。输入目标 URL，设置心跳间隔（检查的频率，如每 60 秒），重试次数（允许的失败次数，然后才将其视为真正的停机，以防止来自短暂网络中断的误报），以及重新发送通知的频率（当仍然连续停机时要重新告警的频率）。对于需要检查状态代码之外的更深层内容的 API，使用 Keyword 类型来搜索响应中的特定文本，或使用 JSON Query（在较新版本中可用）来验证 JSON 响应字段，例如检查 status 字段是否等于 ok，而不仅仅是检查 HTTP 200。对于 TCP Port，监控数据库或后端服务端口是否接受连接。Docker Container 监控让你直接通过 Docker socket 监控同一机器上的其他容器。如果你有很多监控，可以使用 Group 功能或 Tags 来组织它们，以便随着数量增加而更容易管理，例如分离 Production 和 Staging 或按团队职责。你还可以启用 Upside Down Mode 来翻转告警逻辑以应对特殊情况，例如监控维护模式以确保它不会保持太长时间。

• 主要监控类型：HTTP(s)、TCP Port、Ping、DNS、Docker Container、Keyword、JSON Query、Push
• 适当设置心跳间隔和重试次数，以减少由短暂网络中断引起的误报
• 使用 Keyword/JSON Query 检查实际响应内容，而不仅仅是 HTTP 状态代码

通过 Telegram/Email/Line Notify 发送告警

进入 Settings > Notifications 来设置告警渠道，可以独立绑定到每个监控。对于 Telegram，通过 Telegram 应用中的 BotFather 创建新机器人，输入 /newbot，给它一个名字，你将收到一个 Bot Token。然后找到你希望告警发送到的组或账户的 Chat ID（通过 Telegram API 或辅助机器人如 @userinfobot），然后将 Bot Token 和 Chat ID 输入到"添加通知"页面，选择 Telegram 类型，点击"测试"以确认消息到达后再保存。对于 Email，使用 SMTP 类型并输入你的电子邮件提供商的主机、端口、用户名、密码（如 Gmail 应用密码或你的域名提供商的 SMTP 中继），然后设置发送者和收件人地址。这对于非紧急告警或摘要很有用。至于许多人知道的 LINE Notify，重要的是要澄清 LINE 宣布在 2025 年 3 月 31 日关闭 LINE Notify，所以这个选项在 2026 年不再有效。替代方案是通过你自己的 LINE 官方账户使用 LINE Messaging API，设置 Webhook 并让 Uptime Kuma 通过 Webhook 类型发送告警，或使用 Apprise（Uptime Kuma 原生支持），它可以与 LINE Messaging API 和数十种其他通知服务集成，包括自定义集成。你应该至少设置两个渠道一起工作，例如 Telegram 作为主渠道，Email 作为备份，这样如果一个渠道出现问题，你就不会错过告警。

1. Telegram：通过 BotFather 创建机器人以获取 Bot Token，与 Chat ID 配对，保存前点击测试
2. Email：使用 SMTP 类型，输入你的电子邮件提供商的主机/端口/用户名/密码
3. LINE Notify 服务在 2025 年 3 月 31 日关闭，不再可用
4. LINE Notify 替代方案：通过 Webhook 使用 LINE Messaging API 或使用 Apprise，Kuma 原生支持
5. 至少设置 2 个渠道一起工作以避免错过告警

创建公共状态页面

Uptime Kuma 具有内置的状态页面功能来创建一个公开网页，显示服务状态，无需单独的服务。进入 Status Pages 菜单并点击"新建状态页面"，设置名称，为 URL 设置一个 slug（如 /status/production），然后拖动你想要显示的监控并按类别（如"网站"、"API"、"数据库"）进行组织。状态页面显示当前状态、历史正常运行时间百分比以及心跳历史作为条形图，用于快速概览。自定义外观，包括主题、徽标、描述，并根据需要切换显示/隐藏响应时间数字。如果你想要事件历史，从同一页面添加带有进度更新的公告。为了获得信誉，我们建议使用子域名而不是路径，如 status.example.com，通过设置指向你的 Droplet IP 的 DNS A 或 CNAME 记录，然后在 Nginx 中添加一个专门针对这个域名的新服务器块来代理到你的状态页面路径，并通过 Certbot 为其颁发单独的 SSL 证书。子域名上的状态页面的优点是，即使主仪表板通过 Cloud Firewall 限制到特定 IP，它也保持可访问，因为你可以配置 Nginx 只公开状态页面路径，同时将管理仪表板限制在你的团队 IP。

• 通过 Status Pages > New Status Page 创建，设置 slug，拖动监控按类别组织
• 显示历史正常运行时间百分比、心跳历史，并自定义主题/徽标
• 添加事件来公告事件并向用户更新进度

何时使用此功能（真实用例）

Uptime Kuma 适合 DO 的 1 个免费正常运行时间检查不足的情况，如团队同时管理多个服务——主网站、API、数据库、工作队列或多个微服务——需要按点的单独监控而不仅仅是知道"网站停机"的单一概览。另一个情况是为了获得客户想要的他们自己的品牌状态页面的透明度，而不是在事件期间由客户联系的团队。公共状态页面显著减少了支持负担并展示了专业精神。它还适合那些需要比 DO 监控支持的更多元化告警渠道的人，例如想要在 Telegram 团队组、Discord、Slack 或 webhook 中发送告警到你的内部系统的人，这是 DO 监控没有为之设计的。从成本角度来看，与按监控收费的商业监控 SaaS 相比是值得的，因为单个 $6/月 Droplet 可以处理数十到数百个监控，成本固定。相反，如果你只有一个网站或端点要监控，并且不想要服务器管理的开销，现有的 DO 监控和免费正常运行时间检查就足够了。在决定之前，权衡你获得的灵活性与所增加的维护负担。

• 多个服务/端点需要单独监控，超过 DO 的 1 个免费检查
• 想要你自己的品牌状态页面供客户使用，减少支持负担
• 需要多元化的告警渠道如 Telegram、Discord、Slack、Webhooks
• $6/月固定成本在处理许多监控时击败按监控计费的 SaaS
• 如果只有 1 个端点且不想要服务器管理的开销，DO 监控免费选项足够

常见错误及其修复方法

用户经常问到的一点是：最常见的错误是直接向互联网暴露端口 3001，没有反向代理和 SSL，所以登录密码通过网络以明文发送。修复：在 Cloud Firewall 关闭端口 3001，然后如部署部分所述只通过 HTTPS 通过 Nginx 访问。另一个常见问题是运行容器时忘记附加卷，所以当你更新或删除/重新创建容器时，所有监控和通知数据都会消失。预防：始终在每个 docker run 命令中包含 -v uptime-kuma:/app/data，并定期备份这个文件夹，例如 docker run --rm -v uptime-kuma:/app/data -v $(pwd):/backup busybox tar czf /backup/kuma-backup.tar.gz /app/data。下一个问题是设置心跳间隔太频繁，没有必要，例如对于已经稳定的网站每 10 秒，浪费 Droplet 资源并不必要地增加监控端点的负载。根据服务的关键性设置：关键 API 可能是 30-60 秒，而次要服务可能是 5 分钟。另一个经常被忽视的点是没有人监控 Uptime Kuma 本身，它运行在与它监控的服务相同的 Droplet 上，所以如果 Droplet 崩溃，就不会发送告警。修复：使用 DO 的免费正常运行时间检查来监控 Uptime Kuma URL 本身作为额外的层。最后，将镜像标签卡在 :1 而不更新会错过重要的安全补丁。设置定期检查并使用 docker compose pull && docker compose up -d 更新。

1. 端口 3001 在没有 SSL 的情况下直接暴露：在 Cloud Firewall 关闭，然后使用反向代理 + HTTPS
2. 忘记附加卷：重新创建容器时数据消失，总是包含 -v uptime-kuma:/app/data
3. 心跳间隔太频繁：浪费资源并不必要地加载端点
4. 没有人监控 Uptime Kuma 本身：使用 DO 免费正常运行时间检查作为额外的层
5. 镜像标签卡在无更新：错过安全补丁，定期拉取更新

最佳实践

从仪表板安全开始：在创建管理员账户后立即在 Settings > Security 中启用双因素认证 (2FA)，因为这控制所有的告警和监控数据。将其与仅通过 Nginx allow/deny 或 DO 的免费 Cloud Firewall 将仪表板访问限制到团队 IP 结合。对于备份，设置 cron 作业来定期备份 /app/data 文件夹，可能将备份发送到 Droplet 外部以防止完全的 Droplet 故障，或添加另一层 DO Droplet 快照来定期捕获完整的机器状态。对于版本控制，我们建议明确固定镜像标签，如 louislam/uptime-kuma:1.23.16 而不仅仅是 :1，这样你可以控制何时更新，在生产环境之前先在暂存 Droplet 上测试，以防止破坏性变化。对于组织，从一开始设置有意义的名称和标签，因为当监控数量达到数十或数百个时，良好的分组在紧急情况下可以节省故障排除时间。对于系统内的 cron 作业或后台任务，使用 Push 监控类型而不是常规 HTTP，因为它是一个死人开关，其中作业本身必须发送心跳以说"仍在运行"；缺少心跳立即发出信号表示有问题，适合没有外部端点的作业。最后，当监控数量和用户增加到你的 Droplet 资源变得紧张的程度时，考虑升级到 $12/月 包（2 GiB RAM、1 vCPU、50 GB SSD、2,000 GiB 传输），它可以处理更高的负载，同时保持成本效益。

1. 创建管理员账户后立即启用 2FA 并通过 Cloud Firewall（免费）将仪表板访问限制到团队 IP
2. 定期备份 /app/data 文件夹并使用 Droplet 快照来捕获完整的机器状态
3. 明确固定镜像标签如 louislam/uptime-kuma:1.23.16 而不仅仅是 :1
4. 对 cron/后台作业使用 Push 监控类型作为死人开关
5. 当监控增加且资源变得紧张时，升级到 $12/月 Droplet（2 GiB RAM、1 vCPU、50 GB SSD）

领取 $200 免费额度 →