任务 11：小内存 VPS 必备——自建轻量级监控体系 (Uptime Kuma)

对于一台内存有限的云服务器（尤其是在运行严格限制了内存的数据库和各项后端服务时），服务因为 OOM（内存溢出）被系统底层强制“杀”掉常发生。需要一个“数字保安”24小时盯着各项服务，并在发生故障时秒级推送通知。

本教程采用 Uptime Kuma，纯 Docker 环境部署，保持宿主机极其干净，并配合 Nginx 容器实现优雅的反向代理与 HTTPS 访问。

核心步骤与配置记录

#

Step 1: 容器化部署 Uptime Kuma

#

为了让 Uptime Kuma 能够监控同在宿主机上的其他 Docker 容器（例如 mysql-lite），必须将宿主机的 Docker Socket 映射给 Kuma 容器。

1. 创建专属目录并编写配置文件：

mkdir -p /opt/uptimekuma
cd /opt/uptimekuma
nano docker-compose.yml

2. 写入 docker-compose.yml：

version: '3.3'
services:
  uptime-kuma:
	image: louislam/uptime-kuma:1
	container_name: uptime-kuma
	volumes:
	  - ./uptime-kuma-data:/app/data
	  # 核心关键：允许 Kuma 读取宿主机上所有容器的状态
	  - /var/run/docker.sock:/var/run/docker.sock
	ports:
	  - "3001:3001"
	restart: always

3. 启动服务：

docker-compose up -d

如果提示没有docker-compose命令，试试换成新版本的“docker compose”

Step 2: Nginx 反向代理配置

#

可以选择自己添加一个专属子域名（如 status.gyqblog.top）使用 HTTPS 访问监控面板，需要在 Nginx 中配置反向代理。

502 / 503 报错排查：

由于 Nginx 也是运行在 Docker 容器（nginx-gateway）中的，如果直接在 Nginx 配置里写 proxy_pass http://127.0.0.1:3001;，Nginx 会去它自己的容器内部寻找 3001 端口，从而导致 502 Bad Gateway 报错。

在 Nginx 配置文件中加入以下块：

server {
    listen 80;
    server_name status.gyqblog.top; # 自己的监控专属域名

    location / {
        # 这样 Nginx 容器就能精准访问到宿主机上的 3001 端口
        proxy_pass http://《填写自己VPS的IP》:3001;
        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;

        # Uptime Kuma 依赖 WebSocket 实时更新状态，必须添加以下两行支持 WS
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

配置完成后，向 Nginx 容器发送重载指令：

docker exec nginx-gateway nginx -s reload

(注：后续配合 acme.sh 申请并配置好 SSL 证书后，即可通过 HTTPS 安全访问面板)

Step 3: 配置核心监控项

#

进入面板并设置好管理员账号后，首先添加以下两个核心维度的基础设施监控：

1. 监控 Docker 容器存活 (以 MySQL 为例)

#

这能帮我们在数据库容器因内存不足崩溃时，第一时间收到告警。

1. 在“设置” -> “Docker 宿主”中，添加本机节点：

   • 显示名称：本机 Docker
   • 连接方式：Socket
   • 守护进程：保持默认的 /var/run/docker.sock（对应 Step 1 中目录映射）。
   • 点击测试成功后保存。

2. 回到主页点击“添加监控项”，类型选择 Docker 容器。

3. 容器名称/ID：精准填入要监控的容器名（如 mysql-lite）。

2. 监控 Web 服务与证书 (以博客主页为例)

#

确保 Nginx 代理、静态资源和整条公网网络链路畅通。

1. 添加监控项，类型选择 HTTP(s)。
2. URL：填入主站地址 https://gyqblog.top。
3. 勾选“证书到期提醒”（建议设置为提前 7 天或 14 天），防止自动化续期脚本因偶尔的网络波动执行失败而导致浏览器弹出安全警告。

Step 4: 配置 SMTP 邮件告警通知

#

监控配好后，必须打通主动推送机制，否则监控就失去了意义。这里使用第三方邮箱的 SMTP 服务 实现自动化邮件报警（支持发件人和收件人使用同一个邮箱，即“自己给自己发信”）。

详细填写指南：

#

• 通知类型：选择 电子邮件 (SMTP)。
• 显示名称：自定义，如 来自VPS监控平台的通知。
• 主机名 (Hostname)：填入发件邮箱的 SMTP 服务器地址。
  • QQ 邮箱：smtp.qq.com
  • 网易 163 邮箱：smtp.163.com
• 端口 (Port) & 安全性 (Security)：首推加密通道，端口填 465，安全性下拉框选择 强加密 (SSL/TLS)。
• 用户名 (Username)：填入发信邮箱的完整地址（如 xxxx@qq.com）。
• 密码 (Password) ：不能填邮箱的登录密码！ 要填入你在邮箱网页端设置中（“账户” -> “POP3/IMAP/SMTP服务”）开启服务时生成的 SMTP 专用授权码。
• 发信人 (From Email)：严格按照格式填写，且尖括号内的邮箱必须与用户名一致。
  • 示例："VPS监控机器人" <xxxx@qq.com>
• 收件人 (To Email)：填入用来接收告警的邮箱（可以直接填与发件人相同的邮箱）。

避坑注意：如果使用相同邮箱收信，部分邮箱的防骚扰机制可能会误判。收到第一封测试邮件后，可以选择在邮箱中将该地址设为白名单/星标联系人。

填写完成后，点击 “测试”，收到测试邮件后点击 “保存”，并在右侧监控项中勾选应用此通知。

Step 5: 故障演练测试

#

完成配置后，必须在终端执行一次“拔电源”演练，验证整条逻辑闭环：

1. 手动停止数据库容器：docker stop mysql-lite
2. 观察监控面板，几十秒内（取决于设置的探测间隔）心跳线应当断开并标红。
3. 检查手机，确认是否收到了清脆的宕机告警邮件。
4. 重新恢复容器：docker start mysql-lite，确认收到了服务恢复的通知邮件。

至于监控数据对流量分析的影响

#

Uptime Kuma 本质上是一个“机器人访客”，它每隔几十秒就会对站点发起一次 HTTP 探测。

• 对于前端统计（如 Google Analytics, Umami）： 没有影响。因为 Kuma 不会模拟浏览器内核去执行页面中的 JavaScript 脚本，因此不会触发前端流量上报。
• 对于后端 Nginx 日志分析： 有巨大影响。Kuma 的高频探测会在 Nginx 容器内的 access.log 中留下海量记录。如果日后打算用 Python 读取 Nginx 日志做数据分析或用户行为挖掘，必须在数据预处理阶段，通过清洗 User-Agent 字段过滤掉 Uptime Kuma 的访问记录，否则这些高频的规律数据会成为严重的脏数据噪音，破坏统计结果。