自建监控 Uptime Kuma：监控别人之前，先确保自己能被监控

自建服务多了以后，第一个要监控的其实是「监控本身」。Kuma 轻量好用，但如果它和被测服务在同一台机器上，机器挂了就一起沉默。

所以架构上至少要有「外部探针」：另一台机器或第三方心跳检测。

先说结论

监控项按「用户视角」设计，通知要有优先级，监控本身要有外部兜底。

• 监控关键路径（首页、登录、API），不做无意义 ping
• 通知分级：致命走电话/推送，一般走邮件
• 用外部心跳服务监控 Kuma 自己
• 为维护窗口设置静默，避免误报

先把问题说清楚

监控项过多会导致「告警疲劳」：真正出事时没人在意。建议从 5 个以内核心项开始。

Kuma 支持状态页，可以对外展示服务可用性，也是给自己看的「服务清单」。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 部署容器，设置管理员与通知渠道
• 先加三类监控：站点首页、关键 API、数据库端口
• 配置重试次数与超时，降低网络抖动误报
• 开启状态页，列出对外服务
• 用第三方心跳（如 healthchecks）监控 Kuma 自身

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 用 ping 当唯一监控：端口挂了也可能通
• 重试 0 次：网络抖一下就告警
• 所有告警都发同一个渠道：久了就无视
• 监控与业务同机：一起挂

最后补两句

监控的目的不是「知道挂了」，而是「在用户发现之前知道」。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。