个人博客搭起来之后，最开始关心的是页面能不能正常打开。等博客真正开始运行一段时间后，我又遇到一个新问题：如果网站挂了，我怎么第一时间知道？
如果只是偶尔自己打开看看，肯定不够可靠。可能网站已经挂了半天，但我自己没有访问，就完全不知道。尤其是博客还接了图床、统计、Notion 页面、友链插件这些服务后，整个个人站点已经不只是一个单页面了。主站、子域名、后台服务都需要一个地方统一看状态。
所以我部署了 Uptime Kuma，用它来监控我的网站和相关服务是否正常运行。运行网址
Uptime Kuma 是什么
Uptime Kuma 是一个开源的网站和服务监控工具。它的核心作用很简单：定时访问你配置的目标地址，然后判断这个服务是不是正常。
比如我可以配置它定时访问：
https://lovexfan.com
https://umami.lovexfan.com
https://imgbed.lovexfan.com
https://status.lovexfan.com
如果这些地址返回正常状态码，Uptime Kuma 就认为服务正常。如果请求失败、超时、返回异常状态码，它就会把这个监控项标记为故障。
它解决的是一个很直接的问题：
我的网站现在还活着吗？为什么个人博客也需要监控
很多人会觉得，个人博客又不是公司业务，挂了就挂了，没必要监控。
但我实际折腾下来发现，个人网站也很容易因为各种小问题出现异常。比如：
服务器重启后容器没有自动启动
Nginx 配置改错导致反向代理失败
SSL 证书过期
某个插件异常拖慢页面
数据库连接失败
Docker 容器崩了
子域名 DNS 配置有问题
Cloudflare 或反向代理规则配置错误
这些问题不一定每天发生，但一旦发生，如果没有监控，很可能过很久才发现。
Uptime Kuma 的价值就是把“我偶尔手动检查”变成“系统定时帮我检查”。
技术架构
Uptime Kuma 的架构比较简单，适合个人服务器部署。
可以理解成三部分：
监控调度器
↓
探测请求
↓
状态记录和通知它会按照你配置的时间间隔定时发起请求，比如每 60 秒访问一次 https://lovexfan.com。然后根据响应结果判断服务状态。
整体结构大概是：
Uptime Kuma Web 后台
↓
监控任务调度
↓
HTTP / Ping / TCP / DNS 等探测
↓
保存监控结果
↓
展示状态和发送通知如果部署在服务器上，一般会是这样：
浏览器
↓
Nginx / 反向代理
↓
Uptime Kuma 容器
↓
本地数据目录Uptime Kuma 自己带有 Web 管理后台，所有监控项都可以在页面里配置，不需要手写复杂配置文件。
技术栈
Uptime Kuma 是一个开源 Node.js 项目，常见部署方式是 Docker。
它主要涉及：
Node.js
Vue
SQLite
Docker
WebSocket
HTTP / TCP / Ping / DNS 监控
通知集成
默认情况下，它会把数据保存在本地数据目录里。用 Docker 部署时，一般会挂载一个 volume，比如：
volumes:
- ./data:/app/data这个目录里会保存监控配置、历史记录、通知配置等数据。所以迁移服务器时，除了重新启动容器，还要注意备份这个数据目录。
它能监控什么
Uptime Kuma 不只是监控网页是否能打开，它支持很多类型的监控。
常见的包括：
HTTP / HTTPS
Ping
TCP Port
DNS
Docker 容器
SSL 证书
推送监控
关键词监控
JSON Query
Steam Game Server 等
对我的个人博客来说，最常用的还是 HTTP / HTTPS 监控。
比如主站可以这样配置：
监控类型：HTTP(s)
URL：https://lovexfan.com
心跳间隔：60 秒
重试次数：2 或 3 次
超时时间：20 秒
接受状态码：200-299这样 Uptime Kuma 会定时访问我的主站。如果连续几次请求失败，它就会判定网站异常。
响应时间有什么用
除了判断网站是否正常，Uptime Kuma 还会记录响应时间。
这个数据可以帮我观察网站访问速度的变化。比如平时主站响应时间是 200ms 到 500ms，某天突然变成几秒，就说明可能有问题。
可能的原因包括：
服务器负载升高
数据库变慢
插件接口卡住
反向代理异常
网络线路波动
第三方资源加载拖慢
响应时间不是性能分析的全部，但它是一个很好的预警信号。
通知功能
监控工具最重要的不是后台页面有多好看，而是出问题时能不能通知我。
Uptime Kuma 支持非常多通知渠道，比如：
Telegram
邮件
Webhook
Discord
Slack
Bark
Server 酱
企业微信
飞书
钉钉
如果只是个人使用，接一个 Telegram、邮件或者 Server 酱就够了。
理想状态是：
网站异常 -> Uptime Kuma 检测到失败 -> 发送通知 -> 我及时处理这样就不用靠自己每天手动打开每个服务检查。
状态页是什么
Uptime Kuma 还有一个很实用的功能：状态页。
状态页就是一个公开展示服务运行状态的页面。比如可以把主站、图床、Umami、Notion 页面、友链服务都放在一个页面里。
访客打开状态页后，可以看到每个服务当前是正常、异常还是维护中。
它适合做成类似这样的页面：
主站：正常
图床：正常
Umami：正常
Notion Stories：正常
友链页面：正常对个人博客来说，状态页不一定是刚需，但它有两个好处：
第一，自己查看方便。所有服务状态集中在一个页面，不用一个个打开。
第二，如果以后网站访问异常，也可以让别人看到是局部服务异常，还是整个站点都挂了。
不过状态页只是展示结果，不负责修复问题。真正的检测还是由监控项完成的。
和 Umami 的区别
我之前也部署了 Umami，但 Umami 和 Uptime Kuma 完全不是一类工具。
Umami 关注的是访问统计。它告诉我有多少人访问网站、访问了哪些页面、从哪里来、使用什么设备。
Uptime Kuma 关注的是服务可用性。它告诉我网站有没有挂、接口能不能请求、响应时间是否正常。
可以简单理解成：
Umami：有没有人看我的网站？
Uptime Kuma：我的网站现在能不能正常打开？所以这两个工具是互补关系。
Umami 偏内容运营，Uptime Kuma 偏运维监控。
配置监控项时要注意什么
配置 Uptime Kuma 时，最重要的是不要只看“能不能请求成功”，还要根据服务特点设置合理规则。
比如主站 https://lovexfan.com，一般可以接受 200-299 这样的状态码。如果返回 500，肯定不正常。如果返回 404，也说明配置的 URL 可能不对。
如果监控的是后台登录页，可能会返回 302 跳转，这时就要根据实际情况决定是否接受 302。
如果监控的是某个 API，则可以使用关键词或 JSON Query，检查返回内容是否符合预期，而不只是状态码成功。
另外，心跳间隔也不要设置得太夸张。个人博客一般 60 秒或 120 秒检测一次就够了。太频繁没有太大意义，还会给服务增加额外请求。
反向代理和 WebSocket
Uptime Kuma 后台会用到 WebSocket。如果通过 Nginx 或其他反向代理访问，配置时要确保 WebSocket 正常转发。
如果反向代理没有配置好，页面可能会出现一直重连、不断刷新、提示重新加载网站之类的问题。
这种情况通常不是 Uptime Kuma 本身坏了，而是代理层没有正确处理升级连接。
Nginx 里一般需要类似这样的配置：
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";这也是我之前折腾 Uptime Kuma 时踩过的坑。普通网页请求能打开，不代表 WebSocket 就一定正常。
我的使用方式
我现在更倾向于把所有和博客相关的服务都加进 Uptime Kuma。
比如：
主站 lovexfan.com
图床服务
Umami 统计服务
Notion Stories 服务
友链页面
后台相关服务
其他子域名服务这样我的个人网站不再只是一个单独的博客，而是一组服务。Uptime Kuma 就像一个总控面板，帮我判断这些服务当前是否健康。
如果后续我继续增加子域名服务，也可以继续往里面加监控项。
总结
Uptime Kuma 对个人博客来说，是一个很实用的运维工具。
它不会帮我写文章，也不会统计真实访客，更不会自动修复网站故障。它的核心价值是持续检测服务状态，并在异常时提醒我。
我的博客目前大概是这样的分工：
Halo：负责文章内容
CloudFlare-ImgBed：负责图片托管
Umami：负责访问统计
Uptime Kuma：负责可用性监控这几个工具组合起来之后，个人博客就不再只是“能打开一个页面”，而是有了更完整的基础设施。
对个人站长来说，Uptime Kuma 不是必须部署，但如果你已经开始折腾多个子域名、多个服务、多个插件，那么它非常值得加上。因为网站出问题不可怕，可怕的是出了问题很久以后才发现。