企业官网建设流程全解析

1. 本地部署前的思路：为什么我选 Uptime Kuma 做网站监控

讲真的，网站监控这件事，市面上商业方案一抓一大把，比如 UptimeRobot、Pingdom 这些，免费额度看着挺香，真用起来就难受了——监控频率最低 5 分钟一次，想要 1 分钟级别的探测就得掏钱，而且监控节点都在公网上，对纯内网环境、家庭宽带或者公司服务器根本无能为力。更别说数据都在别人手里，状态页、告警、历史记录这些核心资产全绑在第三方平台上，哪天平台改个政策或者服务挂了，你连个替代方案都来不及找。

Uptime Kuma 是我比较了一圈之后确定下来的方案。这个项目本质上是一个开源的、支持自托管的监控看板，界面是用 Vue 写的，后端跑 Node.js，数据库用的 SQLite，整体非常轻。它解决的最大痛点就是“监控这个动作本身得可控”：部署在你的本地服务器上，监控频率自己定，数据完全私有，通知渠道几乎覆盖了主流 IM（Telegram、Discord、钉钉、飞书、邮件、Webhook 全都支持），而且自带一个非常漂亮的状态页，可以直接拿来做服务公开展示。

我这次是在一台局域网内的 Ubuntu 服务器上部署的，Docker 方式安装，前后不到半小时就跑起来了。这篇文章我会把整个搭建过程、配置细节、踩过的坑全部记录下来，如果你也想在自己的本地服务器上搭一套私有监控，照着做基本能一次成功。适合的人群很明确：家里有 NAS 或小主机的折腾党、公司内部有业务系统需要盯着的运维、以及不想为监控服务付费的独立开发者。

2. 部署前必须想清楚的几个选型问题

2.1 裸机装还是 Docker 装

官方仓库的 README 提供了两种主流的安装方式：直接 Node.js 跑源码，或者用 Docker 跑官方镜像。个人强烈建议用 Docker，原因有几个。

Uptime Kuma 的依赖其实不算复杂，但它依赖的 Node.js 版本是有要求的，太老或太新的系统自带 Node 版本很容易踩坑。Docker 镜像把整个运行时环境都打包好了，你不需要在宿主机上装 Node、装 npm、处理版本冲突，一条 docker run 命令搞定一切。

还有一个更实际的原因：升级。Uptime Kuma 的迭代速度非常快，基本每个月都有新版本，加了不少实用功能。Docker 方式升级只需要拉新镜像、重建容器，旧容器删掉即可，数据都存在 volume 里，不会丢。裸机方式升级要手动拉代码、装依赖、重启服务，操作步骤多了，出错概率自然也就上去了。

2.2 要不要加反向代理

如果只在局域网内访问，完全不需要反向代理，直接 IP 加端口就行。但如果你的监控服务需要暴露到公网（比如人在外面想随时看状态页），那强烈建议在前面套一层 Nginx 或者 Caddy。原因不只是 HTTPS 证书的问题，还有安全层面的考虑——Uptime Kuma 虽然本身有登录认证，但任何暴漏到公网的管理后台都是攻击面，用反向代理加一层访问控制、加一层 TLS，能挡掉很多无差别扫描。

我自己的部署场景比较特殊：监控目标既有公网网站，也有内网其他服务器的端口连通性。这种情况下如果监控服务部署在内网，公网网站能正常探测到；但反过来，如果部署在公网，就探测不到内网服务的真实状态了。所以“本地服务器”这个定位并不是妥协，而是这种混合监控场景下最合理的方案。

2.3 网络拓扑的确认清单

部署之前建议先确认几件事，避免装到一半发现网络不通：

• 本地服务器的 IP 是否固定（建议在路由器或 DHCP 里做 MAC 地址绑定，否则后面配置通知、回调地址容易出问题）。
• 服务器上的防火墙是否放行了对应端口（Docker 默认映射端口、反向代理端口都要放行）。
• 能否访问外网（Uptime Kuma 的 Docker 镜像需要从 Docker Hub 拉取，如果服务器在纯内网环境需要先解决镜像源的访问问题）。

3. Docker 部署全流程：从零开始把服务跑起来

3.1 先装 Docker 环境

如果你的服务器上还没有 Docker，这一步得先补上。以 Ubuntu 为例，直接按官方文档来：

sudo apt update sudo apt install ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.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

装完以后执行sudo systemctl enable --now docker，然后docker --version确认一下版本。这里多说一句：Docker 安装包在部分网络环境下可能拉取比较慢，如果遇到超时可以考虑配置国内镜像加速器，这里就不展开讲具体配置了，网上方案很多，关键是让docker pull能正常跑通。

3.2 用 docker-compose 部署 Uptime Kuma

我不太建议直接敲一长串docker run命令来部署，因为参数实在太多，一旦写错或者以后想改配置，还得去翻历史命令。用 docker-compose 把配置固化下来，一劳永逸。

新建一个目录，比如mkdir -p ~/uptime-kuma && cd ~/uptime-kuma，然后创建docker-compose.yml：

version: "3.8" services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma restart: always ports: - "3001:3001" volumes: - ./data:/app/data

然后启动：

sudo docker compose up -d

启动后执行sudo docker ps，看到uptime-kuma容器处于Up状态就说明服务起来了。浏览器访问http://服务器IP:3001，第一次打开会让你创建管理员账号，用户名和密码尽量设置得复杂一点，因为这个页面理论上谁都能访问，如果暴露到公网，弱口令非常危险。

关于镜像版本，我习惯用louislam/uptime-kuma:1这个标签，它会跟随 1.x 的最新版本走，既能及时获得功能更新，又不会出现像latest那样的大版本跳变风险。

3.3 数据目录和备份策略

注意看我在 compose 文件里映射的./data:/app/data，这个目录是 Uptime Kuma 存放 SQLite 数据库、配置文件、上传图片的地方。所有监控配置、通知配置、状态页设置，全在这个目录里。

备份的方式非常简单：定期把data目录打包拷贝走就可以了。

tar -czvf uptime-kuma-backup-$(date +%Y%m%d).tar.gz data/

我实际用下来，整个 data 目录即便配置了十几个监控项、几十条通知记录，大小也就几 MB，备份成本几乎可以忽略不计。建议配合 crontab 写个定时任务，每天凌晨备份一次，保留最近 7 天的备份文件。数据库文件虽然 SQLite 支持并发读写，但备份时最好先停一下容器（docker compose stop），或者在容器内先做 SQLite 的在线备份，避免备份到一半写入引起的文件不一致。我偷懒的做法是直接 tar 打包，实测没有出过问题，但如果你有完美主义倾向，可以多加一步：

sudo docker exec uptime-kuma node -e "const db = require('./server/database'); db.close();"

不过这条命令在不同版本上可能不太兼容，所以我最终觉得直接打包整个 data 目录，加上频率够高，是容错性最好的方案。

4. 核心环节：监控项的创建与配置细节

Uptime Kuma 最核心的用法就是添加监控项。登录后台后，点击 “Add New Monitor”，这里会看到非常多的监控类型，接下来逐个讲。

4.1 HTTP(s) 监控——最常用的一类

对于网页服务，最简单也最关键的就是 HTTP 监控。它的原理就是定时向你的目标 URL 发送 HTTP 请求，根据返回的状态码判断服务是否正常。配置时有几个关键参数：

• URL：填你要监控的完整地址，比如https://example.com/index.html。这里有个容易忽略的点：如果你是监控 API 接口，URL 里可以直接带路径和查询参数；如果你监控的是浏览器渲染后的页面，要清楚 Uptime Kuma 并不会执行 JavaScript 渲染，它只看 HTTP 响应。想监控动态渲染的页面，要么用后面的“Browser Script”类型，要么就退而求其次监控静态资源文件。
• Expected Status Codes：预期状态码。默认是 200-299，比较宽松。如果服务本身会返回 302 重定向，你需要把 302 加进去，或者保证重定向的最终落地页是正常的；如果服务有自定义的状态码（比如有的网关返回 499），也需要在这里配置。
• Interval：探测间隔。Uptime Kuma 的最小间隔是 20 秒（Pro 计划支持到 20 秒，自托管可以自己改，实际跑 20 秒没问题，再短意义不大了）。个人建议公网网站用 60 秒或 5 分钟，内网服务可以适当缩短到 30 秒或 20 秒，但要注意——如果被监控的服务是生产系统，过于频繁的探测可能会增加不必要的负载，尤其是一些老旧的业务系统，扛不住高频请求刷新缓存。
• Timeout：超时时间。默认 49 秒，意味着如果请求超过 49 秒没有响应就判定失败。对大多数 Web 服务来说这个值太长了，建议改成 10-15 秒，否则一旦服务响应变慢，你也只能干等到超时才能感知到“异常”。

4.2 Ping 监控和端口监控

除了 HTTP，Uptime Kuma 还支持 Ping、TCP 端口、DNS、关键字等监控方式。

Ping 监控适合探测服务器是否在线，原理就是发送 ICMP 包。这里提醒一下：很多云服务器和部分内网设备默认禁 ping 或者对 ICMP 限流，如果发现 Ping 监控老是不稳定，先手动在服务器上 ping 一下目标 IP，确认是不是防火墙的锅。

TCP 端口监控非常实用，比如你想监控某个数据库的 3306 端口、Redis 的 6379 端口、SSH 的 22 端口是否是开放的。这类监控不需要任何 HTTP 层的能力，只要端口能建立 TCP 连接就算正常。我在公司内部就用这个方法监控了好几台内网服务器的 SSH 端口和一些自建中间件。

配置端口监控时有一个小技巧：把 Resolve DNS 选项和 IP 版本设置搞清楚。如果域名解析本身有问题，端口监控会直接失败，这时候可能并不是端口不通，而是 DNS 解析挂了。建议内网服务直接用 IP 地址，公网服务可以同时选择 “Resolve hostname to IPv4” 选项来确保走 IPv4 解析。

4.3 关键字监控——检测页面内容是否正确

HTTP 状态码 200 只能说明“服务还活着”，但没法告诉你“服务逻辑正不正常”。比如一个登录页，如果数据库挂了，可能页面还能返回 200，只是页面上的数据会加载失败。这种情况下，关键字监控就派上用场了。

在 HTTP 监控的高级设置里，有一个“Keyword”选项，填一个关键字和一个类型（存在或不存在）。比如你监控一个搜索接口，返回的 JSON 里应该包含"success": true，那就把success填进去，选择 “Keyword exists”。如果页面上有一个错误提示文案Internal Server Error，你可以填进去并选择 “Keyword should not exist”，这样一旦页面返回了错误提示，监控会直接告警。

关键字监控有一个坑：HTTP 响应体的大小。如果页面内容非常大（几 MB），每次抓取响应体来做关键字匹配会消耗额外流量和 CPU。Uptime Kuma 对此的处理还可以，实际跑下来对小站点完全没有压力，但如果你监控的是大文件下载地址，就别用关键字监控了，直接用 HTTP 状态码就行。

4.4 证书监控——防止 HTTPS 证书过期

HTTPS 证书过期这种事故，我相信搞过网站的人都经历过。Uptime Kuma 自带Certificate Info监控类型，可以检测一个域名的 SSL 证书还有多少天过期。这个功能非常省心，配置好以后，证书剩余天数会显示在监控项上，快过期了还能收到通知。

证书监控有一点要注意：如果域名是通过 CDN 或反向代理访问的，检测到的证书可能是 CDN 节点的证书，而不是源站证书。这种情况下证书监控依然有效，因为最终用户访问的也是这个证书。但如果你想监控源站证书，就得填源站 IP 加 Host 头，或者干脆在 CDN 和源站之间做单独的内网证书监控。

配置很简单，URL 填域名（不需要加协议），端口默认 443，如果你想监控非标准端口的 HTTPS 证书，记得把端口改掉。

5. 通知配置与分组管理：告警不能只发到一个地方

5.1 配置 Telegram 通知

监控配好了，最关键的其实是通知。如果平台监控到服务宕机、却没法把信息推送到你手上，那这监控基本等于白做。

Uptime Kuma 的通知渠道非常丰富，我最常用的是 Telegram。配置 Telegram 通知需要三步：第一步，在 Telegram 里创建自己的 Bot，拿到 Bot Token（通过 BotFather 创建，格式大概是123456:ABC-DEF...）；第二步，获取接收告警的 Chat ID（可以给 Bot 发一条消息后，通过 getUpdates 接口拿到）；第三步，在 Uptime Kuma 的 “Setup Notification” 里把 Token 和 Chat ID 填进去，保存后可以点 “Test” 按钮测试。

Telegram 通知的优点在于，Uptime Kuma 天然支持 Markdown 格式化，告警消息可以带上监控项名称、当前状态、响应时间这些信息，一眼就能看明白是哪个服务出了问题。而且手机客户端推送很及时，基本是秒级到达。

5.2 Webhook 通知——打通任意系统

如果你的团队用的是自建 IM 或者内部工单系统，Webhook 是万能的。Uptime Kuma 在通知配置里提供 Webhook 类型，你可以把请求发到任意 HTTP 接口。配置时注意 Custom Headers 里可以加上认证 Token，Body 里支持变量模板，比如：

{ "monitor": "{{NAME}}", "status": "{{STATUS}}", "url": "{{URL}}" }

这里{{NAME}}、{{STATUS}}、{{URL}}是 Kuma 内置的变量，会在请求发出时自动替换成实际值。官方文档里列出所有变量的说明，你按需拼接即可。如果你的通知系统要求 GET 请求而不是 POST，把 Method 改掉就行，非常灵活。

5.3 按监控分组管理

监控项多了以后，如果没有分组，仪表盘会越来越乱。Uptime Kuma 支持给监控项打标签（Tag），你可以把“官网”、“API”、“数据库”、“内网服务”分别打上不同的标签，然后在主页按标签筛选查看。这个功能特别适合有几十个监控项的场景。

我自己的习惯是：标签不仅做分类，还用来做告警路由。比如“TeamA”标签关联 Telegram 群组 A，“TeamB”标签关联企业微信群组 B，这样每个团队只会收到自己负责的那部分服务的告警，不会造成全体轰炸。实现方式就是在添加监控项时在 Tags 里选好对应标签，然后在通知配置页面，把每个通知渠道绑定到你想要的标签上。这样既实现了告警分流，又能保留一个全局视角的仪表盘。

5.4 使用状态页对外展示服务状态

Uptime Kuma 自带的 Status Page 功能，个人觉得是被很多人低估的亮点。你可以配置一个公开的状态页，展示所有监控项的实时状态，包括可用率、响应时间、历史事件。这个页面完全不需要登录就能访问，适合挂在你公司官网的/status路径上，或者分享给客户、用户群体。

配置状态页时，把选好的监控项拖进去，设置好公开访问的 slug（一个简洁的英文标识），再美化一下标题和 logo 就行。如果状态页面向公网用户，建议给它套一层 HTTP 认证或者 Cloudflare Access 之类的访问控制，避免监控数据被无关人员看到——当然，如果你就是想公开透明，那就不设限制直接发布。

6. 常见问题排查：部署和运行中遇到的坑一次性讲完

6.1 端口冲突导致服务起不来

Docker 启动容器时，如果3001端口被宿主机上其他进程占用了，容器会报错退出。排查方法很简单：

sudo lsof -i:3001 sudo netstat -tunlp | grep 3001

找到占用进程后，要么换 Uptime Kuma 的映射端口（比如3002:3001），要么处理掉那个进程。注意容器内端口始终是 3001，宿主机端口可以随便映射。

6.2 邮件通知无法发送

很多人配置 SMTP 通知时遇到问题，明明服务器 25/465/587 端口都是通的，但邮件就是发不出去。我的经验是先确认邮箱服务商是否开启了 SMTP 服务、是否用了授权码而不是邮箱密码。QQ 邮箱、163 邮箱都需要单独开启 SMTP 并生成授权码，直接用客户端密码登录是会被拒绝的。

另外，如果用 465 端口（SSL）或 587 端口（STARTTLS），注意 Uptime Kuma 的邮件配置里选择对应的加密方式。选错了照样连不上。

6.3 监控项频繁误报

如果你发现服务明明好好的，Uptime Kuma 却经常告警，首先怀疑是超时时间配置得太短。特别是一些性能不稳定的 API，平时响应 200ms，高峰期突然涨到 2 秒，如果超时设成 1 秒，就会误报。建议先在监控项的 “HTTP Timeout” 里把时间放宽一点，稳定运行一段时间后再逐步调小。

还有一个常见原因是代理导致的。如果 Uptime Kuma 部署在某个网络环境下，HTTP 请求必须走代理才能访问公网，但 Kuma 默认不走系统代理，需要配置环境变量HTTP_PROXY、HTTPS_PROXY才能正常探测。不配置的话，所有公网监控项都会报错。

6.4 Docker 重启后监控数据丢失

这个问题遇到过一次，起因是 compose 文件里忘了挂载 volume。如果不挂./data:/app/data，容器每次重建后数据就回滚到镜像初始状态，所有监控项和配置都会丢。检查一下 compose 文件里有没有这段：

volumes: - ./data:/app/data

如果之前已经踩坑了，但容器还没删，可以试试从容器里把数据拷贝出来：

sudo docker cp uptime-kuma:/app/data ./data

然后再改 compose 文件把 volume 挂上，手动恢复。

6.5 不能删除内置管理员账号

Uptime Kuma 的数据库里第一个创建的管理员账号是系统内置的，除非你主动修改，否则很多权限操作都依赖它。如果你在测试时不小心创建了多个账号，不要试图直接删除第一个管理员，否则可能会导致后续无法登录。安全起见，第一任管理员密码一定要记好。

7. 性能调优与高可用方案：让监控服务本身更靠谱

7.1 监控实例本身不能成为单点故障

监控系统最重要的属性就是“自己不能挂”。如果你只在一个台机器上跑了 Uptime Kuma，那你监控所有服务的底气，完全系于这台机器的稳定性。对于不重要的小项目，一台小主机足够用了；但对于真正重要的业务，建议部署两个实例，分别放在不同网络环境（比如一个在家里，一个在云服务器上），用状态页把两个实例合在一起展示。

如果做双实例，需要注意数据库同步的问题。Uptime Kuma 官方不推荐两个实例直接共享同一个 SQLite 数据文件，SQLite 在多写场景下容易锁库。可以退而求其次让两个实例的监控项各自维护，状态页只做展示聚合。

7.2 资源占用极低，适合跑在低配设备上

Uptime Kuma 的资源占用非常友好。我实测在 1 核 1G 的小鸡上，跑 10 个监控项、1 分钟探测间隔，内存占用大约 150MB 左右，CPU 基本在 1% 以下。在树莓派、群晖 NAS 甚至一些软路由上跑都毫无压力。如果你手头有吃灰的 ARM 小盒子，装 Docker 后直接部署，很香。

7.3 状态页缓存与公网安全

如果把状态页开放到公网，建议在反向代理层加一个缓存策略，避免每次用户刷新状态页都触发 Kuma 的实时检查。例如 Caddy 的静态文件缓存配置，或者 Nginx 的proxy_cache。不过 Uptime Kuma 本身已经做了连接复用和轻量查询，实际压力很小，加缓存更多是锦上添花。

公网暴露安全方面，有几个亲测有效的习惯：

• 务必设置强密码，最好开两步验证（Uptime Kuma 支持 TOTP 二次认证）。
• 不要在默认端口 3001 上直接裸奔，换一个高位随机端口，或者通过反向代理只暴露状态页，管理后台只允许内网访问。
• 如果管理后台必须公网访问，用 Nginx 加一层 basic auth 做前置拦截，就算 Kuma 有漏洞也能挡住一部分扫描攻击。
• 定期更新镜像，docker compose pull && docker compose up -d，一行命令的事，别偷懒。

8. 最终的使用心得和一些容易忽略的细节

最后再分享几个我实际使用过程中的体会。

Uptime Kuma 的监控日志和历史数据是很有价值的，但很多人配完告警就不管了。建议每周末花两分钟看一遍每个监控项的可用率趋势，有些问题不是“宕机”级别的，而是“响应时间逐步劣化”——比如每天响应时间上涨 50ms，连续涨了一个月，说明上游服务或数据库可能出现了隐患。Uptime Kuma 的图表虽然不算华丽，但这种趋势分析足够用了。

另一个容易忽略的细节是监控项的分组逻辑。很多人一开始把所有监控项堆在同一个仪表盘下，时间久了很难定位问题。建议一开始就按照业务系统维度或网络区域维度来分组，比如“核心电商站群”、“内部OA系统”、“第三方API依赖”。这样一旦告警进来，你能第一时间判断影响范围，而不是看到一堆红色条目，不知道从哪里开始排查。

比如说，你可以利用 Uptime Kuma 的 “Group” 功能（有些版本叫 “Parent”），把多个子监控项聚合到一个父级监控下。如果你的服务是多个依赖组成的整体，父级挂了可以先告警，子级再往下钻取定位具体问题。这种层级化管理在监控数量超过 20 个以后，帮你省下大把时间。

还有一个只有长期用才会发现的点：Uptime Kuma 自带的 “Maintenance” 功能一定要用起来。每次发布上线或维护窗口期，提前把对应的监控项设置为维护状态，否则你会在发布过程中收到一堆假告警，久而久之对告警就麻木了，真出问题时反而没人关心。设置维护时间段之后，状态页会显示这个监控项“Under Maintenance”，很规范，也方便团队协作。

我个人目前跑了三个实例，分别管家里的 NAS、公司的几个核心业务系统和几个客户的公网网站。用了快一年，稳定性没得说，告警通知几乎没有漏报过。如果你还在用第三方监控平台被限制频率和节点，建议花半小时搭一套自己的 Uptime Kuma，上手非常简单，用了就回不去了。