您可以通过选择预安装的应用程序镜像,在VoyraCloud VPS上自托管Uptime Kuma,通过私有SSH隧道创建第一个管理员,然后为您操作的服务添加监控。该镜像提供了一个持久的Uptime Kuma起始点,而公共访问、受信任的HTTPS、通知、备份、更新、容量规划和事件响应仍然在您的控制之下。
TL;DR
- VoyraCloud Uptime Kuma应用程序镜像在Cloud VPS和住宅IP VPS上提供预安装的监控仪表板。
- 端口
3001默认绑定到127.0.0.1,因此请通过SSH隧道创建第一个管理员,而不是将未初始化的设置页面暴露到互联网。 - Uptime Kuma支持HTTP、HTTPS、TCP、ping、DNS、WebSocket、推送、关键字和JSON查询监控,以及项目文档中记录的其他监控类型。
- 公共仪表板或状态页面访问需要您自己的域名、支持WebSocket升级的反向代理和浏览器信任的HTTPS。
- 配置、用户、监控历史、通知和状态页面存储在本地持久存储的
/app/data下。重启持久性不是备份。 - 20个监控、60秒间隔的工作负载是镜像的初始验证配置,而不是无限监控的保证或测量您自己工作负载的替代品。
- 来自同一VPS的监控有一个重要的盲点:如果该VPS、其区域或网络路径发生故障,Uptime Kuma可能无法发送警报。
什么是Uptime Kuma?
Uptime Kuma是一个开源的自托管监控应用程序,用于检查网站、API、网络服务和您控制的其他可达端点。它记录检查结果和响应信息,呈现服务历史,并可以通过管理员配置的集成发送通知。
官方Uptime Kuma项目列出了对HTTP(S)、TCP、HTTP(S)关键字、HTTP(S) JSON查询、WebSocket、ping、DNS记录、推送和Docker容器监控等监控类型的支持。它还提供多个状态页面、证书信息、ping图表、双因素认证、代理支持和广泛的通知集成。
自托管在您希望时非常有用:
- 在您自己的服务器管理下的监控仪表板。
- 对监控配置、用户、历史和状态页面的控制。
- 检查多个网站、API或网络服务的简单方法。
- 连接您已经使用的通知提供商的选项。
- 可以在小型VPS上持续运行的监控工具。
以这种方式部署时,Uptime Kuma不是一个托管监控服务。您拥有VPS、访问控制、升级、备份、通知凭证和响应流程。您还必须决定一个监控位置是否能为您关心的服务提供足够的可见性。
如何开始使用VoyraCloud应用程序镜像?
自托管Uptime Kuma的最快方法是创建一个支持的VoyraCloud VPS,并通过本地SSH隧道完成第一次设置。您无需手动安装Uptime Kuma,但必须在配置监控之前安全地创建管理员。
- 打开VoyraCloud Uptime Kuma页面并继续进行VPS购买流程。
- 选择一个合格的Cloud VPS或Residential IP VPS计划,然后选择该产品当前提供的任何区域。
- 确认在镜像部分选择了Uptime Kuma,然后创建VPS。
- 等待VPS资源和应用程序准备就绪。
- 打开资源详细信息并找到应用程序部分。
- 复制显示的SSH隧道命令。它遵循以下模式:
ssh -p <ssh-port> -L 3001:127.0.0.1:3001 <ssh-user>@<server-ip>
7. 保持该SSH会话打开并浏览到:
http://127.0.0.1:3001
8. 完成官方Uptime Kuma设置页面并创建一个独特的管理员用户名和强密码。
9. 登录,创建一个测试监控,并确认检查出现在仪表板上。
10. 重启VPS一次,并验证Uptime Kuma自动返回,账户、监控和历史记录保持可用。
浏览器地址是本地的,但应用程序在VPS上运行。SSH通过加密连接将您的本地端口3001转发到服务器上的127.0.0.1:3001。关闭SSH会话将关闭隧道;它不会停止Uptime Kuma。
如果您的计算机已经使用本地端口3001,请选择另一个本地端口而不更改远程目标:
ssh -p <ssh-port> -L 33001:127.0.0.1:3001 <ssh-user>@<server-ip>
然后您可以在浏览器中打开http://127.0.0.1:33001。保持远程端为127.0.0.1:3001。
使用显示的SSH用户名和端口,而不是假设root和端口22。
应用程序镜像包含什么?
应用程序镜像包括一个预安装的持久Uptime Kuma实例,但它并不将VPS转换为托管监控服务。在计划生产使用时,以下边界非常重要。
| 由应用程序镜像提供 | 用户管理或未包含 |
|---|---|
| 为镜像批准的Uptime Kuma稳定版本 | 自动应用程序升级 |
| Cloud VPS或Residential IP VPS操作环境 | 托管服务器管理 |
| 正常VPS重启后的服务恢复 | 高可用性或自动故障转移 |
仅在127.0.0.1:3001上的本地访问 | 公共端口3001暴露 |
| 官方的首次管理员设置流程 | 预创建的管理员或固定密码 |
持久的本地/app/data存储 | 自动离线备份 |
| 监控仪表板、历史记录、通知和状态页面功能 | 预配置的第三方通知账户 |
| 资源详细信息中的SSH隧道说明 | 域名注册、反向代理或受信任的HTTPS |
| 用户控制的监控配置 | 保证检测准确性或警报传递 |
| 根据其开源许可证的Uptime Kuma | VoyraCloud在交付后维护Uptime Kuma |
该镜像不包括固定的管理员凭证、无认证模式、通知密钥、域名、证书或公共管理端点。这保持了首次访问的私密性,并避免将未初始化的账户创建页面直接放置在互联网上。
您应该使用哪些监控类型?
根据您需要测试的层选择每种Uptime Kuma监控类型,因为成功的ping并不能证明网站、API或应用程序正常工作。一个有用的监控集检查用户面层和选定的依赖项,而不是依赖于一个通用的心跳。
| 监控类型 | 它可以验证什么 | 重要限制 |
|---|---|---|
| HTTP或HTTPS | 一个URL响应并返回预期状态 | 成功的响应仍可能包含不正确的内容 |
| 关键字 | 响应包括或排除预期文本 | 文本检查并不能验证每个业务功能 |
| JSON查询 | API响应包含预期值 | 查询必须与真实响应结构匹配 |
| TCP端口 | 网络服务接受连接 | 开放端口并不能证明应用程序是健康的 |
| Ping | 主机响应ICMP | ICMP可能被过滤,响应并不能证明应用程序正常工作 |
| DNS记录 | 解析器返回预期记录 | 一个解析器视图可能无法代表全球传播 |
| WebSocket | 可以访问WebSocket端点 | 它并不能验证每个消息流 |
| 推送 | 作业或远程进程报告其自己的心跳 | 缺少推送需要为该作业设计的警报窗口 |
| 证书信息 | 证书状态和到期信息 | 续订仍然取决于您的证书流程 |
对于公共网站,一个实用的集合可能包括HTTPS检查、关键字或JSON检查以获取有意义的内容,以及证书到期检查。对于从VPS可达的内部服务,TCP或HTTP检查可以增加基础设施可见性。对于计划作业,推送监控可以检测预期的心跳未到达时。
避免创建多个因相同原因而失败的监控,然后将它们视为独立证据。监控设计应反映真实的故障模式:DNS、TLS、网络可达性、应用程序响应、内容正确性和后台作业完成。
20个监控验证配置意味着什么?
20个监控配置是初始镜像配置的保守接受工作负载,而不是最大容量的承诺。计划的验证使用20个监控,每60秒一次,持续24小时,然后重启VPS并进行持久性检查。
该验证旨在回答一个狭窄的问题:合格的入门配置是否可以在定义的工作负载下运行一个小型Uptime Kuma安装,而不会出现内存不足事件、数据库锁定、意外容器重启或数据丢失?它并不能证明相同的计划可以支持:
- 无限监控。
- 非常短的检查间隔。
- 大型响应体或昂贵的JSON查询。
- 许多并发用户或公共状态页面访问者。
- 长时间保留而不增长存储。
- 大量通知流量。
- 具有访问主机套接字的Docker监控。
- 共享同一VPS的其他应用程序。
实际资源使用取决于监控类型、间隔、超时、响应大小、历史保留、通知行为、仪表板活动和服务器上的其他软件。从一个经过测量的集合开始,观察CPU、内存、磁盘使用、数据库行为和检查持续时间,然后在实际工作负载需要时转向更大的合格VoyraCloud VPS配置。
不要将购买流程的最低要求解释为普遍的规模建议。它是经过验证的起始配置的资格门槛。
如何安全地发布Uptime Kuma?
通过专用域名或子域名、支持WebSocket的反向代理和浏览器信任的HTTPS发布Uptime Kuma,同时保持端口3001绑定到localhost。当只有管理员需要仪表板且不需要公共状态页面时,长期SSH隧道访问也是有效的。
官方Uptime Kuma反向代理指南解释了该应用程序使用WebSocket,并要求代理传递Upgrade和Connection头。它还指出,Uptime Kuma不支持在正常URL子目录下托管,例如/uptime-kuma;请使用专用主机名,例如status.example.com。
一个典型的Nginx位置块包括:
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
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 Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
这个代码片段仅涵盖代理路径。您必须单独配置主机名、受信任的TLS证书、证书续订、HTTP到HTTPS的重定向、防火墙和访问策略。在应用之前,请验证您选择的反向代理的当前官方示例。
使用此生产检查清单:
- 为专用主机名创建DNS记录。
- 保持
3001/tcp在公共互联网不可用。 - 配置反向代理以访问
127.0.0.1:3001。 - 保留WebSocket升级头。
- 安装浏览器信任的证书。
- 将普通HTTP重定向到HTTPS。
- 确认仪表板在没有WebSocket错误的情况下更新。
- 测试登录、注销、监控更新和状态页面。
- 在不需要公共访问时限制管理主机名。
- 仅在代理和防火墙路径正确后审查受信任的代理设置。
受信任的HTTPS在传输中保护凭证和会话流量,但它并不能保护弱管理员密码或过时的服务器。保持SSH的安全,限制权限,在适当的地方启用双因素认证,并维护操作系统和反向代理。
通知和状态页面如何工作?
通知和状态页面是您在初始化后配置的功能;该镜像不包括第三方账户、凭证、交付保证或公共域名。Uptime Kuma支持多种通知方法,但每个提供商都有自己的账户、可用性、定价、限制和交付行为。
官方通知方法文档提供了特定于提供商的设置参考。仅添加您的团队拥有的集成,仔细存储凭证,并在依赖它们之前发送测试通知。成功的测试证明那一刻一条消息有效;它并不保证未来的交付。
对于每个重要监控:
- 决定谁应该接收警报。
- 设置适合该服务的检查间隔和重试策略。
- 配置一个或多个用户拥有的通知方法。
- 测试故障和恢复通知。
- 确认值班人员可以对消息采取行动。
- 记录监控报告故障时该做什么。
状态页面允许您共享选定的监控状态和事件信息。它们不需要暴露每个内部监控。以客户理解的方式对服务进行分组,避免发布敏感的主机名或内部拓扑,并使用您自己的域名和安全的代理路径进行公共访问。
不要假设每个通知集成都免费。一些服务可能会收费、限制使用、改变其API或需要额外配置。VoyraCloud不提供这些第三方账户,也无法保证提供商接受或传递消息。
Uptime Kuma数据如何存储和备份?
Uptime Kuma将其应用状态保存在/app/data下,该位置必须保留在持久本地存储上,并且必须与运行中的VPS单独备份。官方安装指导要求文件系统支持POSIX文件锁,并警告与NFS常见的文件锁定问题。
持久数据包括数据库和应用状态,所需项目包括:
- 管理员和用户设置。
- 监控定义。
- 监控历史。
- 通知配置。
- 状态页面。
- 维护计划。
- 其他实例设置。
正常的VPS重启应保留该数据并重启应用程序。该行为是持久性,而不是灾难恢复。意外删除、数据库损坏、凭证泄露、升级失败、存储丢失或VPS删除仍可能删除唯一副本。
更安全的备份例程是:
- 识别实际的本地Docker卷或映射到
/app/data的本地目录。 - 将备份调度到VPS外的目标。
- 在所选备份方法需要一致的数据库副本时,暂停或停止Uptime Kuma。
- 复制完整的数据集,而不仅仅是导出的监控列表。
- 加密并保护备份,因为它可能包含操作细节和通知凭证。
- 保留多个恢复点。
- 恢复到单独的测试实例并验证账户、监控、历史、通知和状态页面。
- 记录与备份相关的应用版本。
不要将活动的/app/data目录放在NFS上。远程备份目标适合复制的备份工件;它与直接在网络文件系统上运行活动数据库不同。
同一服务器监控的盲点是什么?
Uptime Kuma实例无法可靠地报告也会移除其自身计算、网络或通知路径的故障。如果Uptime Kuma在与其监控的网站相同的VPS上运行,则VPS故障可能会在发送警报之前停止网站和监控。
即使被监控的服务在另一台服务器上,一个Uptime Kuma位置仍然从一个网络和一个区域观察它。一个本地ISP路由、区域网络问题、DNS解析器差异或防火墙策略可以影响该视图,而不代表每个用户的体验。
根据后果使用部署:
| 监控需求 | 适当的方法 |
|---|---|
| 小型服务的方便仪表板 | 一个自托管的Uptime Kuma实例可能足够 |
| 监控另一台VPS上的服务 | 在实际情况下将Uptime Kuma放置在被监控服务器的故障域外 |
| 检测区域可达性差异 | 使用来自多个位置的独立检查 |
| 在监控VPS故障时发出警报 | 添加外部心跳或独立监控服务 |
| 高可用性监控 | 设计一个独立的多系统监控架构 |
应用程序镜像不提供分布式监控、高可用性或独立的外部检查。将其视为一个监控点,并在错过的警报可能对业务产生重大影响时添加独立覆盖。
您应该如何更新Uptime Kuma?
通过检查官方发布指导、备份/app/data和验证新版本,在更新Uptime Kuma时要谨慎。VoyraCloud在创建VPS后不会自动升级客户实例。
遵循适用于已安装主要版本和部署方法的官方Uptime Kuma更新指导。在更新之前:
- 阅读发布说明和迁移要求。
- 记录当前运行的应用版本。
- 创建并验证
/app/data的离线备份。 - 确认有足够的可用磁盘空间。
- 为重要的监控实例计划维护窗口。
- 使用特定的批准版本,而不是未经审查的浮动标签。
- 启动更新的实例并查看其日志。
- 测试管理员登录、几种监控类型、通知、状态页面和重启恢复。
- 保持与发布说明中描述的数据库更改兼容的回滚计划。
不要假设还原容器镜像总是足够的。主要版本迁移可能会更改应用数据,因此恢复可能需要预更新的数据备份以及早期的镜像版本。
操作系统更新、Docker更新、反向代理更新和证书续订是单独的责任。当前的Uptime Kuma容器并不会使服务器的其他部分保持最新。
常见错误
大多数Uptime Kuma部署错误来自于暴露初始化、过高估计一个监控位置或将持久存储视为完整的操作计划。避免这些错误:
- 在创建管理员之前发布端口
3001。保持在localhost上并使用SSH隧道。 - 将仪表板留在公共HTTP上。对任何公共访问使用受信任的HTTPS。
- 忘记WebSocket代理头。界面可能加载但无法正确更新。
- 在子目录下托管。使用专用域名或子域名。
- 在NFS上运行活动的
/app/data。保持在兼容的本地存储上。 - 将重启持久性称为备份。将经过测试的副本存储在VPS外。
- 假设状态页面创建独立监控。它由同一Uptime Kuma实例呈现。
- 仅从自身监控VPS。完整的服务器故障可能会使服务和监控都沉默。
- 将20个监控视为保证的最大值或最小值。这是一个定义的验证工作负载,而不是普遍的容量结果。
- 期望通知交付得到保证。提供商的可用性、凭证、配额、路由和监控主机都很重要。
- 启用每个集成而没有所有者。仅配置有人测试和响应的渠道。
- 在没有可恢复数据副本的情况下更新。在更改版本之前备份完整的应用数据。
常见问题解答
我可以在不手动安装的情况下自托管Uptime Kuma吗?
可以。VoyraCloud应用程序镜像在合格的Cloud VPS或Residential IP VPS上提供预安装的Uptime Kuma实例。您仍需创建第一个管理员,添加监控,配置通知,并管理安全性、更新、备份和公共访问。
为什么显示http://127.0.0.1:3001而不是服务器IP?
本地地址防止未初始化的管理员设置页面直接暴露到互联网。从您的计算机建立SSH隧道,保持会话打开,然后浏览到本地URL。隧道安全地将您的浏览器连接转发到VPS上的Uptime Kuma。
我可以将端口3001直接暴露到互联网吗?
直接暴露不是推荐的生产路径。保持服务绑定到localhost,并使用具有专用主机名、WebSocket支持、受信任HTTPS和适当访问策略的反向代理。应用程序镜像不会自动配置该公共路径。
Uptime Kuma是否包括免费的SMS、电子邮件、Slack或其他通知服务?
不。Uptime Kuma可以与许多通知提供商集成,但您需要提供和管理提供商账户和凭证。第三方定价、配额、可用性和消息交付在应用程序镜像之外,可能会发生变化。
1 GB的VPS足够Uptime Kuma吗?
它可能仅在定义的镜像验证通过后成为合格的起始点,但实际容量取决于您的工作负载。初始配置使用20个监控,每60秒一次,持续24小时。更多监控、更短间隔、更大响应、更长历史、额外服务或更重的仪表板使用可能需要更多内存、CPU和存储。
Uptime Kuma提供高可用性或外部监控吗?
不。该镜像提供一个自托管的Uptime Kuma实例在一个VPS上。高可用性、分布式检查和独立外部监控需要额外的系统和架构,这些不包括在内。
如果Uptime Kuma自己的VPS失败,它会提醒我吗?
可能不会,因为发送警报的过程可能会与VPS或其网络路径一起失败。当检测Uptime Kuma主机故障很重要时,请使用外部心跳或独立监控位置。
我必须备份什么?
备份映射到/app/data的完整持久数据,并将恢复副本存储在VPS外。保护备份,因为它可能包含监控配置和通知密钥,并测试恢复,而不是假设复制的文件集是可用的。
VoyraCloud会自动更新Uptime Kuma吗?
不。新的VPS资源在创建时接收为镜像批准的应用版本,而后续更新由客户管理。查看官方升级说明,备份/app/data,并在依赖更新的实例之前测试它。
结论
当您想要一个简单的监控仪表板、可配置的检查、通知和状态页面时,自托管Uptime Kuma在您自己的管理之下。通过SSH隧道私下开始,围绕真实故障模式设计监控,将/app/data保留在持久本地存储上,在VPS外备份,并仅在需要公共访问时添加支持WebSocket的反向代理和受信任的HTTPS。
一个实例对于许多小型监控需求是有用的,但它仍然是一个观察点,具有一个故障域。当Uptime Kuma主机本身、区域可达性或警报连续性也必须得到覆盖时,请添加独立监控。
使用VoyraCloud Uptime Kuma应用程序镜像从预安装的VoyraCloud VPS环境开始,同时保持访问、数据、通知和操作在您的控制之下。

