哪吒监控面板实战：部署 Dashboard、接入 Agent、钉钉告警，再配置固定公网访问

52# 哪吒监控面板实战：部署 Dashboard、接入 Agent、钉钉告警，再配置固定公网访问

前言

手里只有一台服务器时，偶尔 SSH 上去看一眼 htop、磁盘和网络并不算麻烦；可当 VPS、NAS、树莓派和测试机越攒越多，真正让人焦虑的不是"有没有监控工具"，而是故障发生以后不知道该先看哪台机器。哪吒面板吸引我的地方，就是把这些分散主机拉进同一个 Dashboard：CPU、内存、磁盘、流量、在线状态都放在一个页面里，Agent 主动上报，省得每次挨个登录。相比把监控做得多复杂，我更在意的是能不能先建立一个稳定、清楚、出了问题就知道从哪里查的基础链路。

这次我先在一台公网服务器上部署哪吒 Dashboard，完成默认账号登录和基础设置，再给被监控主机安装 Agent。过程中碰到一个很典型的问题：Agent 安装过程没有报错，但面板里就是看不到服务器，最后把启动参数里的 NZ_TLS="true" 改成 NZ_TLS="false" 后才正常出现。节点在线以后，我又继续配置钉钉机器人、通知组和告警规则，最后再用 cpolar 把 Dashboard 的 8008 Web 页面提供到公网，并切换到固定二级子域名 nezha。对我来说，这类监控系统最重要的不是"铠甲感"，而是节点真的在线、异常真的能提醒、人在外面也真的能打开面板。 只有这三层都跑通，监控才算真正开始发挥作用。

1. 哪吒面板真正解决的是什么？

哪吒面板（Nezha Monitoring）是一套开源、跨平台、自托管的服务器监控与管理面板。

它采用 Dashboard + Agent 的分离架构：

Dashboard：集中展示监控数据和管理节点；
Agent：安装在每台被监控主机上，主动上报状态。

当前介绍中提到的监控内容包括：

CPU；
内存；
磁盘；
带宽；
在线率；
进程数；
系统负载。

同时支持 Linux、Windows、macOS、ARM、OpenWrt 等不同平台。

我更愿意把它看成一个"集中看状态 + 异常告警"的轻量监控入口，而不是拿它去替代所有监控体系。和 Prometheus + Grafana 相比，它更偏向快速部署和集中查看；和 Uptime Kuma 相比，它展示的又不仅仅是 HTTP / 端口可用性。

这次实际要验证的是：

Dashboard 能访问 → Agent 能上线 → 节点状态能看到 → 告警能发到钉钉 → Dashboard 能从外网访问。

2. 先准备哪吒 Dashboard 服务端

2.1 当前环境要求

当前流程要求准备一台配置不低于：

1 核 CPU；
512MB 内存；

的公网服务器。

同时提前安装 unzip，并在防火墙或安全策略中放行：

8008

端口。

CentOS 系统使用：

shell 复制代码

sudo yum install unzip      # CentOS 7 及以下版本
sudo dnf install unzip      # CentOS 8 及以上版本

Ubuntu 或 Debian 使用：

shell 复制代码

sudo apt update
sudo apt install unzip

这里先把服务端环境准备好，再继续安装哪吒 Dashboard。

3. 安装哪吒 Dashboard

在服务端执行当前安装脚本：

shell 复制代码

curl -L https://raw.githubusercontent.com/nezhahq/scripts/refs/heads/main/install.sh -o nezha.sh && chmod +x nezha.sh && sudo ./nezha.sh

运行以后，按照终端提示继续。

这次选择的是手动安装。

等待服务端重启完成，期间不要关闭终端。

部署完成后，在浏览器访问：

http://IP:8008

页面能正常打开以后，Dashboard 这一层先算跑通。

4. 第一次登录先改默认账号信息

点击右上角登录。

当前默认用户名和密码均为：

admin

登录以后先修改密码。

默认凭据不适合长期保留，尤其后面还要继续增加公网访问入口。

5. 节点备注和展示信息可以继续补充

后面把 Agent 接入以后，可以进入编辑页面补充公开备注。

当前默认主题使用的备注内容如下：

shell 复制代码

{
  "billingDataMod": {
    "startDate": "2024-12-08T12:58:17.636Z",
    "endDate": "2024-12-08T12:58:17.636Z",
    "autoRenewal": "1",
    "cycle": "Year",
    "amount": "200EUR"
  },
  "planDataMod": {
    "bandwidth": "30Mbps",
    "trafficVol": "1TB/Month",
    "trafficType": "2",
    "IPv4": "1",
    "IPv6": "1",
    "networkRoute": "4837",
    "extra": "Einstein"
  }
}

还可以继续增加自定义字段。

回到前台以后，可以看到展示变化。

这一部分更偏向节点信息展示，不影响 Agent 是否在线，但如果服务器比较多，统一补充线路、流量、续费或备注信息，后面识别起来会更快。

6. 给被监控服务器安装 Agent

进入【服务器】页面，点击右侧【安装命令】。

根据被监控服务器的操作系统选择对应命令，安装命令会自动复制到剪贴板。

Linux 示例：

Windows 示例：

执行完成以后刷新 Dashboard。

正常情况下，被监控服务器会自动出现在列表里。

还可以编辑服务器名称。

回到前台以后，可以直接看节点状态。

点击某台服务器，可以继续查看详细信息。

当前页面还提供一键跳转终端的入口。

7. 一个真实踩坑：Agent 安装没报错，但节点就是不出现

这次真正让我停下来排查的是这里。

Linux Agent 自动安装脚本执行过程中没有报错。

但 Dashboard 里始终看不到对应服务器。

当前这次采用的处理，是修改 Agent 启动参数，把：

shell 复制代码

NZ_TLS="true"

改成：

shell 复制代码

NZ_TLS="false"

也就是关闭 TLS。

当前说明给出的判断是：

NZ_TLS=true 用于服务端已经配置有效 TLS 证书的情况；
默认 Docker 或二进制部署通常不包含 HTTPS，因此这里改成 false；
即使外层通过 Nginx 反向代理做 HTTPS，当前说明仍建议 Agent 连接内部 HTTP 地址。

这次修改为 false 后，节点成功出现在面板里。

这个过程比"一键安装成功"更值得保留，因为以后如果安装没报错、Dashboard 却没有节点，我会先检查 Agent 的连接参数，而不是直接重装一遍。

8. 节点在线以后，再配置钉钉机器人告警

监控页面能看只是第一步。

真正减少"等用户反馈才发现故障"的关键，是异常发生以后能主动通知。

这次使用钉钉群自定义机器人。

进入钉钉群设置，添加机器人。

选择【自定义】机器人。

当前示例机器人名称使用：

哪吒

并按页面选择关键词触发等安全方式。

创建完成以后，复制 Webhook URL。

这里的机器人 Token 属于访问凭据，不适合公开传播。

9. 哪吒里的钉钉通知配置

当前通知配置示例如下。这里保留现有页面配置结构，其中 Webhook 使用的是 xxxxxxxxxxxxxxxxx 占位值。
点击展开/收起

获取 URL 参数

创建机器人：在钉钉群的设置中添加机器人，选择自定义关键词方式。
获取 Webhook URL：创建完成后获得。

通知配置：

名称：哪吒探针小跟班
URL：

接着添加通知分组。

通知组这一步很关键，因为后面的告警规则需要真正关联到通知组，才能把消息送出去。

10. 配置 CPU 告警规则

进入告警规则配置。

当前测试填写的规则是：

shell 复制代码

[{"type":"cpu","max":10,"duration":5,"cover":0,"ignore":{"1":true,"2":false}}]

这里有一个现有记录差异需要留意：

文字说明写的是"CPU 大于 20% 就告警"；
当前 JSON 中 max 的实际值是 10。

这两处记录都按现有内容保留。真正复现时，应根据自己希望的阈值确认最终规则，不要把说明文字和 JSON 参数混为一谈。

同时一定要选择对应通知组。

当前测试中，钉钉群机器人已经收到告警。

这一步真正验证的是：

哪吒监控规则 → 通知组 → 钉钉机器人 → 告警消息

已经走通。

11. 其他告警规则可以继续按需要增加

当前材料还给出了几组规则示例：

离线报警：[{"Type":"offline","Duration":10}]
CPU 过高：[{"type":"cpu","max":90,"duration":300}]
内存过高：[{"type":"memory","max":90,"duration":300}]
硬盘占用过高：[{"type":"disk","max":80,"duration":43200}]

这些规则覆盖了在线状态、CPU、内存和磁盘。

实际使用时，阈值不必照搬。监控规则太敏感会不断打扰，太宽松又失去意义，最好根据自己的服务器负载和业务特点慢慢调整。

12. 本地 Dashboard 能用了，再考虑外网访问

如果 Dashboard 本身部署在公网服务器，当前 8008 页面已经可以通过服务器地址访问。

但当前流程继续使用 cpolar 给这个 Web 页面建立公网入口。

这里 cpolar 的职责很明确：

只负责把哪吒 Dashboard 的 8008 Web 页面提供到公网。

节点采集、Agent 上报、告警判断和钉钉通知仍然由哪吒面板自己完成。

13. 安装 cpolar

执行当前安装命令：

shell 复制代码

sudo curl https://get.cpolar.sh | sh

安装完成后检查服务状态：

shell 复制代码

sudo systemctl status cpolar

服务正常以后，通过主机 IP + 9200 打开 cpolar Web 管理页面。

当前页面同时写到：

http://ip:9200

以及链接目标：

http://localhost:9200/

实际访问时，以当前环境真正能够打开的地址为准。

14. 给哪吒 Dashboard 创建随机公网地址

进入【隧道管理 → 创建隧道】。

当前配置为：

隧道名称：nezha
协议：http
本地地址：8008
域名类型：随机域名
地区：China Top

创建以后，到在线隧道列表查看生成的公网地址。

从其他电脑或移动设备访问。

哪吒 Dashboard 可以正常打开。

这一层确认的是：

哪吒 Dashboard 8008 → cpolar 随机公网地址 → 外部浏览器。

15. 长期使用再切换到固定二级子域名

随机地址适合先验证。

如果这个监控面板会长期从外部访问，再使用固定二级子域名会更省事。

进入预留页面。

选择保留二级子域名。

当前记录为：

地区：china Top
二级子域名：nezha

然后回到【隧道管理 → 隧道列表】，找到对应隧道并编辑。

修改为：

域名类型：二级子域名
Sub Domain：填写已经保留的二级子域名
地区：China Top

点击更新。

更新完成以后，在线隧道列表中的随机地址会切换成固定二级子域名形式。

最后从其他设备访问。

页面可以正常打开。

总结

哪吒面板对我来说真正有价值的地方，不是"给服务器穿上铠甲"这种说法，而是把原来分散在不同机器上的状态放到一个地方看，并且异常时能主动提醒。

这次实际跑通的主线是：

公网服务器 → 哪吒 Dashboard 8008 → 默认账号登录并修改密码 → Agent 安装 → NZ_TLS 排错 → 节点上线 → 钉钉机器人 → 通知组 → CPU 告警 → cpolar → 8008 → 随机公网 → 固定二级子域名 nezha。

其中最值得记住的反而是几个容易踩坑的地方：

Agent 安装没有报错，不代表节点一定已经成功接入；
当前这次把 NZ_TLS="true" 改成 NZ_TLS="false" 后，节点才正常出现；
CPU 告警说明文字写 20%，但示例 JSON 的 max 是 10，真正部署时要按自己的阈值核对；
通知规则要关联通知组，否则钉钉配置完成也不等于一定会收到消息；
cpolar 只负责 Web 入口，不参与 Agent 上报和告警逻辑。

对多台 VPS、NAS、树莓派或测试机来说，我更愿意先把"所有节点都能稳定上线"和"告警真的能收到"做扎实，再去调整主题、展示字段和公网入口。监控的目的不是让面板更漂亮，而是出问题时能比用户更早知道。