原文来自我的个人博客：告别宝塔和WordPress：低配服务器从零搭建Typecho博客完整教程 - 叹惋博客
聊个真实经历。
去年我搭了个小工具站，没搞监控，觉得反正是自己用，挂了再说。结果有一天下午朋友找我"你网站咋又打不开了。"我打开浏览器一试，确实挂了。SSH连上去，重启Nginx、清缓存、翻日志，折腾了半小时才恢复。
但我到现在都不知道——它到底是几点挂的，挂了多久，是被人打了还是自己崩的。
第二天又来了一次。这次刚好在电脑前，发现是内存爆了。但如果不是刚好在呢？
后来我就决定搞个监控。Zabbix太重，Prometheus那套东西学习曲线太陡，云厂商自带的监控有些要额外付费。最后找到了Uptime Kuma，部署完之后的感觉就是：这个项目体验太顺了，几乎没有多余的步骤。
一、这个东西能监控些啥
Uptime Kuma本质上就是个定时帮你检查服务是否正常的机器人。
支持的监控类型不少：
1.HTTP/HTTPS网站：你的博客、导航站、API接口。除了检查状态码，还能检测页面里有没有包含特定关键字——这个功能用来防篡改很实用
2.TCP端口：SSH端口(22)、MySQL(3306)、Redis(6379)这些服务端口通不通
3.Ping：纯粹看主机是否在线，比TCP更底层
4.SSL证书过期：Let’s Encrypt三个月续一次，人脑哪记得住，让它帮你盯着
5.DNS解析：检测域名解析记录是否变了，或者被污染了
说白了，它就是一个7×24小时替你跑curl和ping命令的自动化工序果你新建了通知渠道但没有手动选上，它不会自动生效。
二、准备工作
服务器环境
我手头这台机器是雨云服务器，配置不高，跑Uptime Kuma完全够用。挂了三四十个监控项，内存占用一直稳定在200MB以内，CPU平时连5%都不到。
唯一的前提是装了Docker和Docker Compose。
如果还没装，依次敲这几条命令：
sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y
sudo usermod -aG docker $USER
newgrp docker
装完跑一下 docker --version 和 docker compose version，没报错就继续。
防火墙放行
默认端口是3001。两个地方要检查：
1.系统防火墙（如果你开了ufw的话）：
sudo ufw allow 3001/tcp
2.云服务商控制台的安全组。这个很容易忘——SSH能连上但浏览器死活打不开，八成就是安全组没放行。去后台入方向加一条规则：端口3001，协议TCP。
三、部署
别用docker run裸跑，后面想改参数或者看日志的时候命令会越记越长。建个文件夹用Compose管起来，一劳永逸。
依次执行：
mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma
然后用编辑器创建 docker-compose.yml 文件：
nano docker-compose.yml
把下面的内容粘贴进去：
version: "3.8"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "3001:3001"
volumes:
- ./data:/app/data
environment:
- TZ=Asia/Shanghai
按 Ctrl+X，按 Y，再按回车保存退出。
volumes那行是重点： ./data:/app/data 把容器内部的数据目录挂载到宿主机上。如果不做这一步，容器一删，你配的所有监控项、历史数据、通知设置全没了。挂载了的话，哪怕容器炸了重新建一个，数据都还在。
接下来启动容器：
docker compose up -d
等镜像拉完，浏览器打开http://你的服务器IP:3001，看到注册页面就说明成了。
日常管理命令也顺手记一下：
# 查看容器运行状态
docker ps
# 查看实时日志（排查问题用）
docker logs -f uptime-kuma
# 停止容器
docker compose down
# 重启容器
docker compose restart
# 更新镜像到最新版
docker compose pull
docker compose up -d
四、初始化管理员账号
第一次访问会让你注册一个管理员账户，填用户名、密码、邮箱。邮箱可以随便填，但密码别太简单，毕竟这东西暴露在公网上。
注册完登录进去，仪表盘是空的。接下来开始配监控。
五、添加第一个监控项
很多人到这一步就填个URL完事了。但其实展开"高级设置"，里面有些配置能帮你省掉很多误报的麻烦。
以监控一个博客为例
1.监控类型：HTTP(s)
2.显示名称：个人博客
3.URL：https://你的博客地址
4.检测间隔：60秒（个人用足够了，没必要设太短）
高级设置里几个值得调的选项：
预期状态码默认是200。但有些网站会返回301/302重定向，如果没改就会误报。建议直接设成200-299，只要是2开头的状态码都算正常。
重试次数默认0次，建议改成1次。有时候只是网络闪了一下丢了个包，重试两次就能过滤掉大部分误报。不然大半夜手机被震醒，发现只是骨干网抽风了一秒钟，那感觉真不太好。
响应超时可以改到15秒。
监控SSL证书过期（强烈建议勾上）
在高级设置里找到"监控证书过期"，勾上之后设置提醒阈值：
Let’s Encrypt免费证书三个月就得续一次，身边好几个站长都是忘了续导致网站打不开才反应过来。这个功能就是防这个的。
六、配通知
监控配好了，怎么通知你是关键。不配通知的话，这个监控就只是个漂亮的数据看板，没什么实际用处。
企业微信（国内最方便）
- 在企业微信群聊里点右上角三个点 → 群机器人 → 添加机器人
- 复制Webhook地址（长这样：
https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx） - Uptime Kuma后台进"设置 → 通知 → 添加通知"
- 类型选"企业微信"，把Webhook贴进去
- 点"测试"，群里收到消息就说明通了
好处是微信你每天都在看，告警来了不会漏。
飞书
群聊里添加"自定义机器人"，获取Webhook。如果开启了签名校验，记得把签名密钥也填到Kuma对应的字段里。
邮件SMTP（最稳定的兜底方案）
选"Email (SMTP)"，以QQ邮箱为例：
- SMTP服务器：
smtp.qq.com - 端口：
465（SSL加密） - 用户名：你的QQ邮箱
- 密码：不是QQ登录密码，是邮箱后台生成的16位授权码
填完测试一下，能收到就存。
每个监控项可以单独指定通知渠道
在监控项的编辑界面里，有个"通知"下拉框，可以选这个监控项的告警发到哪个渠道。
比如测试环境的消息只发到测试群，不想打扰主群，就可以单独指定，灵活度挺高的。
七、维护窗口（防误报）
这个功能很多人在用之前根本不知道，但用过了就回不去。
设想一个场景：你半夜要重启服务器升级内核，刚敲完reboot，手机就开始疯狂弹通知——“博客宕机了！”“API不可达！”“数据库端口关闭！”
你一边重启一边被消息轰炸，烦不烦？
配置路径： 头像 → 维护 → 计划维护
1.起个名字，比如"系统升级窗口"
2.勾选会受影响的监控项
3.设置时间段，比如周六凌晨 02:00 到 06:00
这个时间段内就算真的挂了，Kuma也不会发告警通知，状态页上只会显示"计划维护中"。
从此不用再掐着秒表算重启时间了。
八、状态页公开
Uptime Kuma自带一个只读的状态展示页，可以对外公开。
路径：顶部菜单"状态页" → 新增状态页。
选好要展示的监控项，生成一个链接（比如http://IP:3001/status/abc123）。
这个页面显示各个服务的当前状态、响应时间、可用性百分比。你可以把这个链接挂在博客底部或者项目主页上，告诉用户"服务状态在这里看"，比口说无凭强多了。
九、用Nginx反代加HTTPS
如果不想每次都记IP加端口，想绑个域名比如status.yourdomain.com来访问，可以用Nginx反向代理。
先装Nginx：
sudo apt install nginx -y
创建站点配置：
sudo nano /etc/nginx/sites-available/uptime-kuma
把下面的配置贴进去，把monitor.your-domain.com换成你自己的域名，证书路径也换成你自己的：
server {
listen 80;
server_name monitor.your-domain.com;
# 只把/.well-known路径放行给Certbot验证，其余全部跳转HTTPS
location /.well-known/acme-challenge/ {
root /var/www/html;
}
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2;
server_name monitor.your-domain.com;
ssl_certificate /etc/letsencrypt/live/monitor.your-domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monitor.your-domain.com/privkey.pem;
# SSL配置建议加上这几行提高安全性
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
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-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}
启用配置：
sudo ln -s /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
有一个坑要注意： 配置里 proxy_set_header Upgrade 和 proxy_set_header Connection "upgrade" 这两行不能少。Uptime Kuma用到了WebSocket长连接，少了这两行仪表盘的实时状态会卡住不刷新。
十、数据备份和迁移
前面我们把数据挂载到了./data目录。这个目录里其实就是SQLite数据库文件加上一些缓存。
备份操作：
cd /opt/uptime-kuma
docker compose stop
tar -czf uptime-backup-$(date +%Y%m%d).tar.gz ./data
docker compose start
# 把备份文件下载到本地，或者传到其他存储位置
# 备份文件在 /opt/uptime-kuma/uptime-backup-20260725.tar.gz
如果以后换服务器了，迁移步骤：
mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma
# 把备份文件上传到这个目录，然后解压
tar -xzf uptime-backup-20260725.tar.gz
# 创建同样的docker-compose.yml文件
nano docker-compose.yml
# 粘贴之前的compose内容
docker compose up -d
打开网页一看，所有监控项、历史记录、通知配置全都在，无缝迁移。
十一、日常维护
跑久了（半年以上），SQLite数据库会变大，可能吃掉几百MB。可以定期做个碎片整理：
cd /opt/uptime-kuma
docker compose stop
docker run --rm -v $(pwd)/data:/data alpine:3.18 sh -c "apk add sqlite3 && sqlite3 /data/kuma.db 'VACUUM;'"
docker compose start
这条命令会重建数据库文件，去除删除数据留下的空闲空间，体积经常能缩小30%-50%。
另外，如果担心Docker日志把磁盘撑爆，可以在docker-compose.yml里加上日志大小限制。把原来的内容改成这样：
version: "3.8"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "3001:3001"
volumes:
- ./data:/app/data
environment:
- TZ=Asia/Shanghai
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
改完之后执行 docker compose up -d 重建容器就会生效。
十二、几个小问题
Q：Ping监控一直失败是为什么？
容器里执行Ping需要额外权限。要么在Compose里加cap_add: - NET_RAW，要么干脆改用TCP端口监控（比如监控22端口），效果差不多。
Q：企业微信测试通，但挂了不通知？
检查监控项编辑界面里，“通知"下拉框有没有选对渠道。默认是"默认通知组”，如果你新建了通知渠道但没有手动选上，它不会自动生效。
Q：消息轰炸怎么办？
两个办法：一个是前面说的维护窗口，另一个是把监控项的"重试次数"设到3次，连续失败3次才发告警，短暂网络抖动就不会炸锅了。
Q：怎么更新到最新版？
cd /opt/uptime-kuma
docker compose pull
docker compose up -d
十二、总结
Uptime Kuma是我目前用过的部署最简单、功能最够用的开源监控方案。从一条docker命令到配好通知，熟练的话十分钟就能搞定一套完整的监控系统。
有了它之后，网站挂了你是第一个知道的，甚至用户还没发现你就已经修好了。
项目地址：GitHub - louislam/uptime-kuma: A fancy self-hosted monitoring tool · GitHub
服务器买来光吃灰太浪费了，装个Uptime Kuma也算是物尽其用。如果你手头刚好有台闲置的机器，不妨花十分钟装一下试试。