状态：在用 · 2026-04 至今 · 暂时不换
速读#
哪吒解决的是多机状态总览和告警，不是为了做一套复杂监控平台。几台机器的规模下，Prometheus + Grafana 太重，自写脚本又不值，哪吒的复杂度刚好；真正的纪律是宁可少报，也别滥报。
它解决什么#
| 能力 | 具体 |
|---|---|
| 总览 | CPU、内存、流量、在线状态，一个网页看全 |
| 告警 | 离线、负载超阈值时主动找我 |
| 定位 | 工作流里的「可观测」那一面——图外盯整张图的那只眼 |
没有它，整套链路谈不上可信赖：出了事只能靠人想起来去查。服务级守护能把进程拉回来，但「拉回来过」这件事得有人告诉我——自愈了还不知道，就少了一次复盘机会。
部署方式也顺眼：每台机器跑一个 agent，主动出站连到面板，被监控的机器不用为监控开任何入站端口。和用出站隧道做内网穿透是同一个方向——凡是能出站解决的连接，就别开入站的缝。
有一件事得想在前面：面板自己也是台服务。它挂了，所有告警跟着失明——而「告警系统挂了」恰恰是没有告警的。所以面板要放在独立于被监控机器的位置，别让监控者和被监控者共命运；这是监控系统的第一课，规模再小也适用。
为什么不是其它#
多机监控从一台变四五台之后就是刚需，哪吒是我固定下来的那一个；开源仓库：nezhahq/nezha（Go，能翻源码，不是黑盒）。
| 选项 | 取舍 |
|---|---|
| Prometheus + Grafana | 太重。几台机器用不上那套灵活度，搭 + 维护得不偿失 |
| 自写轮询脚本 | 重复造轮子，而且没人长期维护 |
| 哪吒 | 开源、界面能看、Docker 一把梭、告警规则够用 |
不是它最强，是复杂度和我的需求匹配。监控工具我不要自由度，要省心——和选框架时「先问场景要自由还是定型」是同一类判断。
什么情况下不该选它#
- 要的是指标深度：按标签聚合、任意历史区间查询、自定义大盘——那是 Prometheus + Grafana 的地盘。哪吒的历史数据够回看趋势，不够做分析。
- 只关心服务通不通：拨测 URL、证书到期、端口存活这类可用性监控，Uptime Kuma 一类更对口。哪吒看的是机器的状态，不是业务的死活——「机器健康」和「服务可用」是两个问题，别指望一个工具两头包。
- 只有一台机器：为单机搭面板意义不大，
htop加一条离线告警就够。总览的价值从第二台机器才开始。
另外，面板页可以公开，但公开前想一下：机器数量、流量曲线、地域分布本身都是信息。我的原则是能不公开就不公开——监控是给自己看的，不是站点装饰。
会不会换#
暂时不会。
监控一旦告警规则调好，换的成本就不值：新工具要重配规则、重新养信任，中间还有监控盲区。这种「调好了就别动」的工具，稳定性比更先进重要。
最容易玩废的一条：不狼来了#
规则太敏感 → 消息多到直接静音 → 监控废掉。
人一旦嫌烦整体静音，真出事也收不到。所以阈值上我反复验的是同一句话：宁可少报，也别滥报。
负载阈值定多少、离线多少秒才报、要不要区分网络抖动和真宕机——都按「报出来的我都信」来调。这和 fail2ban 阈值同源：任何自动响应机制，误触发多了人就会整体关掉它。
监控的价值不在报得多，在报出来的我都信。哪吒留下，一半因为省心，一半因为能把告警调到「不狼来了」。