Uptime Kuma 应该放哪台机器？

把 Uptime Kuma 和所有业务服务放在同一台机器上，面板很好看，但整机宕机时它也一起消失。可用性监控最重要的是"从外面看见问题"。本文讲监控机怎么选、哪些目标要监控、通知怎么设置。

摘要：适合有多个网站或自托管服务的人，目标是搭一个真正能报警的外部监控。

适合场景和不适合场景

适合：

个人站长和小团队
多个自托管服务需要状态页
需要 HTTP/TCP/Ping 和通知渠道的人

不适合：

严肃企业级监控替代品
只看服务器 CPU 内存的场景
所有服务都在内网且没有外部入口

这一步要先讲清楚，是因为很多服务器教程只告诉你"怎么装"，却不告诉你"该不该装"。如果场景不匹配，后面配置写得再漂亮，也只是把问题推迟到上线之后。

配置和成本怎么取舍

Uptime Kuma 很省资源，1 核 2G 足够监控几十个目标。更重要的是部署位置：最好放在和业务不同的服务器、不同地域或不同运营商，这样更容易发现外部访问问题。

我会把 Uptime Kuma 放在 雨云服务器 rainyun-com 的 1 核 2G 机型上，监控几十个 HTTP、TCP、Ping 目标很轻松。注册填优惠码 2026off 领 5折，这类配置更适合先稳定跑起来，再按真实负载升级。

准备工作

准备一台干净的 Ubuntu 22.04 或 Debian 12 服务器，先确认 SSH、时间同步和防火墙状态。
规划目录：/opt/uptime-kuma-monitor-from-outside-20260601。配置、数据、备份脚本都放在同一主题目录下，后面迁移更省事。
根据主题放行端口：3001/tcp。游戏和网络服务尤其要分清 TCP/UDP。
先用测试数据跑通，再导入正式数据或邀请其他人使用。

核心配置

下面配置用于说明关键项，发布前要按当前官方文档确认镜像版本、环境变量和端口。

yaml 复制代码

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

如果需要 HTTPS，可以让应用只监听本机端口，再用 Caddy 反代：

Caddyfile 复制代码

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

怎么确认真的可用

添加一个 HTTP 目标、一个 TCP 端口和一个故意不存在的测试目标，确认通知渠道真的能收到恢复和故障提醒。

验证时不要只看进程是否存在，至少完成一次真实动作：游戏服要让外部玩家连接，应用要登录并写入一条数据，运维项要确认状态变化真的生效。这样能提前发现端口、权限、反代和路径问题。

踩坑清单

监控频率不要全设成 20 秒。目标多了会增加请求压力，也容易因为网络抖动制造误报。普通站点 60 秒或 120 秒已经够用。

排查建议按这个顺序来：

看日志里第一条明确错误，不要只看最后一屏。
查端口监听和云安全组，确认协议没有写错。
检查数据目录权限，尤其是容器用户和宿主机目录映射。
回滚到上一个能工作的配置，再逐项恢复新改动。

备份、升级和迁移

备份 data 目录即可保留监控项、通知渠道和状态页配置。

维护时建议保留一份"最小恢复说明"：需要哪些文件、恢复命令是什么、域名和端口在哪里改。等真正出问题时，人通常没那么冷静，清单比记忆可靠。

总结

监控系统不需要很重，但它必须站在业务外面看业务。