Ubuntu运维监控Prometheus+node_exporter部署

在Ubuntu服务器上部署Prometheus+node_exporter监控体系，核心就是三步：安装Prometheus主服务、部署node_exporter采集器、配置抓取目标让两者联动起来。整套流程在Ubuntu 20.04/22.04上跑通只需要二十分钟，但要把监控做得稳定、全面、可扩展，细节非常多。下面我把从安装到生产级配置的完整链路全部讲透。

一、为什么选Prometheus+node_exporter这套组合

Prometheus是目前云原生领域事实标准的时序数据库监控系统，Pull模式采集、多维度标签、强大的PromQL查询语言，这些特性让它在运维监控中几乎无可替代。node_exporter则是Prometheus官方维护的主机级指标采集器，专门负责把CPU、内存、磁盘、网络、文件系统等底层硬件和系统指标暴露成Prometheus能读懂的格式。两者搭配，一台Ubuntu服务器的监控就有了完整的数据底座。

相比Zabbix这类传统方案，Prometheus+node_exporter的优势在于：轻量级、无Agent依赖（node_exporter本身就是独立进程）、天然适配容器化和微服务架构、告警规则灵活可编程。劣势也要说清楚：它不擅长日志采集，长期存储需要搭配Thanos或VictoriaMetrics，初次上手PromQL有一定学习曲线。

二、Ubuntu上安装Prometheus服务端

首先更新系统包索引，然后下载Prometheus官方编译好的二进制包，不需要从源码编译，直接用官方release包最省事。

sudo apt update && sudo apt upgrade -y
wget https://github.com/prometheus/prometheus/releases/download/v2.51.2/prometheus-2.51.2.linux-amd64.tar.gz
tar xvfz prometheus-2.51.2.linux-amd64.tar.gz
sudo cp prometheus-2.51.2.linux-amd64/prometheus /usr/local/bin/
sudo cp prometheus-2.51.2.linux-amd64/promtool /usr/local/bin/
sudo mkdir -p /etc/prometheus
sudo cp prometheus-2.51.2.linux-amd64/consoles /etc/prometheus -r
sudo cp prometheus-2.51.2.linux-amd64/console_libraries /etc/prometheus -r
sudo useradd --no-create-home --shell /bin/false prometheus
sudo chown -R prometheus:prometheus /etc/prometheus
sudo chown prometheus:prometheus /usr/local/bin/prometheus
sudo chown prometheus:prometheus /usr/local/bin/promtool

接下来创建Prometheus的systemd服务文件，让它开机自启并以独立用户运行，这是生产环境的基本安全要求。

sudo tee /etc/systemd/system/prometheus.service > /dev/null <

然后创建数据存储目录并设置权限，启动服务。

sudo mkdir -p /var/lib/prometheus
sudo chown -R prometheus:prometheus /var/lib/prometheus
sudo systemctl daemon-reload
sudo systemctl start prometheus
sudo systemctl enable prometheus
sudo systemctl status prometheus


此时访问服务器的9090端口就能看到Prometheus的Web界面了。但别急，现在它还没有配置任何采集目标，需要下一步。

三、Ubuntu上部署node_exporter采集器

node_exporter同样从官方release下载，支持x86_64和arm64架构，Ubuntu服务器一般都是x86_64。

wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz
sudo cp node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false node_exporter


创建node_exporter的systemd服务文件，默认监听9100端口。

sudo tee /etc/systemd/system/node_exporter.service > /dev/null <

启动并验证node_exporter是否正常工作。

sudo systemctl daemon-reload
sudo systemctl start node_exporter
sudo systemctl enable node_exporter
curl http://localhost:9100/metrics


curl命令返回一大堆以#开头的注释和指标数据，说明node_exporter已经在正常暴露指标了。这里有个关键点：node_exporter的启动参数里我加了很多collector开关，默认情况下部分采集器是关闭的，比如conntrack、tcpstat、processes这些在排查网络和进程问题时非常有用，建议生产环境全部开启。

四、配置Prometheus抓取node_exporter指标

编辑Prometheus的主配置文件，添加抓取任务。

sudo vim /etc/prometheus/prometheus.yml


写入以下内容：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']
        labels:
          instance: 'ubuntu-server-01'
          env: 'production'

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']


配置说明：scrape_interval设为15秒意味着每15秒Prometheus会主动去node_exporter拉一次数据，这个频率对大多数场景够用，如果服务器负载高可以调到30秒。labels字段是自定义标签，方便后续在PromQL里按实例、环境等维度过滤查询。第二个job是让Prometheus监控自身，这是最佳实践。

配置改完后需要重载Prometheus使其生效，不需要重启服务。

sudo systemctl reload prometheus
curl http://localhost:9090/-/reload


然后打开Prometheus Web界面，进入Status -> Targets页面，应该能看到node_exporter的状态是UP，最后一次抓取时间是几秒前。如果状态是DOWN，检查防火墙是否放行了9100端口，以及node_exporter进程是否在跑。

五、防火墙和安全加固

Ubuntu默认用ufw管理防火墙，需要把9090和9100端口放开。如果是内网监控服务器，建议只允许特定IP访问9090端口。

sudo ufw allow from 192.168.1.0/24 to any port 9090
sudo ufw allow from 192.168.1.0/24 to any port 9100
sudo ufw reload
sudo ufw status


更安全的做法是用Nginx做反向代理，给Prometheus Web界面加上Basic Auth认证。node_exporter本身不需要认证，因为它只在内网暴露，但如果你的监控网络不够隔离，也可以考虑用mTLS。另外，node_exporter的9100端口不要直接暴露到公网，这是很多人犯的低级错误。

六、常用PromQL查询语句实战

部署完成只是第一步，真正的价值在于你能从指标里挖出什么。下面列几个运维日常最常用的查询：

查看CPU使用率（排除idle状态）：

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)


查看内存可用百分比：

(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100


查看磁盘使用率（按挂载点）：

(1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})) * 100


查看网络入站流量速率：

rate(node_network_receive_bytes_total{device="eth0"}[5m])


查看系统负载（1分钟）：

node_load1


这些查询直接在Prometheus Web界面的Graph标签页里输入就能看到图表。建议运维人员把这些常用查询保存成模板，日常巡检直接调用。

七、配置告警规则

Prometheus自带Alertmanager做告警通知，但很多人只装了Prometheus没配Alertmanager，等于监控只看不报警。简单配置一个告警规则文件：

sudo vim /etc/prometheus/alert_rules.yml


groups:
  - name: node_alerts
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU使用率超过80%"
          description: "{{ $labels.instance }} CPU使用率已达 {{ $value }}%"

      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "内存使用率超过85%"
          description: "{{ $labels.instance }} 内存使用率已达 {{ $value }}%"

      - alert: DiskSpaceLow
        expr: (1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})) * 100 > 90
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "根分区磁盘使用率超过90%"
          description: "{{ $labels.instance }} 根分区使用率已达 {{ $value }}%"

      - alert: InstanceDown
        expr: up{job="node_exporter"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "实例 {{ $labels.instance }} 不可达"


然后在prometheus.yml里引用这个规则文件：

rule_files:
  - "/etc/prometheus/alert_rules.yml"


重载Prometheus后，在Web界面的Alerts标签页就能看到这些规则的状态。但要真正收到告警通知，还需要部署Alertmanager并配置通知渠道（邮件、企业微信、钉钉等），这是另一个话题，篇幅有限这里不展开。

八、多服务器监控扩展方案

如果你有几十台甚至上百台Ubuntu服务器需要监控，手动在prometheus.yml里逐个加target显然不现实。这时候有两种方案：一是用文件发现（file_sd_configs），Prometheus定期扫描指定目录下的JSON文件自动发现新目标；二是用Consul、etcd等服务发现机制。最简单的文件发现配置如下：

scrape_configs:
  - job_name: 'nodes'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/*.json'


每台服务器的node_exporter信息写成一个JSON文件放到指定目录，Prometheus自动加载。这种方式比静态配置灵活得多，新增服务器只需要丢一个JSON文件进去。

九、数据持久化和长期存储建议

Prometheus默认的本地存储适合短期监控，数据保留时间由--storage.tsdb.retention.time参数控制，默认15天。如果需要更长时间的历史数据做趋势分析，有三个主流方案：Thanos（官方推荐的长期存储方案，支持对象存储）、VictoriaMetrics（高性能替代方案，单节点性能比Prometheus强很多）、Cortex（适合多租户大规模部署）。对于中小规模运维团队，VictoriaMetrics是性价比最高的选择，部署简单且兼容Prometheus的查询接口。

十、常见踩坑和排查技巧

实际部署中最常见的问题有三个：第一，node_exporter采集不到GPU或RAID信息，这是因为需要额外安装nvidia-smi或mdadm工具，并且启动时加对应参数；第二，Prometheus抓取超时，通常是node_exporter响应太慢或者网络不通，检查9100端口连通性和node_exporter的CPU占用；第三，指标太多导致Prometheus内存飙升，可以通过metric_relabel_configs过滤掉不需要的指标，比如：

metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'node_cpu_.*'
    action: keep


只保留CPU相关指标，其他全部丢弃，能显著降低内存消耗。另外，定期用promtool检查配置文件语法是否正确，避免配置错误导致Prometheus起不来：

promtool check config /etc/prometheus/prometheus.yml


总结一下，Prometheus+node_exporter在Ubuntu上的部署本身并不复杂，真正拉开差距的是后续的规则优化、告警策略、存储方案和可视化展示（搭配Grafana效果最佳）。把基础打牢，监控体系才能真正为运维减负而不是添乱。