Nezha 介绍与选型指南

目标：作为《Nezha》专栏首篇，讲清 Nezha（哪吒监控）的定位、dashboard+agent 架构与选型结论。全部结论基于真实环境实测：dashboard v2.3.18 + agent v2.3.5，双 Ubuntu 22.04 服务器（systemd 独立环境模拟），部署验证、指标上报、告警触发全链路跑通。安装细节见《Nezha 安装部署指南》，参数说明见《Nezha v2.3.18 配置参数详解》，日常维护见《Nezha 运维手册》。

一、Nezha 是什么

Nezha（哪吒监控）是一款开源（Apache-2.0 协议）的服务器监控与探针系统，由 GitHub 组织 nezhahq 维护，是国内自托管监控领域最流行的方案之一。它的核心能力：

• 多机探针监控：在一台中心服务器部署 dashboard（面板），其余被监控机器安装轻量 agent（探针），agent 通过 gRPC 持续上报 CPU、内存、磁盘、网络、负载、连接数、进程数、GPU、温度等指标；
• Web 面板：内置管理后台与世界地图风格的机器总览页，支持多用户、多管理员角色；
• 告警引擎：支持基于指标阈值的持续采样判定（如"CPU 连续 3 个采样点超过 50%"）、循环区间流量（月度流量超额）、离线告警，以及告警触发任务（告警后在目标机器上自动执行命令）；
• 计划任务：在指定机器上批量执行命令（备份、重启服务等），可手动触发；
• 运维增强：WebSSH/Web 终端、DDNS、NAT 穿透端口映射（均可按需关闭）。

一句话定位：面向"多台服务器资产"的轻量级可观测与运维工具，重点在"看住一堆机器"而不是"看住一个服务"。

二、架构：一个 dashboard，N 个 agent

Nezha v2 的架构非常简单，只有两个组件，且只需要开放一个端口：

                    ┌──────────────────────────────┐
  浏览器 ──HTTP──▶  │  dashboard（中心面板）          │
                    │  - HTTP API + 静态页面 (8008)  │
  agent ──gRPC───▶  │  - 同端口复用 gRPC 服务        │
                    │  - SQLite/MySQL/PostgreSQL     │
                    └──────────────────────────────┘
                       ▲            ▲            ▲
                       │ gRPC 上报   │            │
                  ┌────┴───┐   ┌────┴───┐   ┌────┴───┐
                  │ agent 1│   │ agent 2│   │ agent N│
                  └────────┘   └────────┘   └────────┘

实测要点（来自《Nezha 安装部署指南》的真实部署）：

• 单端口复用：dashboard 默认监听 8008，HTTP 面板与 agent 的 gRPC 连接共用这一个端口（HTTP/2 多路复用），防火墙只需放行一个端口；
• agent 是推模型：agent 主动向 dashboard 建立连接并上报，被监控机器无需入站端口，天然适配 NAT 后的内网机器；
• 存储轻量：默认 SQLite 单文件（实测为 data/sqlite.db），小规模部署（几十台机器）完全够用，v2.3.x 亦支持 MySQL/PostgreSQL；
• 双端独立版本：dashboard 与 agent 版本号独立演进（实测时 dashboard 为 v2.3.18、agent 为 v2.3.5），老版本 agent 可以连接新版 dashboard，但新功能（如指标告警的流式采样）依赖双端版本对齐——实测发现 v2.3.5 agent 配 v2.3.18 dashboard 时，指标类告警的采样呈间歇性工作，这在选型后运维时需要留意（详见《Nezha 运维手册》升级章节）。

三、横向对比：Beszel / Uptime Kuma / Glances

这四个工具常被放在一起比较，但定位其实不同。下表为基于实际部署体验的对比（Beszel、Uptime Kuma 的部署实测见站内对应专栏）：

几点实测后的补充说明：

• Nezha vs Beszel：两者都是"中心 + 探针"的服务器监控。Beszel 更极简（部署快、UI 清爽、几乎零配置），但功能面窄；Nezha 功能密度明显更高——告警可以联动在目标机器上执行脚本（实测验证过该链路）、有计划任务和 Web 终端，更接近"轻量运维平台"。如果只需要"看 CPU/内存/磁盘"，Beszel 更省心；如果要"监控 + 告警 + 自动处置"，Nezha 更合适；
• Nezha vs Uptime Kuma：完全是互补关系，不是替代。Uptime Kuma 擅长从外部"拨测"你的服务（HTTP 状态码、证书到期、TCP 端口），Nezha 擅长从机器内部看资源与进程。生产环境常见组合是两者并用，互链见《Uptime Kuma 介绍与选型指南》；
• Nezha vs Glances：Glances 没有"中心面板 + 多机聚合 + 告警中心"这一层（导出到 InfluxDB 再配 Grafana 是另一条重路线）。管多台机器时 Nezha 开箱即用得多。

四、选型结论

基于实测，给出如下选型建议：

1. 有 3 台以上服务器（VPS/云主机/内网机）想统一监控 → 选 Nezha。单端口部署、agent 推模型、原生中文、告警与触发任务一体化，综合体验最好；
2. 只要最简单的资源监控、追求极低维护成本 → 选《Beszel Docker Compose 部署指南》中的 Beszel；
3. 核心诉求是服务可用性（URL/端口/证书） → 选 Uptime Kuma（见《Uptime Kuma 介绍与选型指南》），可与 Nezha 并用；
4. 只是临时看单台机器的资源 → Glances 足够，不必引入中心节点；
5. 需要告警后自动处置（自动重启服务、自动清理磁盘等联动脚本） → 这是 Nezha 独有的差异化能力（告警触发任务），实测链路真实可用。

五、需要注意的点（实测视角）

选型前应当了解的几个真实短板：

• 版本兼容要留意：dashboard 与 agent 独立发版，实测老 agent 配新 dashboard 存在指标采样间歇性问题，生产环境建议双端同版本部署（升级方法见《Nezha 运维手册》）；
• 默认口令必须首改：全新部署的 dashboard 默认账号为 admin / admin（实测确认），首次登录必须立即改密，且面板暴露公网时建议置于反代 + HTTPS 之后；
• v1 到 v2 是大版本跨越：网上大量教程基于 v1（旧版主题、配置、告警语法均不同），查资料时务必确认是 v2 语法；
• Webhook 出站有安全限制：v2.3.x 出于 SSRF 防护，通知 Webhook 禁止指向私网/回环地址（实测确认），将告警对接内网系统时需经由公网可达的中转端点，或改用官方支持的通知渠道类型。

六、参考链接

1. GitHub 仓库（架构与协议说明）：https://github.com/nezhahq/nezha
2. Dashboard Releases（v2.3.18 版本核实）：https://github.com/nezhahq/nezha/releases
3. Agent 仓库与 Releases（v2.3.5 版本核实）：https://github.com/nezhahq/agent
4. 站内延伸：《Nezha 安装部署指南》——Docker Compose 与二进制两种部署方式的全流程实测。