凌晨三点零七分，手机在床头震了一下。监控群里弹出一条消息：某台机器负载 12。
你爬起来，笔记本开机，SSH 进去，敲 uptime，load average 12.4，五个核的机器。再敲 top，CPU 加起来只有 20%。
这种时候最难受的不是机器坏了，是你不知道该看哪儿。
CPU 不高、负载很高，通常是 IO 在等，或者一堆进程卡在不可中断睡眠里。你想知道是哪个进程在写盘，top 的默认视图里没有 IO 那一列。你想知道这情况是十分钟前就开始了还是刚刚才发生，top 不给你历史。你想知道是不是只有这一台这样，top 更管不着别的机器。
同一个夜晚，三个工具会给出三种完全不同的答案。btop 在一个屏幕里把 CPU、内存、磁盘、网络、进程树全铺开，鼠标点哪行看哪行。Glances 让你在终端里看，也能在自己笔记本的浏览器里看同一份数据。Netdata 可能在你还没醒的时候，就已经把 3:02 到 3:07 之间每个网卡的包量画成图，顺便发了一条告警出去。
这三个东西经常被塞进同一篇对比文章，但它们其实不在一条赛道上。选错的代价不是多装一个软件，是关键时刻打开了一个答不了你问题的窗口。
它们回答的不是同一个问题
我用一个很笨的办法区分它们：想象你关掉终端之后，这台机器上还剩下什么。
btop 关掉就什么都不剩。它是一个观察工具，一个在你眼前展开的仪表盘，退出之后没有历史、没有守护进程、没有监听端口。
Glances 关掉终端还可能活着，前提是你用 -s 起了服务端。它在 61208 端口上开一个 Web 界面和一套 REST API，同一份采集结果既能在终端里画成表格，也能被浏览器、被脚本、被别的系统读走。它卡在中间。
Netdata 从头到尾就不是给你「打开看一眼」的。装上去就不管，19999 端口常年开着，每秒采一次，数据落盘，异常自己学，出事自己发消息。
所以比较它们的正确方式，是看它们各自愿意为你保留多少东西，又为此付出多少代价。
| 维度 | btop | Glances | Netdata |
|---|---|---|---|
| 怎么装 | 系统包管理器一条命令，或解压一个静态二进制 | pip、pipx、uvx、Docker、brew，Web 功能要另装 glances[web] |
官方一键脚本、Docker、各平台安装包 |
| 界面 | 纯终端全屏，支持鼠标 | 终端、浏览器、REST API 三个入口 | 以浏览器为主，19999 端口 |
| 历史数据 | 没有，只有内存里滚动的曲线 | 默认不留，可导出到 InfluxDB、Prometheus、ClickHouse 等 | 自带时序库，分层存储，官方称每样本约 0.5 字节 |
| 告警 | 无 | 阈值只在界面变色，要通知得外接 | 内置数百条规则，可发邮件、Slack、Telegram、PagerDuty |
| 授权 | Apache-2.0 | LGPL-3.0 | Agent 为 GPL-3.0，Web UI 另有 NCUL1 许可 |
| 体量感觉 | 一个九百多 KB 的静态二进制 | 一整套 Python 依赖 | 常驻守护进程加一个数据库 |
这张表里唯一一个能称得上精确的数字，是 btop v1.4.8 的 Linux 静态包里那个 973KB。其余全是定性描述，因为这三个项目的资源占用跟你的机器、采集项、保留时长强相关，任何「实测占用 XX MB」的说法换个环境就不成立。
btop：把当下这一秒摊开
假设你现在在一台四核小机器上编一个 Rust 项目，风扇开始叫。top 显示 cargo 占了 380%，但你想知道是哪个子进程在吃，是编译阶段还是链接阶段，内存是不是快满了。
btop 打开，第一眼是四宫格。每个核一根柱，内存和 swap 分色，磁盘读写速度，网络上下行。往下是进程列表，默认按 CPU 排序。按 f 输入 rustc，列表立刻只剩编译进程。选中一行回车，右边弹出这个进程的详细信息和完整命令行。按 e 切成树状视图，你能看见 cargo 底下挂着的那一串子进程各自的状态。盯住某个进程按 t 发 SIGTERM，按 k 发 SIGKILL，不用退出去敲 kill。列表还能暂停，方便你盯住某一屏不被新进程刷走。
它的手感是这三个里最像「工具」的：全鼠标支持，所有标了快捷键的按钮都能点；主题文件跟 bpytop、bashtop 通用，网上现成的配色能直接拿来用；1.3 之后加了 GPU 支持，N 卡、A 卡、Intel 核显都能出利用率、显存、功耗和频率；1.4 之后又补了进程跟随和进程列表暂停。它自称是 bashtop 和 bpytop 的 C++ 续作，也确实是这么做的，只是把 Python 那层运行时彻底去掉了。
安装这件事它做得最干脆。release 页给的是 musl 静态编译的二进制，解压、sudo make install、完事。Debian 系想自己编的话门槛不低，README 现在写的是至少 GCC 14 或 Clang 19，这个要求能劝退一大半人，所以大多数人还是走发行版包或者 brew install btop。静态包的好处是兼容老内核，README 说 2.6.39 以后的都能跑，这在一些还在服役的老 CentOS 上很实用。
代价也很清楚：你关掉它，这一屏就没了。它不写数据库，不发告警，不记得十分钟前发生过什么。想复盘刚才那波尖峰，只能靠你在它还开着的时候截图。
但有一类场景它无可替代：你已经在机器上了，你要在三十秒内知道谁在吃资源，然后动手。这时候任何需要开浏览器、需要等图表加载的工具都是累赘。
反过来，它也有几件事完全干不了。你要同时盯十台机器，它帮不上。你要查上周三的磁盘延迟，它帮不上。你要给值班同事留一条「这台机器 IOPS 超过 5000 就打电话」的规则，它更帮不上。这些得交给另外两个。
Glances：同一份数据，换个地方看
再换一个场景。你手上有六台机器，一台在云上，一台在朋友机房，两台是家里的树莓派，还有两台是测试环境。你不想每台都 SSH 一遍，也不想为了看个内存装一整套监控系统。
Glances 的解法是把采集和呈现拆开。每台机器上 glances -s 起服务端，它在 61208 端口提供服务，监听地址可以用 -B 指定。然后你在笔记本上 glances -c 那台机器的IP，终端里出现的是和本地几乎一模一样的界面，数据从对方的 REST API 拉过来。或者直接把浏览器指向 http://那台机器:61208，得到一个响应式布局的 Web 面板，手机上看也不难看。它还有个 --browser 参数，能自动发现局域网里所有开着 Glances 的机器，机器一多这个功能省事。
这是它和 btop 最本质的区别。btop 的界面就是它的全部，Glances 的界面只是它的一种输出。同一个 CPU 插件的数据，可以在终端里变成一根柱，可以在 Web 里变成一个环，可以 --stdout 打成一行行纯文本喂给脚本，可以 --export 写进 InfluxDB、Elasticsearch、PostgreSQL/TimeScale、ClickHouse、CouchDB、Prometheus、Graphite，也可以 import glances 当 Python 库直接调。
2026 年这一版还多了个我觉得挺有意思的东西：4.5.1 之后它内置了 MCP server。glances -s --enable-mcp，AI 助手就能直接查这台机器的 CPU、内存、网卡、进程。以前你得给模型解释半天「帮我看看内存」，现在它自己就能读到那些字段。这个设计和整个项目是一路的：数据是核心，界面随便换。
还有两个容易被忽略的小功能，正好体现这种「数据优先」的取向。glances --fetch 会打一张一次性的体检卡，机器概况一屏看完，适合写进登录脚本，SSH 上去先看一眼。glances -q --export csv 能在完全不开界面的情况下把采样写成 CSV，配 cron 跑，比解析 top 的输出省事得多。
它的短板也在同一个地方。因为它什么都想干，所以它什么都不深。装 Web 功能要 pip install 'glances[web]'，全功能是 glances[all]，依赖不算轻，而且要求 Python 3.10 以上。默认没有密码，README 里明确写着服务端默认不受保护，要加密得先 glances --set-password 生成哈希，再写进配置文件的 [outputs] 段。这两条放在公网上是会出事的。
还有一点容易被忽略：Glances 的阈值设置主要服务于界面着色，超过 warning 变黄，超过 critical 变红。它不负责把这件事告诉你。你睡着了，它不会叫醒你。
Netdata：给「你不在场」的那几个小时
第三种场景。早上九点，客服说昨晚十一点有一批下单失败。你打开 Netdata，把时间轴拖到 22:50。
这是三个工具里唯一能回答「过去」的那个。默认界面在 19999 端口，打开就是密密麻麻一屏图，每屏都是每秒一个点。CPU 的 user、system、iowait、softirq 分开画，内存分了十几个维度，磁盘有 IOPS 也有延迟，网络按协议拆，容器按 cgroup 拆。往下翻还有 nginx 的请求数、Postgres 的连接数、Redis 的命中率。README 里说集成了 800 多个。
真正让它和另外两个拉开距离的是三件事。
一是它自己会学习。每个指标在边缘侧训练模型，持续比对最近的行为，偏离了就标记成异常。你不需要先知道「正常的 iowait 是多少」，它自己知道。
二是它自己会喊人。内置几百条告警规则，开箱能发邮件，也能接 Slack、Telegram、PagerDuty、Discord、Teams。README 里有句话挺实在：只要机器上配了 MTA，邮件告警默认就是通的。
三是它自己会存。内置分层时序库，README 说每个样本大约 0.5 字节，这意味着小机器上也能留几周的高精度数据，而不是只留聚合后的平均值。
它的存储是分层的。默认的 db 引擎把原始秒级数据放在最底层，往上一层按分钟降采样，再往上一层按小时，越老的数据精度越粗。好处是你不用在「高精度」和「长历史」之间二选一，坏处是磁盘会慢慢长，得在配置里给它划个上限，不然一台小机器半年后会发现根分区满了。
代价是它是个正经的服务。它常驻、它占内存、它写盘、它开端口，而且它的图多到第一次打开会有点晕。你如果只是想看一台机器现在卡不卡，装它属于用牛刀。它还需要你理解几个概念：Agent 跑在节点上，Parent 负责汇聚和延长保留期，Cloud 负责跨节点视图和权限。这套东西不复杂，但也不是装完就懂。
它还有个容易被误解的地方。Netdata 这个品牌下面其实有三样东西：Agent 是开源的，跑在你机器上，负责采集、存储、告警；Cloud 是商业服务，有免费额度，企业功能要钱；Web UI 用的是一套叫 NCUL1 的自有许可，不是 GPL。所以「Netdata 是开源软件」这句话对 Agent 成立，对整个产品不成立。
授权协议，比想象中容易踩
这一段平时没人看，真到了要把它塞进产品或者镜像里的时候，会卡住整个项目。
btop 是 Apache-2.0。三者里最宽松的一个，你可以改、可以闭源分发、可以打包进商业产品，只要保留版权声明和变更说明。
Glances 是 LGPL-3.0。这个协议的边界在「链接」。你改 Glances 本身的代码，改动要开源；但你的程序通过它的 REST API 拿数据，那只是进程间通信，不会传染到你的代码。所以拿它当数据源基本没有顾虑，改完再闭源分发就不行。
Netdata 的 Agent 是 GPL-3.0，比 LGPL 严一档。你在自己机房跑，怎么改都行，不用公开；但你要是分发一个改过的 Agent，整个衍生作品都得按 GPL 开源。它的 UI 又是另一套许可，限制比 GPL 多。
一句实用结论：公司内部随便用，三个都没问题；要把改过的版本塞进卖出去的产品，btop 最省事，Glances 次之，Netdata 得先找法务。
它们各自吃多少
这个问题不能只看数字，得看数字换来了什么。
btop 的开销基本等于「一个终端程序」的开销。静态二进制九百多 KB，不需要运行时，不需要数据库，退出就释放。它在低配机器、老内核、甚至一些奇怪的嵌入式环境里都能跑。代价是它没有任何后台成本，因为它没有后台。
Glances 多了一层 Python。用 psutil 采数据本身不贵，贵的是解释器启动、依赖加载，以及你开了 Web 之后一直跑着的那个 ASGI 服务。它的资源曲线是「用的时候高，不用的时候也还在」。偶尔 glances 看一眼，这点开销无所谓；在二十台机器上都挂着 -s，那就该算一下总量。
Netdata 是三者里最重的，这是功能决定的，不是实现差。常驻进程、时序数据库、每个指标一套模型、几百个采集器按需加载。README 引用了一项阿姆斯特丹大学 2023 年的研究，说它在 Docker 场景下是能耗最低的监控工具。厂商引用第三方研究这件事，你信几分自己判断，但它至少说明一点：重不等于低效，重也可以重得有条理。
我的判断标准很土。这台机器内存小于 1GB，不装 Netdata。我只是想知道现在谁在吃 CPU，不装 Netdata。我需要回答「昨天下午三点那波超时是怎么回事」，那我宁可少装别的东西也要装它。
那今晚到底敲哪个
回到凌晨三点。
只想搞清楚「现在」，btop 最快。一条命令，一个屏幕，鼠标点两下知道是哪个进程，t 或 k 处理掉，收工。它不需要你提前部署，不需要配置，甚至不需要联网。
手上不止一台机器，或者想让脚本也能读这些数，Glances 更合适。起一次服务端，以后终端、浏览器、API 三个入口随便用，还能顺手把数据推进你已有的 Prometheus。
需要的是「事后能查」，或者你根本不想半夜被叫醒，那就得是 Netdata。它替你值夜班，代价是它自己要占一张床。
三个都装其实不冲突。一台机器上跑 Netdata 做长期记录，临时进去用 btop 看细节，Glances 负责把数据递给外部系统，这是不少人实际的组合。真正会出问题的，是只装了一个，然后在需要另一种答案的深夜里发现它答不上来。
装之前记得一件事：Glances 的 61208 和 Netdata 的 19999 默认都没有身份验证。别把它们直接开到公网，套一层反向代理加认证，或者只监听内网。监控工具自己变成入侵入口，这种事每年都在发生。
最后说句可能有点扫兴的。这三个工具都不能替你脑子里那张图。它们能告诉你 CPU 在等 IO，但「为什么在等」还得你去翻日志、看慢查询、问上游那个刚改过配置的人。工具能做的是把问题从一整个系统缩小到一屏，剩下那一步没人替你做。
延伸阅读
- Beszel vs Netdata vs Uptime Kuma：轻量服务器监控三选一，2026 年怎么选不踩坑
- Pydantic AI 对比 LangGraph 与 Agno：Python 智能体框架怎么选
- OpenCLI vs page-agent：让 AI Agent 直接操作网页的两条路线（2026）
- invisible_dots vs Camoufox vs Patchright：反检测浏览器怎么选
- Conductor 工作流引擎对比 Temporal、Inngest、Restate：AI Agent 持久化执行怎么选
Stay updated with our latest AI insights
