当你自托管的服务开始多起来——网站、API、数据库、VPN、家里 NAS——一个基本问题会一直悬着：我的这些服务现在都活着吗？网站打不开的时候，是它挂了还是网络出问题？等用户来告诉你不正常，说明你已经是最后一个知道的人。Uptime Kuma 就是解决这件事的工具：一个开源的、自托管的"可用性监控与告警"平台，用各种探针定时去检查你的网站、端口、应用是否正常，一旦不可用就在第一时间通知你（邮件、Telegram、钉钉、Server 酱等）。这篇讲清它解决什么、怎么用探针类型覆盖"网站/端口/服务层面"，怎么设置告警渠道与通知策略，以及它和"性能监控（Prometheus 那种）"的边界。
一、它解决的是"服务还活着吗 + 挂了立刻让我知道"
先把监控想成两层。一层是"性能观测"：延迟/负载/吞吐随时间的曲线，给你优化依据——那是 Prometheus/Grafana 的领域。另一层是"可用性告警"：一个服务越界、不可达、返回错误码时，系统要在它影响体验之前告诉你——这正是 Uptime Kuma 的核心。很多自托管服务其实只需要后者：它们没那么多指标要看，但你需要一条"要是它 30 秒起不来就通知我"的心跳线。
Uptime Kuma 也常常作为"外部视角检查"，因为它通常部署在另一台机器/另一个网络，用真实的公网访问去探测你的服务，能发现"我这边还开着、但外网根本访问不到"这类本地视角发现不了的问题——这对于验证"反代 + HTTPS + 防火墙配合起来外网真的通"尤其有价值。它天然属于自托管运营底座里"给自己装个守夜人"的那一环。
二、探针类型：不同对象用不同的"检查方式"
Uptime Kuma 给每种服务都准备了相应探针，选择正确的探针能让监控既准又不误报。最常见的是 HTTP(s) 探针：它按你设定的间隔请求 URL，可配置"预期状态码"和"关键字包含"，把"返回 502"或"页面没有某关键字"也算作故障；TCP/Ping 探针适合检查端口是否通（如数据库端口、SSH）、主机是否可达；还有针对特定服务（如 Docker、PostgreSQL、MQTT）的探针，能深度检查"这个服务进程本身正常"而不只是端口通。
# 以 HTTP 探针为例，监控你的网站 https://example.com
# 设置项：间隔(如每 60 秒) / 预期状态码(200) / 关键字(可选)
# 当响应状态码不对或含关键字缺失，该监视器被标记为 down 并触发告警
选探针的实用经验：优先用 HTTP 探针（检查到应用层更真实），再叠加一个 TCP 探针验证关键端口；Ping 看主机存活但判断不了"这个具体服务好没好"；对越重要的服务，间隔越短越好但也要考虑激增请求对被监控方的影响。把这套"按对象选探针"的自觉做对，监控才有意义，而不是一群漂在表面、通通只测 ICMP 的死板探针。
三、告警：把"发现问题"变成"我能收到"
监控的落点是告警——如果它发现了异常却没让你及时知道，等于没有监控。Uptime Kuma 支持接入大量通知渠道：邮件、Telegram、钉钉/企业微信、Server 酱、Webhook、Discord、Slack 等。配置核心是"让告警真正能触达你并降噪"：重要的服务接你最常用的即时渠道并设较短的检查间隔，次要的可以仅记录不打扰；利用它的"恢复通知"能让你知道"它又好了"，避免一边修一边反复被轰炸。
# 告警渠道示例（思想）：为服务绑定 Telegram/企业微信通知，并开启：
# - 故障时通知 + 恢复时通知 （避免"好了"没人知道 / 持续轰炸）
# - 分组/分级：核心服务即时告警，边缘服务仅 Web/邮件记录
一个常被忽略但很现实的问题是"告警疲劳"：把所有监控都接成高感度、短间隔，会有大量无关告警，久而久之你会打开静音、最后谁出事都不看了。所以设置时要有"分级 + 降噪"的意识——核心服务严格、边缘服务宽松；同时把告警渠道、服务分组规划成"一眼能分辨轻重"的结构。监控的价值在于"该响的时候有效响一次"，而不是"哗啦啦响到没人当回事"。
四、状态页与持久化：把"可用性"公开展示，也把历史存下来
Uptime Kuma 还带一个很实用的状态页（status page）：把你各服务的实时状态以公开展示的页面呈现，可设置每个服务的公开/私有粒度，非常适合服务商、个人站主向用户透明展示"当前各服务是否在线"。同时它本身也提供历史探测记录与可用率统计，让你能回看"这个月某个服务到底稳定不"，而非只凭感觉。
# 状态页用途示例：把核心 3 个服务以公开状态页展示，其余保持私有
# 内置的可用率统计（如 30 天可用率 99.x%）可回看稳定性趋势
落地时把"它也要长久"想进去：Uptime Kuma 自己是常驻服务，它的配置、探针设置、历史与状态页都在其数据目录里，要纳入备份（否则你辛辛苦苦配的整张监控网会随实例消失）。因为它是"给你报告别人活没活的"那个角色，你若由它托管却不备份它，就有种悖论式风险——所以别省下这一步。
五、边界：它管"可用性"，性能曲线与根因交给别的工具
最后把边界摆清。Uptime Kuma 专业在"按需检查某服务是否正常 + 挂了告警"，但它的定位不是性能分析器：它不存细粒度指标、不做复杂的阈值曲线与长期容量分析。当你想知道"延迟走势、各层瓶颈、长期资源趋势"时，那仍是 Prometheus + Grafana（配合 Loki 看日志）那套指标的领域。两者不是替代、而是分工——Uptime Kuma 给你"活着吗"的实时心跳，指标栈给你"快不快、为什么"的深层画像，成熟的自托管往往两者搭配。
把定位想清后用起来的判断是：先把"哪些服务不能没人盯、挂了要立刻知道"列出来，用 Uptime Kuma 兜住这群的心跳与告警；再按需把想要长期曲线的服务接入指标监控。用这套组合，你既不会漏掉"服务挂了没人知道"，也不会把笨重的指标栈用到其实只需要心跳的场合。把它当"自托管守夜人 + 可用性门面"，它就是用最小成本让你从"最后一个知道故障"变成"第一时间被叫醒"的核心一环。
结语
Uptime Kuma 的价值，是用定时探针"检查每个自托管服务是否正常 + 在故障瞬间第一时间通知你"，并顺带提供公开状态页与历史可用率。落地要点：按对象选对探针（HTTP 优先、TCP 盯端口）；接上你最常用的即时告警渠道并设置"故障+恢复"通知；用分级与降噪避免告警疲劳；把它的配置与历史纳入备份。它的边界是"管可用性、不做性能曲线与根因分析"——与 Prometheus/Grafana 指标栈分工而非替代。让自己从"等服务用户来喊"转变为"故障先于体验被自动叫醒"，Uptime Kuma 正是这一环最小、最贴心、最自托管的答案。
