Netdata不只是CPU和内存图表：节点、日志、告警和异常都集中在一个页面里

Netdata不只是CPU和内存图表：节点、日志、告警和异常都集中在一个页面里

前言

NAS真正让人不放心的地方，往往不是"今天能不能打开"，而是它长期7×24小时运行以后，CPU、内存、磁盘、网络这些状态到底有没有悄悄变化。平时一切正常时很少有人主动去看，等到卡顿、服务异常甚至掉盘，才开始回头找原因。

这次我在飞牛NAS上部署Netdata，先通过SSH确认Docker环境，再用官方镜像启动监控服务。和Prometheus+Grafana那种需要自己拼采集、存储和仪表盘的方案相比，Netdata更强调安装以后直接进入现成的可视化界面。

后面的实际使用我继续看了主页、节点、监控指标、日志、自定义仪表盘、系统警告、异常指标和AI相关入口。这里我只写页面实际展示到的功能，不把"所有NAS硬件和Docker容器都一定能完整采集"写成无条件成立的结论。

最后再把Netdata页面提供给外部设备查看。整篇真正要跑通的是飞牛NAS → Docker → Netdata仪表盘 → 监控页面 → 外部访问 这条链，同时把本地端口1999/19999的不一致和宿主机监控范围讲清楚。

这类监控工具真正有价值的地方，也不是让仪表盘一直开着，而是设备出现卡顿、负载异常或服务不对劲时，手里能有一个统一入口去看指标、日志和告警，而不是临时再去回忆该敲哪些命令。

1 Netdata适合解决什么问题

NAS平时最容易被忽略的，不是文件能不能存进去，而是设备长期运行时的状态变化。

真正需要看的通常包括：

• CPU负载；
• 内存使用；
• 磁盘与IO；
• 网络流量；
• 系统告警；
• 异常波动；
• 多节点状态。

Netdata的特点是把这些信息集中到一个Web仪表盘里。

它更适合：

想快速看系统运行状态，但不想先搭一整套Prometheus+Grafana的人。

2 项目介绍里的"全能监控"不要直接等同于本次实测

Netdata本身强调实时监控、自动发现、告警和异常检测。

但这篇实际展示的是：

• Netdata容器启动；
• 首次登录；
• 主页面；
• 添加节点；
• 监控指标；
• 日志；
• 自定义仪表盘；
• 系统警告；
• 异常指标；
• AI相关入口。

所以正文只确认：

这些页面和功能入口已经实际打开。

至于某台NAS上的全部硬件传感器、全部Docker容器、温度信息是否都能完整采集，还取决于部署参数和宿主机权限。

3 先在飞牛NAS开启SSH

进入飞牛设置开启SSH：

继续进入对应页面：

完成以后通过终端连接：

后面的Docker操作都从这里继续。

4 检查Docker环境

执行：

docker -v 
systemctl status -v

也可以在飞牛主页直接确认Docker状态：

代码保持原样。

真正需要确认的是：

后面的Docker pull和docker run能够正常执行。

5 拉取Netdata镜像

执行：

 sudo docker pull netdata/netdata

这一步直接使用：

netdata/netdata

作为镜像。

6 启动Netdata容器

执行：

sudo docker run -d --name netdata -p 19999:19999 --restart always \
    -v netdataconfig:/etc/netdata \
    -v netdatalib:/var/lib/netdata \
    -v netdatacache:/var/cache/netdata \
    netdata/netdata

这条命令里最关键的参数包括：

• 容器名：netdata
• 端口映射：19999:19999
• 重启策略：always
• 配置卷：netdataconfig
• 数据卷：netdatalib
• 缓存卷：netdatacache

这三个Volume至少可以让Netdata自己的配置、数据和缓存不只停留在容器临时层里。

7 这里有一个很明显的端口不一致

Docker命令明确写的是：

19999:19999

后面的cpolar配置也使用：

19999

但本地访问文字却写成：

http://飞牛IP:1999

页面：

所以这里不能把1999和19999混成同一个端口。

按Docker映射关系判断，本地服务入口应重点核对：

19999

如果照着部署打不开，第一件事就是确认：

• 容器实际监听端口；
• 宿主机映射端口；
• 浏览器访问地址。

8 当前Docker命令没有展示完整宿主机挂载

这份启动命令里只挂载了Netdata自身的三个Volume。

没有展示常见的宿主机监控挂载，例如：

• /proc
• /sys
• /etc/os-release
• Docker Socket
• 其他宿主机目录

这意味着：

不能只根据"Netdata页面打开了"就推导出NAS宿主机和全部Docker容器指标一定已经完整采集。

如果后面发现某些宿主机指标缺失，应优先回头检查容器权限和挂载范围。

9 第一次进入Netdata

页面：

首次登录需要完成一系列初始化。

这里先填写邮箱：

10 获取随机会话ID

在终端执行：

docker exec netdata cat /var/lib/netdata/netdata_random_session_id

结果：

继续：

这一步用于后续首次登录流程。

11 邮箱确认

邮件已经发送：

点击继续访问：

继续页面：

12 完成基础信息选择

登录以后继续选择基础信息：

完成后进入Netdata主页面：

做到这里，可以确认：

浏览器 → Netdata Web界面

已经可以正常进入。

13 主页集中展示当前监控信息

主页面：

这里的意义是把分散的系统指标集中到一个入口。

相比只用SSH临时跑top、free或df，Web仪表盘更适合持续观察趋势。

14 继续添加节点

页面：

在准备加入监控的节点执行对应命令：

执行结果：

这说明Netdata不只可以围绕单个页面使用，也提供了继续扩展节点的入口。

15 查看具体监控指标

页面：

这里才是真正进入"系统状态可视化"的部分。

本文没有逐项验证所有指标，所以更准确的说法是：

已经进入监控指标页面并看到对应数据展示。

16 查看日志

日志页面：

这类入口对于排查：

• 服务异常；
• 采集失败；
• 系统状态变化；

会比只看一张总览图更有价值。

17 自定义仪表盘

页面：

如果默认页面信息太多，可以继续调整仪表盘。

这一步更适合把自己最关心的指标放到更容易看到的位置。

18 查看系统警告

页面：

Netdata会集中展示当前告警和警告状态。

但这里要区分：

看到告警入口

和：

已经针对自己NAS完成全部告警阈值调优

并不是一回事。

默认规则是否适合自己的设备，还要结合实际负载继续观察。

19 查看异常指标

页面：

这里可以继续查看异常相关信息。

这类页面更适合辅助发现：

某项指标和平时相比突然发生了变化。

但不能只凭"异常"两个字，就直接判断硬件已经损坏。

20 AI相关入口也已经出现

页面：

本文确实展示了Netdata里的AI相关入口。

但没有继续演示：

• AI具体给出了什么结论；
• 是否自动定位了故障；
• 是否完成告警处置。

因此只保留：

页面中存在AI相关功能入口。

不把它写成"AI已经自动帮你修好NAS"。

21 到这里，本地监控页面已经跑通

当前链路是：

飞牛NAS

↓

Docker

↓

Netdata

↓

Web仪表盘

↓

节点 / 指标 / 日志 / 告警 / 异常

如果只在家里查看NAS状态，到这里已经可以使用。

22 为什么还要做远程查看

真正需要看监控的时候，往往不一定人在家。

比如：

• 下载任务长时间运行；
• NAS突然变慢；
• 某个服务停止；
• 出门后想确认设备状态。

这时候局域网地址就不方便了。

后面增加cpolar，解决的是：

外部设备如何访问Netdata页面。

23 安装cpolar

执行：

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

页面：

安装完成以后检查服务：

sudo systemctl status cpolar

页面：

确认服务正常以后，再进入Web管理页面。

24 打开cpolar管理界面

通过：

主机IP:9200

进入：

登录后开始给Netdata创建公网入口。

25 先映射19999

本次创建参数：

• 隧道名称：netdata
• 协议：HTTP
• 本地地址：19999
• 域名类型：随机域名
• 地区：China Top

页面：

这里再次印证：

远程映射使用的是19999。

所以前面那处飞牛IP:1999更值得单独核对。

26 查看随机公网地址

进入在线隧道列表：

从外部设备访问：

能够打开以后，可以确认：

外部浏览器 → 公网地址 → 飞牛19999 → Netdata

已经跑通。

27 监控页面公开以后，风险和普通网页不同

Netdata页面可能展示：

• 系统资源；
• 主机信息；
• 网络状态；
• 服务状态；
• 告警；
• 日志；
• 节点信息。

这些内容对运维很有价值，对不该访问的人同样有价值。

所以公网使用时至少要考虑：

• Netdata自身登录状态；
• 公网地址传播范围；
• NAS系统安全；
• 是否真的需要长期开放。

28 随机地址适合先验证链路

随机地址更适合：

• 临时查看；
• 测试公网链路；
• 偶尔远程检查。

如果只是想确认人在外面能打开Netdata，到这里已经够用。

29 需要长期收藏再配置二级子域名

进入预留页面：

本次设置：

netdataa

页面：

实际名称以自己账号最终成功保留的结果为准。

30 修改Netdata隧道

回到隧道列表：

把域名类型改成：

二级子域名

填写前面保留的名称：

31 查看新的长期访问入口

进入在线隧道列表：

此时地址已经切换成二级子域名形式。

最后再访问：

能够正常进入以后，长期入口完成。

32 二级子域名解决的是入口稳定

它主要解决：

• 浏览器收藏；
• 手机长期查看；
• 不用反复复制随机地址。

但它不会自动解决：

• Netdata权限；
• NAS账号安全；
• 日志和监控数据暴露；
• 本地容器是否在线。

所以不把它写成：

永远不会变化、也永远安全的固定地址。

33 这套方案更适合什么人

比较适合：

• 已经有飞牛NAS；
• 想快速看设备状态；
• 不想先搭Prometheus+Grafana；
• 想看监控、日志、告警和异常入口；
• 希望人在外面也能打开监控页；
• 愿意继续处理容器权限和宿主机采集范围。

如果真正需要：

• 长期大规模指标存储；
• 复杂PromQL；
• 自定义监控体系；
• 多团队告警路由；
• 完整可观测平台；

Prometheus、Grafana、Loki等组合仍然有自己的优势。

34 最后把完整技术链重新看一遍

运行环境：

飞牛NAS + Docker

镜像：

netdata/netdata

容器端口：

19999

持久化：

netdataconfig / netdatalib / netdatacache

首次登录：

邮箱 + session ID

功能入口：

主页 / 节点 / 指标 / 日志 / 自定义仪表盘 / 警告 / 异常 / AI

远程查看：

cpolar → Netdata 19999

长期入口：

二级子域名

实际完成：

• SSH；
• Docker检查；
• 镜像拉取；
• Netdata容器；
• 首次登录；
• 邮箱验证；
• session ID；
• 主页面；
• 添加节点；
• 监控指标；
• 日志；
• 自定义仪表盘；
• 系统警告；
• 异常指标；
• AI入口；
• cpolar安装；
• 随机公网访问；
• 二级子域名；
• 外部设备访问。

这样Netdata真正展示出来的价值，不是"装上以后NAS就不会出问题"，而是把原本藏在后台的运行状态变得更容易看见。

总结

这次真正跑通的是一条完整的Netdata使用链：先在飞牛NAS里确认Docker环境，拉取netdata/netdata镜像并启动容器，再完成首次登录和Web仪表盘访问。

功能部分继续实际进入了主页、节点、监控指标、日志、自定义仪表盘、系统警告、异常指标和AI相关入口。这里最需要收回来的是"装上就能完整监控NAS所有硬件和Docker容器"的结论，因为当前Docker命令没有展示宿主机/proc、/sys或Docker Socket等挂载，具体能采到哪些宿主机指标要以实际页面为准。

这篇还有一个非常值得注意的端口问题：Docker明确映射19999:19999，cpolar也映射19999，但本地访问文字却写成飞牛IP:1999。如果部署时页面打不开，优先确认实际监听和映射端口，不要把1999和19999混在一起。

远程部分最后把Netdata仪表盘提供给外部设备查看，并切换到二级子域名作为长期入口。监控页本身会暴露系统状态、日志和节点信息，因此公网访问解决的是"人在外面也能看"，并不自动等于安全，访问范围和账号仍然要单独保护。