首页/云/可观测性速查/部署 node_exporter 采集主机指标
Prometheus 与采集64 条

部署 node_exporter 采集主机指标

node_exporter 暴露 Linux/Unix 主机指标(CPU、内存、磁盘、网络、文件系统等);以 systemd 服务方式运行,默认监听 9100 端口。

可观测性速查云更新于 2026-10-13

node_exporter 是什么

node_exporter 是 Prometheus 官方的主机指标采集器:它读取 Linux 与类 Unix 系统的 proc 与 sys 接口,把 CPU、内存、磁盘、文件系统、网络、负载等指标暴露成 metrics 端点,默认监听 9100 端口。它以单进程常驻方式运行,资源占用小,是主机监控的默认选择。

基本信息

默认端口9100
运行方式单进程常驻,通常由 systemd 托管
依赖情况静态编译的单个二进制,无外部运行时依赖
采集范围CPU、内存、磁盘、文件系统、网络、负载等
可选采集器systemd、textfile 等需要显式开启

典型使用场景

  • 主机资源看板:用 CPU、内存、磁盘、网络四类指标支撑日常巡检
  • 容量与水位告警:文件系统剩余空间、内存可用量跌破阈值时通知
  • 故障定位:用负载、IO 繁忙度、TCP 重传判断是资源瓶颈还是应用问题
  • 自定义指标注入:通过 textfile 采集器把脚本产出的业务主机指标暴露出来
  • 批量纳管:配合配置管理统一分发,再由 Prometheus 服务发现自动接入

下载并安装二进制(示例)

下载并安装二进制(示例)
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -xzf node_exporter-1.8.2.linux-amd64.tar.gz
sudo install -m 0755 node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
node_exporter --version              # 确认版本与可执行

systemd 单元示例

systemd 单元示例
[Unit]
Description=Prometheus node exporter
After=network-online.target
[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter --collector.systemd --web.listen-address=:9100
Restart=on-failure
[Install]
WantedBy=multi-user.target

上线前的本地验证

上线前的本地验证
curl -s localhost:9100/metrics | head -20        # 端点是否返回指标文本
curl -s localhost:9100/metrics | grep -c '^node_' # 指标条数是否符合预期
ss -lntp | grep 9100                              # 监听地址是否正确

常用启动参数

参数作用
--collector.systemd开启 systemd 采集器,采集服务状态
--collector.textfile.directory指定自定义指标目录供 textfile 采集器读取
--web.listen-address修改监听地址与端口
--no-collector.<名称>关闭不需要的采集器以降低开销

容器化与批量部署

容器里运行必须挂载宿主机的 proc 与 sys,否则读到的是容器自身的数值,磁盘与网络口径尤其容易错。批量部署通常配合配置管理或编排工具统一分发二进制与单元文件,再在 Prometheus 侧用服务发现自动纳管,避免逐台手工登记。

上线验证清单

  • 端点可达:在目标机上 curl 本地 9100 端口能返回指标文本
  • 目标在线:Prometheus 的 Targets 页面显示该实例处于在线状态
  • 关键指标齐备:CPU、内存、文件系统、网络四类指标都能查到
  • 采集开销可控:抓取耗时远小于抓取超时,进程占用平稳
默认采集器已覆盖常用指标,systemd 与 textfile 需要显式开启。textfile 适合注入脚本产出的自定义指标,例如备份结果与证书到期天数。
部分指标需要相应权限与挂载才能采集完整;升级版本后个别指标名可能变化,升级前对照发布说明检查看板与告警的依赖项。

与 Prometheus 侧的配合

采集器与抓取端要一起设计:目标端点确定后,Prometheus 侧才有固定的抓取路径与端口;反过来,如果采集器改了监听端口或指标路径,抓取任务必须同步修改,否则表现为目标掉线而主机本身毫无异常。

维护阶段的注意点

  • 统一版本:多台主机版本不一致会让指标集出现差异,看板出现空白
  • 单元文件纳入配置管理:重启策略、运行用户与采集器参数要一致
  • 资源开销定期复核:开启的采集器越多,抓取耗时与序列数越高
  • 变更留痕:端口、路径、采集器开关的调整记录在案,方便故障时回溯
主机数量增长后建议用标签区分环境与角色:同一个 9100 端口在大批机器上完全相同,只有标签能把它们区分成可维护的集合。
采集器升级与 Prometheus 升级要分开安排:先升级采集端并回归看板,确认指标名与口径无变化,再考虑升级服务端。

易错点

  • 容器部署未挂载宿主机 proc 与 sys:磁盘与网络指标实际是容器的,主机容量判断全错
  • 只在一台机器手工安装:主机批量扩容后大量节点没有采集,监控覆盖出现缺口
  • 开启全部采集器:无用指标推高序列数与抓取耗时,应按需裁剪
  • 升级不检查指标名变化:看板与告警依赖的指标改名后会静默变成无数据

数据来源与参考

  • node_exporter 官方仓库(github.com/prometheus/node_exporter)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌