项目地址：https://github.com/netdata/netdata 定位：分钟级部署、秒级采集、开箱即用的分布式实时监控系统——"装完那一刻你就有了一千个指标"。
| 元信息 | 说明 |
|---|---|
| 语言 | C（Agent 核心，极致性能）+ 前端 |
| 星标 | 70k+ ⭐ |
| 协议 | GPL v3（Agent）/ 商业版（Cloud） |
| 资源占用 | Agent 约占用单核 1-5% CPU、数百 MB 内存（视插件数量） |
1、背景：监控的两条路线之争
| 路线 | 代表 | 特点 |
|---|---|---|
| 拉取式、低频、集中存储 | Prometheus + Grafana | 指标聚合强、告警生态大；粒度与保真度受采集间隔限制 |
| 推送/本地式、高频、单机保真 | Netdata | 每秒采集、异常检测自动告警；默认本地存储，Cloud 账号可选择性增强 |
Netdata 的产品哲学：监控不应该需要两周的调研选型。wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh 一条命令，60 秒后浏览器里出现上千个实时图表。
2、架构剖析
2.1、总体结构
┌────────────────── Netdata Agent（每台机器） ──────────────────┐
│ Collectors（采集器：internal / proc / statsd / exporters…） │
│ │ 每秒写入 │
│ DB engine（时序库：RAM + 磁盘分层，RRD 变体，秒级精度） │
│ │ │
│ Health（告警引擎：数百条内置规则 + ML 异常检测） │
│ │ │
│ Web/API（本地 19999 端口：无依赖的单机 dashboard） │
└──────────────┬───────────────────────────────────────────────────┘
│（可选，加密流）
Netdata Cloud（告警聚合、跨机视图、社区版免费）
2.2、采集器：广度的护城河
一个 Linux 节点装完即采集：
- 系统层：CPU 每核、中断、上下文切换、内存（含 slab 分项）、磁盘 I/O（毫秒延迟分布）、网络栈每个接口/TCP 状态机/Qdisc；
- 应用层：MySQL/PostgreSQL/Redis/nginx/cgroup（容器）等几十种开箱插件；
- 生态桥接：statsd 直接收、Prometheus exporter 复用、Logs 监控（新版）。
实现上的讲究：采集器以 C 为核心、插件化扩展（应用层走 go.d 等 Go/Python 插件），读取 /proc、/sys 的开销被压到极低；"每个指标每秒一个点"的成本可控，靠的是 ring buffer 式的分层存储而非全量落盘。
2.3、数据库引擎与存储经济学
热数据：内存（默认几十 MB~GB，可配）
│ 降采样+压缩（有损）
温数据：dbengine 磁盘文件（默认 /var/cache/netdata）
│ 可配置保留时长，精度从 1s 逐步降到 1m/1h
与传统 RRD 的关系：继承了"环形分层降采样"思想，但 dbengine 支持无预聚合的灵活查询与磁盘缓存页，是现代 SSD 时代的重设计。
2.4、告警与 ML 异常检测
- 阈值规则：内置数百条（如
10min_cpu_usage、oom_kill、磁盘util> 95%），模板化 YAML/CONF 一目了然； - ML 无阈值告警：对每个维度训练季节性模型，偏离预测区间即告
anomaly——不用拍脑袋定阈值，适合"不知道什么是正常"的新业务； - 告警动作：本地 UI、Cloud 通知、webhooks（钉钉/Slack/Telegram 均可接）。
3、快速上手
# 一键安装（kickstart 自动识别发行版）
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --stable-channel
# 访问本机 dashboard
open http://<host>:19999
# 手动压测观察：另一个终端跑 stress，看 dashboard 秒级响应
stress-ng --cpu 4 --vm 2 --vm-bytes 1G --timeout 120s
# 常用命令
netdatacli reload-health # 重载告警配置
systemctl status netdata
# 配置目录：/etc/netdata/（netdata.conf + go.d/*.conf + health.d/*.conf）
容器场景：官方镜像 netdata/netdata 挂载宿主机 /proc、/sys、docker.sock、/var/run，即可监控整机与每个容器（cgroup 级 CPU/内存/IO 曲线自动出现）。
4、生产实践视角
- 定位：单机深度排障，而非全局容量规划：
- 强项：登录某台"有问题的机器"后 3 分钟内看到一切——TCP 重传突增、磁盘 util 长尾、某个容器的内存爬坡，肉眼可辨；
- 弱项：万台规模的全局视图与长周期聚合分析，Prometheus + Thanos/Mimir 更合适；
- 混合方案很常见：Netdata 做单机排障与异常检测，指标同时经 exporting 引擎导出到 Prometheus 做长期聚合。
- 内存与 CPU 预算：高指标数节点（上千维度）Agent 可用到 1GB+ 内存；通过
[db]配置与关闭不用的 collector 控制占用；Cloud 免费版对节点数与保留期有策略，企业级需求评估商业授权。 - 告警治理：默认规则全开=告警风暴。做法：先
silence全部 → 按 SLO 挑 10-20 条核心规则 → 逐步放开；ML 异常只做"提示级"，不做 PagerDuty 级。 - 安全：19999 端口只绑内网或加 Cloud 隧道，Agent 默认
run as netdata低权限用户；不要把裸 dashboard 暴露公网——里面信息量足够攻击者做侦察。
5、横向对比
| 工具 | 采集粒度 | 部署成本 | 全局视图 | 告警 | 适合 |
|---|---|---|---|---|---|
| Netdata | 1 秒 | 极低（一条命令） | 中（Cloud） | 内置+ML | 单机/小集群深度排障 |
| Prometheus+Grafana | 15-60 秒（拉取） | 中 | 强 | Alertmanager | 全局监控、长期聚合 |
| Zabbix | 分钟级 | 高（server+db） | 强 | 成熟 | 传统 IDC 全栈监控 |
| Datadog | 秒级 | 中 | 强 | 强 | 不差钱的商业全家桶 |
结论不是"谁替代谁"：Netdata 解决"看到"的速度问题，Prometheus 解决"存住、聚合、告警路由"的问题。
6、面试/实践高频问答
- Q：为什么 Netdata 能做到 1 秒粒度而 Prometheus 通常 15 秒？ A：架构决定——Netdata 本地采集本地存储，无网络拉取与中心库写入瓶颈；Prometheus 的 pull 模型与 TSDB 写入成本在大规模下要求放宽间隔（且每秒拉取会造成 target 压力）。
- Q：无阈值 ML 告警可信吗？ A：作为异常信号很好（捕捉"形状变化"：突刺、台阶、震荡），但根因与严重级仍需阈值规则与人工确认；建议 ML 只进低优先级通道。
- Q：如何控制 Netdata 的资源占用？ A：三层——collector 裁剪（禁用无关插件）、db 配置（内存模式/保留天数）、更新频率（
update every从 1s 调到 5s 损失有限但省一半）。 - Q：把指标流给 Prometheus 怎么做？ A：配置 exporting 引擎（Prometheus Remote Write），或让 Prometheus 直接抓取 Agent 的
/api/v1/allmetrics接口；最佳实践是只导出聚合后的核心指标，避免 1s 粒度打爆 Prometheus 存储。
7、总结
Netdata 把"监控的启动成本"降到了接近零，把"数据的保真度"提到了秒级。当你深夜被叫醒排查一台机器时，它是最锋利的手术刀；而构建整个机房的观测体系时，记得把它放进以 Prometheus 为中心的生态位。
8、参考资料
- 官方文档：https://learn.netdata.cloud/
- GitHub：https://github.com/netdata/netdata
- 本系列第 7 篇之后的可观测性专题（Prometheus 生态请参考官方文档与《Prometheus: Up & Running》）
