Linux查看硬件负载，glances监控工具全解析

Glances 是 Linux 下功能强大且开箱即用的综合硬件监控工具，能一站式呈现 CPU、内存、磁盘 I/O、网络、温度等关键负载指标，但其真正价值远不止于“看到数据”——新手常被默认界面和颜色预警误导，而实际使用中必须手动启用传感器（-e）、依据 io_wait 而非 CPU% 判断磁盘瓶颈、通过 c/m/i 键精准排序进程，并深入配置文件调整动态阈值以匹配真实业务场景；它不是“装完就能懂”的工具，而是需要理解每项指标背后物理含义、结合硬件环境（如物理机 vs 云服务器）和系统行为交叉验证的运维利器。

glances 是目前 Linux 下最接近“开箱即用”的硬件负载综合监控工具——它不只看 CPU 或内存单项，而是把 CPU 负载、内存压力、磁盘 I/O 延迟、网络吞吐、温度传感器、高耗资源进程等全塞进一个终端界面，且默认刷新仅消耗不到 2% 的 CPU。

但直接敲 glances 很容易卡在“啥都看见了却不知道该盯哪”，尤其新手常误以为绿色=安全、红色=马上宕机，其实颜色背后是可调阈值，而某些关键模块（比如温度、磁盘 I/O）默认压根不启用。

glances 默认不显示 CPU 温度和风扇转速，必须手动启用传感器模块

很多用户运行 glances 后按 f 键想看温度，结果提示 No sensors detected。这不是工具坏了，而是 glances 默认不加载硬件传感器数据。

• 先装底层驱动：yum install -y lm_sensors（CentOS/RHEL）或 apt install -y lm-sensors（Debian/Ubuntu）
• 再运行 sensors-detect，全程按回车接受默认检测（遇到 yes/no 选 yes）
• 最后启动 glances 时加 -e 参数：glances -e，此时按 f 才能唤出温度/风扇面板
• 注意：lm_sensors 在虚拟机里通常无效——它依赖物理主板的硬件传感器，云服务器（如阿里云、腾讯云 CVM）基本不支持

磁盘 I/O 负载看 io_wait 比看 %CPU 更准

glances 界面顶部的 CPU 使用率（如 CPU%: 12.3%）容易误导：它反映的是 CPU 时间片占用，不是系统是否卡顿。真正拖慢响应的，往往是磁盘等待。

• 在 glances 中按 d 键可切换显示磁盘 I/O 细节，重点关注 io_wait 列（单位为 %）——它代表 CPU 等待 I/O 完成的时间占比
• 如果 io_wait > 20% 且持续超过 30 秒，说明磁盘已成瓶颈，哪怕 CPU% 只有 5%，服务也会明显变慢
• glances 默认每 3 秒刷新一次，但 I/O 波动快，建议启动时加 -t 1：glances -t 1，避免漏掉尖峰
• 若发现某块盘 read/s 或 write/s 长期超 100 MB/s，而它是机械盘（非 SSD），基本可判定过载

glances 进程排序默认不按实际资源消耗，得手动切

刚进 glances 时看到的进程列表，是按 PID 排序的，完全不能反映谁在吃资源。很多人盯着 top 里排第一的进程猛查，结果发现它只是个常驻守护进程，真正凶手藏在后面。

• 进入界面后，直接按 c 键按 CPU% 降序排列，按 m 键按 MEM% 降序，按 i 键按 I/O 读写量排序
• 注意：glances 默认只显示前 10 个高耗进程，如果想看全部，启动时加 --process-short 关闭精简模式，或按 1 键切换单 CPU 视图释放空间
• 某个进程 CPU% 高但 MEM% 很低，大概率是计算密集型任务；反之 MEM% 高但 CPU% 低，可能是内存泄漏或缓存堆积
• 按 a 键可自动按当前最紧张的资源类型排序（比如内存告警时自动切到 m 模式）

颜色警告不是绝对标准，阈值藏在配置文件里

绿色 OK、红色 CRITICAL 的视觉反馈很直观，但 glances 默认的阈值（careful=50, warning=70, critical=90）对不同场景可能完全失真。

• 阈值定义在 /etc/glances/glances.conf（全局）或 ~/.config/glances/glances.conf（用户级），修改前先备份
• 例如数据库服务器，swap 使用率 >5% 就该标 WARNING，但默认是 70% 才触发——得改 [memswap] 下的 critical 行
• 磁盘使用率告警要区分分区：/ 分区 85% 就危险，但 /data 分区 95% 可能只是归档目录，需单独配 [fs] 段
• 改完配置不用重启，glances 会热加载；但颜色变化只在下次刷新生效，不会追溯历史

真正难的不是装上 glances，而是理解它每列数字背后的真实含义——比如 load 行三个数字（1/5/15 分钟平均负载）得和 cpu count 对着看，否则单说 “load 4.2” 完全没意义。这些细节不翻配置、不结合 sensors 和 iostat 交叉验证，很容易被表层颜色带偏。

今天关于《Linux查看硬件负载，glances监控工具全解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！