高颜值开源监控工具Uptime Kuma：5分钟搭建网站可用性监控

前阵子帮朋友梳理服务器监控，装完某款“企业级”开源监控之后，我直接想关掉页面——功能确实全，但满屏表格和灰扑扑的配色，别说日常巡检，连接受都有点难。后来我把手上站点全部迁移到另一套方案，也就是中文圈子里被叫成“酷监控”的项目 Uptime Kuma。它开源免费，界面走现代卡片设计，部署只要一条 Docker 命令，解决的问题却非常直接：网站是否在线、API 是否可用、端口通不通、证书还有没有救，以及一旦出故障能不能立刻通知到我。这类工具对个人站长、小团队和 HomeLab 玩家尤其友好，不想为几个服务去硬啃一套重量级监控平台的话，它应该是目前最接近“装完就能用”的选项。

1. 为什么我会选这类“高颜值”监控工具

1.1 颜值不是摆设，是监控效率的一部分

很多人觉得监控工具界面无所谓，能出告警就行。这话放到半夜三点被叫醒看故障的时候，你会发现完全不是那么回事。一个面板如果一眼望去全是表格线、编号和指标码，人的大脑需要花时间解码，等看清楚是哪个服务挂了，可能又过去几十秒。而高颜值的监控面板通常用大卡片、状态颜色和响应时间图形来组织信息，绿色健康、黄色异常、红色宕机，扫一眼就能定位问题。

我还发现一个现实问题：监控疲劳。告警配得越多，越容易麻木。但如果日常打开面板本身是舒适的，团队巡检意愿会明显更高。说白了，界面有设计感不是虚荣，而是减少了“看监控”这件事的摩擦。Uptime Kuma 的仪表盘把分组、状态、响应时间和事件历史整合在卡片布局里，信息密度和可读性平衡得不错，这也是我向很多朋友推荐它的第一原因。

1.2 它和 Zabbix、Prometheus 那类平台根本不是一回事

Zabbix 或 Prometheus + Grafana 是给复杂基础设施和大团队用的，能采集 CPU、内存、磁盘、日志和调用链数据，能力很香，代价是部署、维护、告警规则都要花不少功夫。可对多数个人站点和业务后台，我真正需要的不是几百个指标，而是“我的服务现在是否可用，挂了能不能告诉我”。这就是轻量监控工具的主场。

Uptime Kuma 这类工具的核心定位是可用性监控和状态展示。它支持 HTTP(S)、TCP 端口、Ping、DNS 等协议，靠定期发起请求来探测服务状态，把结果存在内嵌 SQLite 数据库里，整个应用封装成一个 Node.js 服务，资源占用很低。我用一台 1 核 1G 的云主机跑它，同时监控二十多个目标，CPU 和内存都波澜不惊。

需要注意它的边界在哪里。如果你要追踪业务接口的 P95 延迟、分析 JVM 堆内存、采集 K8s 集群指标，那它不合适，右转 Prometheus 加 Grafana。可如果只是想要一个“我自己和团队看得懂、愿意看”的可用性面板，这套高颜值工具是效率最高的选择之一。把合适的工具用在合适的场景，才算真的会选型。

2. 5分钟跑起来：从 Docker 部署到反向代理

2.1 准备一台能长时间运行的机器

安装本身没有什么门槛，但既然做监控，监控进程必须稳定，建议选一台长期在线的机器。云服务器、NAS、软路由盒子、树莓派都可以，只要支持 Docker。我用的是腾讯云轻量服务器，系统 Ubuntu 22.04，Docker 与 Docker Compose 插件都装好了。如果你手头机器还没装 Docker，直接按官方文档处理，几分钟就能完成。

端口规划上，服务默认监听 3001 端口。如果只有一台机器跑多个 Docker 应用，可以换一个高位端口避免冲突，比如 3001、4001 都行。我是通过 Nginx 反代绑定了域名并加了 HTTPS，这样无论是管理后台还是对外状态页，访问起来都正规不少，部分浏览器特性也更友好。

2.2 一条命令完成部署

启动容器的命令很简单，我实际用的版本是这样：

bash复制docker run -d \
  --name uptime-kuma \
  --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

解释一下每个参数：-d 表示后台运行；--restart=always 保证服务器重启后容器自动拉起，这一步是做监控服务的基本素养；-p 3001:3001 把宿主机 3001 端口映射到容器内；-v uptime-kuma:/app/data 创建名为 uptime-kuma 的 Docker 卷，所有配置、用户和监控数据都存在这里面，后续升级不丢数据。

如果你习惯用 Compose，保存下面的 docker-compose.yml：

yaml复制services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma:/app/data

然后执行 docker compose up -d 即可。部署完成后，浏览器访问 http://服务器IP:3001，第一件事是创建管理员账号。这里提醒一句，密码不要偷懒，因为这个后台能控制你所有服务的监控与告警，权限不小。

2.3 用 Nginx 反代并套上 HTTPS

直接裸奔 IP 访问 3001 端口，既不美观也不够安全。我自己的做法是把 3001 端口只监听内网地址，然后用宿主机上的 Nginx 反代到域名。核心配置如下：

nginx复制server {
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
    }
}

务必保留 Upgrade 和 Connection 两行，Uptime Kuma 的页面会通过 WebSocket 实时推送状态变化，反代不支持 WebSocket 升级的话，前端会一直转圈或者状态不刷新。HTTPS 证书我用 Let’s Encrypt 申请，再用 cron 自动续期，整条链路就很省心了。之后浏览器访问 https://status.example.com，功能完全正常。

2.4 完成基础配置

首次登录后，在设置里可以切换语言、选择主题和配色。界面内置了多套主题，暗色模式尤其适合挂在办公室大屏上。到这里监控面板已经能用了，下一步才是关键——把需要盯的服务逐个加进去。

3. 核心监控项配置：让服务上墙并会喊人

3.1 支持的监控类型与我的常用组合

Uptime Kuma 支持的监控类型非常多，除了常规 HTTP(S)，还有 Ping、TCP 端口、DNS、关键字、Docker 容器、游戏服务器状态等。我把常见类型整理成一张表，方便直接对照：

我实际监控组合大致是：博客首页和文章接口走 HTTP(S)；对象存储的预签名地址走 TCP/HTTPS；家庭 NAS 通过内网穿透映射出来的端口走 TCP Port；云服务器本身走 Ping；第三方支付回调 URL 则用关键字监控，确保返回里包含约定状态码。不同目标配合不同监控类型，比盲目全用 HTTP 更能反映真实问题。

3.2 添加一条 HTTP 监控时，我会逐步确认的参数

以监控一个 API 为例，在“添加监控”页面选择 HTTP(S)，设置名称后填入 URL。下面几个参数容易踩坑：

• 请求间隔：默认一般是 60 秒，我通常保持不变。监控是长效防护，不是性能压测，设成 10 秒或 20 秒只会增加目标服务器压力和误报概率。
• 超时时间：默认值偏保守，我一般改成 10 秒。超过 10 秒没响应就认为这次探测失败，比默认更敏捷。
• 重试次数：如果设成 0，可能一次瞬时网络抖动就触发告警。我会设置 2 次重试，连续失败才判定宕机，有效减少噪音。
• 请求方法：普通 GET 探测即可。需要登录的页面可以考虑带 Header，或者用关键字内包含登录态特征的 URL 来探测。
• 关键字：这是非常实用的功能。我监控支付回调时，会在“关键字”里填服务器成功返回的标志字符串，请求正常但内容异常也能被及时发现。

配置页还允许自定义 HTTP Header、Basic Auth、客户端证书等。爬虫类业务如果担心探测请求被限流，可以设置一个独立的 User-Agent，同时在目标服务白名单里放行监控来源 IP。我试过不设 UA 去探测某些网站，偶尔会被 WAF 拦截造成误报，加一个 UptimeMonitoring/1.0 的 UA 后干净很多。

3.3 分组、维护窗口和通知渠道

服务一多，页面就会混乱，所以我强烈建议一开始就做好分组。我会划分“生产环境”“测试环境”“第三方服务”“家庭网络”等分组，不同分组设置不同颜色标识。“生产环境”里是核心业务，通知策略最严；“家庭网络”里的 NAS 主要用于提醒自己，不用轰炸式告警。

通知渠道在“设置 -> 通知”里配置。Uptime Kuma 支持邮件、Telegram、钉钉、企业微信、飞书、Webhook、iOS 和 Android App 推送等多种方式。我个人经验是：

• 个人项目：Telegram Bot 推送很方便，机器人稳定，通知消息还能自定义格式。
• 团队项目：优先选企业微信群机器人或飞书机器人，和内部沟通软件打通，比邮件更容易让值班同事真正看到。
• 邮件：必须配合靠谱的 SMTP 服务，很多域名邮箱容易进垃圾箱，配置后一定要先发测试邮件验证。

所有通知都可以绑定到具体监控项。配置完点击“测试”，如果收不到就检查密钥、群机器人 Webhook 地址以及网络连通性。实际用下来，从服务真正不可用到我手机弹出告警，延迟通常在 30 到 80 秒之间，取决于请求间隔和重试策略，这个灵敏度对大多数业务足够。

3.4 对外状态页：把“高颜值”变成生产力

这是我觉得最值回票价的功能：状态页。开启后可以创建一个不依赖登录的公开页面，展示所有服务当前状态、历史可用率、平均响应时间和近 90 天的事件记录。团队外部成员或客户不需要知道监控系统密码，打开状态页就能看到“现在是否正常”。

我配置状态页的做法是：先建分组，再按系统重要性把对应监控项拖进去；设置子路径，比如 status.example.com；自定义页头 Logo、主题色和站点名称；如果想做成只对内部可见的状态页，也可以加访问密码。页面自带移动端适配，用户拿手机看毫无压力。此类状态页做好后，甚至可以让客服直接发给用户，比人工回复“帮你看一下”专业太多。

操作维护窗口时，选择维护时间段并关联监控项，在这段时间内会暂停告警。比如每周日凌晨做数据库备份，很可能产生短暂服务中断，提前建立定时维护窗口，就不会收到一堆虚假告警。这个细节极其重要，我就是被“凌晨三点告警惊醒，结果发现是自己定时任务导致的”教训教过。

4. 真实故障模拟：从绿色到红色的一次复盘

4.1 我盯着哪些东西

说几个我正在监控的真实目标：个人博客首页、一个供小程序端调用的业务 API、对象存储的下载地址、以及家庭 NAS 的 Web 管理端口。每个监控项都有独立卡片，显示当前状态、最近响应时间、历史变化曲线和事件列表。日常我只打开首页按分组看一眼颜色，完全不需要点进每一项。

有一个我认为很实用的界面细节：状态卡片的响应时间曲线不是只有折线图，还能反映一段时间内服务的波动情况。虽然它提供不了复杂指标，但对于“最近这段时间 API 是不是变慢了”这类问题，曲线直接给我答案，不用再去查日志。

4.2 模拟一次真实宕机

为了验证整套链路，我故意把一台测试机上的 Nginx 容器停掉。这时监控项仍按 60 秒间隔发出请求，第一次请求超时后，系统按照我配置的重试次数再次探测。连续两次失败后，卡片从绿色变成黄色再变成红色，同时我提前绑定的消息通知收到一条告警：服务名、URL、故障开始时间都在通知里。

随后我把 Nginx 容器重新启动，下一轮探测成功后，卡片恢复绿色，通知渠道再次收到“恢复”消息。整个过程大概两分钟。从事件记录页能看到两次状态变更时间点，这个记录可以直接换算成可用率。如果对外状态页开启，用户侧还会显示一条运维事件，而不是一脸懵地等恢复。

4.3 面板卡住未必是服务挂了

高颜值监控也要理性使用。有一次面板把接口显示成红色，但我用手机流量访问目标 API 完全正常。后来排查发现，Uptime Kuma 所在服务器和目标 API 之间的网络路由出现了临时抽风，源服务器到目标服务器不通，用户到目标服务器却不受影响。换句话说，监控探测的是“监控点视角下的可用性”，不是你业务全部用户的真实体验。

这个案例给了我两点经验。一是不要把监控平台和业务部署在同一家云厂商同一可用区，否则厂商网络出问题，监控也宕了，什么也通知不了。二是可以把监控频率设为 60 秒以上，降低对目标服务的依赖，同时在目标服务器安全组里单独允许监控机 IP，防止探测请求被误杀。

5. 常见问题排查与我的避坑经验

5.1 高频问题速查表

5.2 保护监控服务本身

监控工具最容易被忽略的点就是安全。Uptime Kuma 默认没有内置非常细粒度的权限体系，且管理端能删除监控项、修改通知，如果直接把 3001 端口暴露公网，很容易被人爆破后台。我建议至少做三件事：

• 不要将 Docker 端口直接暴露到 0.0.0.0，尽量只监听 127.0.0.1，由 Nginx 反代对外提供访问。
• 为管理后台设置高强度密码，有条件的话在 Nginx 层再加一道 Basic Auth，或者启用项目自带的二次验证能力。
• 定期备份 Docker 卷：先停止容器，再用 docker run --rm -v uptime-kuma:/data -v $(pwd):/backup ubuntu tar czf /backup/uptime-kuma-backup.tar.gz -C /data . 将卷打包到宿主机，备份成本很低，恢复却可能救命。

5.3 关于更新和长期维护

Uptime Kuma 的版本迭代挺活跃，官方推荐使用 :1 标签跟随最新 1.x 版本。升级流程是：先 pull 新镜像，再删掉旧容器并基于同一数据卷重新创建。操作前先备份卷，尤其是版本跨度大的时候，我在一次大版本升级后遇到过自定义通知配置无法显示的问题，回滚备份后重新升级才恢复正常。

我个人的运维习惯是每季度检查一次容器版本，挑业务低峰期升级，升级后手动停一个测试监控项，确认告警能正常触发，再恢复，整个验证流程不到十分钟。这个习惯让我对监控系统本身的稳定性非常有底。

如果你也准备给手头服务安排一套高颜值而且不折腾的监控面板，直接按上面步骤搭起来基本没什么坑。先加分组后加监控项，通知渠道优先选能推送到手机的，状态页可以晚点再配。我实际用下来最大的体会是：监控方案不是拼功能多，而是拼“服务挂了你能多快知道，以及你愿意天天看它几眼”，这两点做好了，比什么都强。