80.8k Star！零配置 AI 监控神器，服务器抖一下都逃不掉

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/netdata-zero-config-ai-monitor/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

搞过监控的人都知道，从零搭一套 Prometheus 加 Grafana 是什么体验。写采集配置、接数据源、调仪表盘，一个下午就没了，而且每加一台机器还要再改一遍配置。我自己几台服务器上一直跑着 Netdata，图的就是装完就能看。

它现在 GitHub 上八万多 Star，GPL-3.0 协议，主要用 Go 写的。你可以把它理解成一个跑在机器上的 Agent，自带 Web 面板，默认走 19999 端口，数据默认存本机，不需要另外搭数据库。

仓库首页实时截图，Star 与 Fork 计数同时可见

README 头部，两句标语与五组徽章

这篇不聊怎么调参，我想聊它到底解决了什么问题，代价在哪。

它答应你的是一秒粒度的现场

多节点总览页，节点数与活跃告警

官方那句标语写得很直白，每一项指标，每一秒。

官方 README 里还挂着一句自我调侃，说人们会对 Netdata 上瘾，一旦用上就回不去了。

这不是修辞。多数监控工具默认 15 秒甚至 1 分钟采一次，平时看不出差别，排查的时候就差出来了。服务器上那种几秒钟的卡顿、瞬间打满的磁盘 IO，在低频采集下会被直接抹平，图上就是一条平滑的线，你根本不知道刚才发生了什么。一秒粒度能把那个尖峰完整画出来，还能顺着看到当时是哪个进程引起的。

CPU 与内存的实时图表，图表上方是异常率标记

每张图还能框选放大、拖动，排查时顺着时间线往前翻，比较顺手。

它答应的是一秒粒度的现场，而这份现场是用历史深度换来的。

装完不用配，是因为它自己会扫

零配置这件事，靠的是自动发现。官方说支持八百多种集成，Nginx、MySQL、Redis、PostgreSQL、Docker、Kubernetes 这些常见的都在名单里。

你不用告诉它机器上装了哪些服务，它自己会扫。作者在一台跑着 Docker 和几个服务的机器上装完，面板里直接多出了容器的资源占用图和服务指标图，中间没点过任何配置；后来在那台机器上加了新服务，监控也跟着自动加上了。

代价是它替你扫完，你对它采了什么要多一分留意，必要时还是得去翻一遍集成列表。

异常检测是它最像 AI 的部分

异常检测顾问页，异常率曲线与异常指标列表

每个指标背后都在跑一个机器学习模型。它先学这个指标平时正常是什么样，然后实时算一个异常率，图表上方有一条 AR 指示；鼠标停在某个时间点上，能看到那一刻各个维度的异常率分别是多少。

它抓的是一类阈值告警抓不到的问题。有的指标只是比平时高一点，数值不夸张，按静态阈值根本不会响，但按它自己的历史看已经不正常了。排查的时候先看哪几个指标的异常率飙了，再顺着往下查，比漫无目的地翻图快。

指标和日志在同一个面板里

日志页，优先级分布与日志表

面板上有一个 Logs 页签，可以直接翻 systemd journal 的日志，按服务、按时间过滤。

这件事单独看不大，和指标图放在同一个面板里就不一样了。你看图发现某个时间段不对劲，顺手就能翻到那个时间段的日志，不用再开一个终端敲 journalctl。排查有一半时间花在「把两个现场对起来」上，能省掉这一步就省掉了一步。

告警也是开箱就有的。它内置了几百条现成的规则，CPU 持续过高、磁盘快满了、内存不够这类常见问题都覆盖到了，装完直接生效。通知渠道支持邮件、Slack、Telegram、ntfy 等很多种，改一个配置文件填参数就行。想自己写规则也不难，写清楚查哪个指标、看多长时间窗口、超过多少告警，基本就这三样。

历史存储是它的短板，也是它和 Prometheus 分工的原因

这段是它的取舍。默认配置下，它优先保实时的高精度数据，历史数据按精度分级保留，能存的时间有限；想存得久一点，要自己配分层存储，或者把数据导到外部的时序数据库里。拿它看现在、看刚才发生了什么很合适，跨月跨年的容量趋势，就得换工具了。

所以它和 Prometheus 加 Grafana 不是二选一，是分工。Netdata 看机器当前的状态，Prometheus 看长期趋势和复杂告警规则。不少人两个都跑，Netdata 装在各台机器上负责实时排查，Prometheus 负责长期存储。两边还能打通，Netdata 提供了一个 Prometheus 格式的抓取端点，可以让 Prometheus 直接来采它的数据。

父子节点还是上云，差别在数据出不出网

多节点实时视图，多台机器并排与右侧节点树

机器多了以后有两种汇总方式。一种是把多台机器的数据流式汇总到一台父节点上，在父节点的面板里看所有机器的图，配置就是在文件里填父节点地址和一个密钥。

另一种是官方的 Netdata Cloud，把多个节点接到云端统一看。这里有个取舍要说清楚，走云端意味着指标数据会发到外部服务上；对数据有不出网要求的环境，用父子节点自托管就行，指标可以完全留在自己的机器上。

装起来两条命令，19999 别直接对外

先看官方的一行脚本。

curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry

这条要在 root 或者 sudo 下跑，--stable-channel 锁稳定通道，--disable-telemetry 关掉遥测上报。

容器这条路，官方文档里有全量和精简两个变体。全量那套要 --pid=host 与 --network=host 加上十来条宿主机挂载，才能拿到和直接装在宿主机上一样完整的采集能力；只想先看面板的话，精简版这样写。

docker run -d --name=netdata \
  --hostname=$(hostname) \
  -p 19999:19999 \
  -v netdataconfig:/etc/netdata \
  -v netdatalib:/var/lib/netdata \
  -v netdatacache:/var/cache/netdata \
  --restart unless-stopped \
  --security-opt apparmor=unconfined \
  netdata/netdata

跑起来以后浏览器打开 http://服务器IP:19999 就能看到面板；想改告警或者加集成，改 /etc/netdata 下面的配置文件。

最后一条提醒，19999 端口别直接暴露到公网。正式用就套一层反向代理加上认证，或者只允许内网访问。

什么人适合拿它当第一套监控

资源开销先摆出来。来源作者那边的体感和几篇实测文章的汇总是一组数字，CPU 平时在 1% 上下，内存从一百 MB 到三四百 MB 不等；官方口径是另一组，每秒 5,000 指标的量级下大约是 5% 的单核 CPU 和 200 MB 内存。两组的前提不一样，前者没给指标量，只能当量级参考。内存只有 1G 或 2G 的小机器又跑满了服务，还是要掂量一下，或者把采集频率调低。

剩下就是判断了。机器上还没监控的，或者手上已经有 Prometheus 但每次排查都要先翻半天图，可以装一个试试，它补的正是「刚才那几秒发生了什么」这一段。它的长期存储和复杂查询干不了，要跨月跨年的容量趋势，还是得靠别的工具。

最后交代一句，我没在机器上装过 Netdata，上面的功能描述来自官方文档与来源正文，资源占用那两组数字都不是我实测的。仓库地址是 https://github.com/netdata/netdata 。