三台 VPS 的自托管监控与告警链路：哪吒监控 + Uptime Kuma + 自建推送中继

摘要
服务器只有一台的时候，监控可有可无；手里有三台不同云厂商的 VPS、上面跑着十来个自托管服务之后，问题就变了：任何一台机器半夜宕机、流量跑满或者服务悄悄挂掉，你都希望第一时间知道，而不是第二天打开网页才发现。
本文记录我给自己的三台服务器（腾讯云、甲骨文云、华为云各一台）搭建的一套完全自托管的监控与告警链路：哪吒监控负责主机指标与探针、Uptime Kuma 负责服务可用性、自建 ntfy 和微信推送中继负责把告警送到手机上。整套链路不依赖任何第三方 SaaS，并重点复盘几个只有实际部署后才会遇到的坑。
一、整体结构：采集、判断、触达三层解耦
我把这套系统分成三层：
采集层：三台机器上的哪吒 Agent + Uptime Kuma 探针
│
判断层：哪吒面板（离线 / 负载 / 流量规则）+ Kuma（HTTP / Push 监控）
│
触达层：ntfy 自建推送 + 企业微信群机器人 + 微信公众号客服消息中继
分层的意义在于替换成本低：哪天想换掉某个推送渠道，只动触达层；新增一台机器，只需要在采集层装一个 Agent。告警规则集中在判断层配置，不散落在每台机器的脚本里。
二、哪吒监控部署：一个域名解决不了所有问题
哪吒面板用 Docker 部署在腾讯云的机器上，Nginx 反向代理加 Let’s Encrypt 证书。真正花时间的不是安装，而是域名接入方式：
Agent 上报走 gRPC 长连接。如果把面板域名挂在 CDN 代理后面，代理会干扰 gRPC 的 TLS 连接，Agent 表现为反复掉线重连。
浏览器访问面板则适合走 CDN，有缓存和防护收益。
最终我采用了双域名架构：一个域名 DNS 直连、专门给 Agent 上报用；另一个域名开 CDN 代理、只给浏览器访问面板。两个域名指向同一个面板服务，职责彻底分开。这个问题如果不在部署时想清楚，排查起来很痛苦：面板能打开、端口也通，就是 Agent 永远连不上。
Agent 首次连接时自动注册到面板，之后在面板里改名、分组即可。三台机器分别位于国内、首尔和香港，正好也能顺带观察不同线路的延迟和丢包。
三、告警规则：宁可少报，不要报到麻木
监控系统最常见的死法不是漏报，而是误报太多，最后把通知全关了。我的规则刻意保持克制，只保留三类：
离线通知：探针断开约 30 秒判定离线。阈值太短会把网络抖动全变成告警，太长又失去时效，30 秒左右是个人使用的平衡点。
高负载告警：1 分钟负载超过 4 触发。我的机器都是 1～2 核，这个阈值意味着负载已经明显超过机器的处理能力，而不是正常波动。
高入站流量告警：入站速度超过 10MB/s 触发。小规格机器的正常流量很低，突然的大入站要么是被刷，要么是某个服务失控，都值得立刻看一眼。
所有规则都设置为“状态变化时触发一次”，恢复时再发一条恢复通知。持续重复轰炸只会训练人忽略告警。如果某条规则一周误报两次以上，我就回头改阈值，而不是忍受它。
四、Uptime Kuma 补主机监控的盲区
哪吒看的是主机维度：CPU、内存、网络、在线状态。但主机活着不等于服务可用——容器可能退出了，Nginx 配置可能写错了，证书可能过期了。这一层由部署在甲骨文云机器上的 Uptime Kuma 补上，跨机器部署本身也避免了“监控和被监控对象一起宕机”。
它有两种监控方式值得说：
HTTP 监控：每 60 秒请求一次我的个人主页，状态码异常即告警。这是最基础的可用性探针。
Push 型监控：有些东西没有 HTTP 入口可探，比如一个基于 UDP 的代理服务。这类目标改用反向思路：被监控对象每分钟主动向 Kuma 的 Push 地址打一次卡，超时没收到心跳就判定异常。把“探活”变成“签到”，很多原本测不了的东西就都能测了。
五、触达层：自建推送中继的两个现实约束
告警发不出去等于没监控。我的触达通道有三条，互为备份：
ntfy：自建服务，监控脚本和各类定时任务统一往一个 alerts 主题推纯文本消息，手机上装 App 订阅即可。这是最主力的一条。
企业微信群机器人：哪吒面板原生支持，配置 Webhook 即可，适合发结构化的告警卡片。
微信公众号客服消息中继：我自己用 Flask 写了一个小服务部署在服务器上，通过公众号的客服消息接口把告警转成微信消息，还加了颜色约定——告警橙色、恢复绿色，扫一眼就知道是出事还是没事了。
最后一条有个必须提前知道的平台约束：客服消息只能在用户与公众号最后一次互动后的 48 小时内下发。我的解法是在公众号菜单里放一个“续期”按钮，每隔一两天点一下刷新互动时间，把通道续上。做个人告警系统时，这类平台规则比代码本身更影响可用性，值得在选型时就查清楚。
另外一个细节：所有定时任务的通知都同时发聊天渠道和 ntfy，两条通道内容一致、互为镜像。这样任何一条通道出问题，另一条还能把消息送到；推送本身失败也要再通过另一条通道报错，避免“告警系统静默死亡”。
六、复盘：三个经验
监控必须跨机器部署。面板、探针、推送服务不要全压在一台机器上，否则最需要告警的那次故障，恰好是整套系统一起消失的那次。
先解决连通性模型，再装软件。gRPC、WebSocket 这类长连接和 CDN 代理的兼容性问题，在画域名和入口架构时就要确认，装完再排查的成本高得多。
告警的信噪比决定系统寿命。规则少而准、恢复通知明确、误报及时修阈值，这套系统才能跑上几个月还不被主人亲手关掉。
总结
这套链路的成本只有几台本来就在用的 VPS 和一点配置时间：哪吒管主机，Kuma 管服务，ntfy 和自建中继管触达。对个人自托管玩家来说，监控不是大厂的专利，把采集、判断、触达三层拆开，每层用最简单的工具实现，就能得到一套出故障时真的能找到人的系统。