为什么这篇评测值你 10 分钟

上个月，我们团队给一个电商客户做故障复盘。客户凌晨 3 点收到告警，登录 Grafana 后找不到 CPU 飙高的具体容器，在 PromQL 里写了 20 分钟查询，最后发现是 rate(container_cpu_usage_seconds_total[5m]) 的标签选错了。事后客户CTO 说了一句让我记到现在的话：“监控工具不是看颜值，是看你在凌晨三点能不能 30 秒定位到问题。”

这个场景直接决定了本文的态度：选型不是选最强，而是选最快能让你从"收到告警"走到"找到根因"的那条路径。今天的主角是三套开源方案——Prometheus+Grafana组合、Uptime Kuma、Netdata，它们的定位完全不同，但国内开发者社区里经常被放在一个选型池里讨论。

维度 Prometheus + Grafana Uptime Kuma Netdata
安装复杂度 高（多组件 + 配置） 极低（单容器） 中（单容器 + agent）
数据模型 时序数据库（自定义标签） 状态记录（可用性） 指标快照 + 历史窗口
告警触达 需额外接入 Alertmanager 内置 90+ 通知渠道 内置 webhook + 邮件
指标覆盖深度 需自己写 exporter 仅 HTTP/TCP/Ping 600+ 内置仪表盘
存储占用（30天，10台主机） ~8-15 GB ~100 MB（纯文本） ~2-4 GB
学习曲线（从零到第一张图表） 2-4 小时 10 分钟 30 分钟
适用规模 100+ 节点或复杂微服务 <50 个端点 1-50 台单机
社区维护活跃度 顶级（CNCF 毕业） 活跃（Node.js 社区） 活跃（近两年增长快）

数据来源：我们团队在 4 台 4C8G 的 ECS 上跑了 45 天，混合 15 个 HTTP 端点 + 3 个 MySQL + 2 个 Redis。

Prometheus + Grafana：监控世界的"瑞士军刀",但也是"时间黑洞"

我见过太多团队从 Uptime Kuma 迁移到 Prometheus 后的第一反应是兴奋——Grafana 的图表确实漂亮，dashboard 模板能直接 import。但第二个月开始，他们会在凌晨被自己的告警规则吵醒，因为 up == 0 对 Prometheus 来说只是"目标不可达"，而不是"服务挂了"。这中间差了一个 for: 5m 参数和一次告警抑制配置。

Day 15 我们给客户部署时，Prometheus 单节点吞了 180 万条/天的指标，内存稳定在 2.3 GB。这个数据并不惊艳，但真正的问题在 30 天后暴露：所有业务指标和基础指标混在一个 TSDB 里，查询变慢到 4-6 秒——不是 Prometheus 不行，而是我们没有提前做 recording rule 和 label 降基。

它的强项必须承认：

  • 数据模型是标签化的，能回答"所有状态码为 500 的请求在哪个实例上"这类问题
  • Alertmanager 的静默 + 分组 + 路由机制，是生产环境告警的标配
  • Grafana 的变量模板（$instance, $app）让同一个 dashboard 可以复用到 30 套环境

但我也要承认 Prometheus 不如 Uptime Kuma 的地方：对"这台机器还活着吗"这种简单问题，它需要你写 PromQL、配置 blackbox exporter、定义 probe 目标——而 Uptime Kuma 里一个 HTTP check 只需填 URL 和间隔。我们团队测过，同样的监控目标，Uptime Kuma 从零到收到第一条告警短信用了 11 分钟，Prometheus 花了 2 小时 47 分（包含看文档）。

Uptime Kuma：颜值与快感并存，但别指望它回答"为什么"

单看 UI，Uptime Kuma 是这三者里唯一会让我觉得"像现代产品"的。Status page 直接对外展示，暗色主题，PWA 支持手机推送，这些细节对个人站长或小团队来说非常加分。我们的一个外包客户，就用它监控了 7 个客户项目的接口存活，第 2 周就反馈"终于不用每天早上手动 curl 了"。

它的告警渠道覆盖了我见过的所有主流 IM：钉钉、飞书、企业微信、Telegram、Discord，加上 Webhook，基本无死角。

局限也清晰：

  • 只有可用性数据，没有性能趋势。"响应时间从 200ms 涨到 2s"它只会显示为黄灯，但你想看 30 天内的 p95 趋势，对不起，没有
  • 数据库用 SQLite，监控端点超过 200 个后，状态切换历史会拖慢查询（我们实测 500 个端点时，后台操作卡顿到 3 秒以上）
  • 无 agent 体系，无法监控进程级指标或日志

说实话，Uptime Kuma 适合的场景是"我只需要知道服务挂没挂，挂了通知我"。它不是监控系统，它是报警器。

我们团队内部有个不成文的规矩：给客户搭监控，先问一句话——“如果告警响了，你知道下一步干嘛吗？” 如果客户摇头，优先推 Uptime Kuma 加简单手册；如果客户点头且能说出"查 CPU、查慢日志、查依赖"，再上 Prometheus。

Netdata：实时性怪兽，但历史数据是短板

第一次接触 Netdata 是在第 2 周给客户排查慢查询时，装完 apt install netdata 后 30 秒，浏览器打开 19999 端口，那种扑面而来的实时图表刷新速度让我愣了一下——我见过很多监控工具的"实时"，都是 5 秒刷新一次，Netdata 是每秒更新 10 个点，而且每个指标都自带解释。

它的优势非常聚焦：

  • 零配置的深度：它自动发现 MySQL、Redis、Nginx、Docker 等 30+ 常用服务，并生成对应仪表盘
  • 单机资源占用极低：我们实测 4C8G 机器上，netdata 进程占用 120-180 MB 内存，CPU 0.3-0.5%，对生产环境几乎无感
  • 告警规则开箱即用：内置 100+ 条，比如磁盘满、内存压力、TCP 重传率

但它的致命伤在 Day 30 显现：Netdata 的默认存储是 round-robin 数据库，保留 1 小时 1 秒级数据 + 1 年 1 分钟级数据，但这意味着你想查看"3 天前的 CPU 峰值时同时发生了什么"时，它只能给你分钟级精度。对于故障排查来说，分钟级往往不够——你想知道的是那 10 秒内发生了什么。

还有一点要泼冷水：Netdata 的告警通知配置在 UI 上操作体验很差，需要手动填 webhook 格式，没有 Kuma 那种可视化编排。

不过呢，我们团队现在给客户做混合部署时，Netdata 是每个节点的标配——它负责"现场直播"，Prometheus 负责"历史回放"。这两者不冲突，反而互补。

选型决策树：先问自己三个问题，别先问工具

我们做咨询时，会把监控选型压缩成三个问题，按顺序回答：

  1. 你现在有多少台机器/端点？

    • < 20 个端点，且不需要历史趋势：Uptime Kuma
    • 20-100 个端点，需要单机性能细节：Netdata
    • 100+ 端点或微服务架构：Prometheus + Grafana

  2. 告警响应的第一责任人是谁？

    • 运维人员：任何工具都可以，但 Prometheus 需要培训
    • 开发负责人兼运维：Netdata（图表直观，能自我定位）或 Uptime Kuma（简单）
    • 业务方看状态：Uptime Kuma 的 Status page 直接分享

  3. 你们是否已经用 Grafana 做可视化？

    • 是：跳过 Netdata，直接用 Prometheus + Grafana
    • 否：Netdata 自带 UI 足够了，不需要额外图表系统

个人看法：国内大量团队在 Prometheus 上投入的维护成本被严重低估。“用起来免费，维护起来不免费”——我们客户平均每月要花 6-8 小时在维护告警规则、调整 recording rule、清理 TSDB 上。 对于 50 台机器以内的团队，Netdata 或 Kuma 在 30 分钟就能达到 80% 的监控效果，剩下的 20% 复杂度根本不需要。

还有一个反面教训：有个客户为了"统一监控栈"，把 5 台机器的监控从 Zabbix 迁到 Prometheus，迁移 + 调优花了 2 周，期间漏了一次磁盘满告警，导致数据库写入失败。血泪教训：监控工具迁移的风险远高于收益，除非当前方案完全不能用，否则别动。

混合推荐的实战配置

说实话，我们团队最终给大多数客户的落地配置是这样的：

  • 每台机器跑一个 Netdata agent（实时观测 + 快速定位）
  • 一个轻量 Uptime Kuma 实例（对外可用性监控 + 状态页展示 + 告警通知）
  • 如果客户有容器平台（K8s），才上 Prometheus + Grafana（指标持久化 + 容量规划）

这套组合的存储成本极低（30 天约 5-7 GB），告警延迟控制在 15 秒内，且每个层的工具都是各自领域的简单方案，不需要专职运维。

回头看，Prometheus 生态的复杂度是它自己的护城河，也是它的诅咒。

你团队的监控现状是什么？有没有过被告警轰炸但找不到根因的深夜？