3、Prometheus快速上手：安装部署、配置文件结构、第一个监控目标（node_exporter）的接入与数据采集

本章将带领你从零开始，完成Prometheus监控体系的第一块拼图。我们将以最直接的方式，完成Prometheus服务端的安装与启动，深入剖析其核心配置文件 prometheus.yml 的结构与逻辑，并接入第一个监控目标——node_exporter，最终在Prometheus自带的Web界面中验证主机指标数据的采集链路。这一过程是后续所有监控、告警与可视化工作的基石，理解其数据流模型至关重要。

上图清晰地展示了Prometheus主动拉取（Pull）模式的架构。Prometheus Server根据 scrape_configs 中定义的目标（Target），周期性地通过HTTP协议从 node_exporter 暴露的 /metrics 端点拉取指标数据。这种模式使得监控端无需在被监控端安装Agent，且被监控端只需暴露一个HTTP端点即可，极大地简化了运维复杂度。

3.1 安装部署：二进制与容器化双路径

Prometheus本身是一个用Go语言编写的单二进制文件，部署极为简单。我们推荐两种主流方式：二进制直接部署（适用于物理机或虚拟机）和 Docker容器化部署（适用于云原生环境）。无论哪种方式，核心都是获取Prometheus主程序与配置文件。

3.1.1 二进制安装（以Linux为例）

首先，从Prometheus官网下载最新稳定版（此处以 v2.53.0 为例）。你需要根据你的系统架构选择对应的压缩包。

# 1. 下载并解压
wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
tar xvf prometheus-2.53.0.linux-amd64.tar.gz
cd prometheus-2.53.0.linux-amd64

# 2. 查看目录结构
ls -l
# 总用量 220M
# -rw-r--r-- 1 root root  11357 6月  20 22:00 LICENSE
# -rw-r--r-- 1 root root   3773 6月  20 22:00 NOTICE
# -rw-r--r-- 1 root root   1023 6月  20 22:00 prometheus.yml
# -rwxr-xr-x 1 root root 220M 6月  20 22:00 prometheus

# 3. 启动Prometheus（默认加载当前目录下的prometheus.yml）
./prometheus --config.file=prometheus.yml

启动后，控制台会输出日志，包括监听端口（默认9090）和存储路径（默认 data/）。此时，你可以通过浏览器访问 http://<服务器IP>:9090 访问Prometheus自带的简易Web界面。

3.1.2 Docker容器化部署

容器化部署更加简洁，且便于版本管理与环境隔离。我们使用Docker运行Prometheus，并将配置文件挂载到容器内。

# 1. 创建配置目录
mkdir -p /opt/prometheus
cd /opt/prometheus

# 2. 创建最小可用的prometheus.yml（内容见下一节）
vim prometheus.yml

# 3. 运行容器
docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
  -v /opt/prometheus/data:/prometheus \
  prom/prometheus:v2.53.0

这里使用了 -v 参数将宿主机上的配置文件和数据目录挂载进容器，确保配置修改后无需重建容器，且数据在容器删除后依然保留。

3.2 配置文件结构：prometheus.yml 深度解析

Prometheus的配置基于YAML格式，虽然字段众多，但核心结构清晰。一个标准的 prometheus.yml 由四个顶级配置块组成：global、rule_files、scrape_configs 和 alerting。下表总结了它们的作用与关键参数：

下面是一个最精简但可运行的 prometheus.yml 示例，它包含了抓取Prometheus自身和后续要接入的node_exporter的配置：

# 全局配置
global:
  scrape_interval: 15s   # 默认每15秒抓取一次目标
  evaluation_interval: 15s # 默认每15秒评估一次告警规则

# 告警规则文件（暂不配置）
rule_files:
  # - "first_rules.yml"

# 抓取配置列表
scrape_configs:
  # 任务名称，会在指标和标签中体现
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]  # 抓取Prometheus自身

  - job_name: "node_exporter"
    static_configs:
      - targets: ["localhost:9100"]  # 抓取node_exporter

3.3 接入第一个监控目标：node_exporter

node_exporter是Prometheus官方提供的主机指标采集器，它能够收集丰富的系统级指标，如CPU使用率、内存占用、磁盘I/O、网络流量等。接入过程分为两步：启动node_exporter 和 在Prometheus中配置抓取。

3.3.1 启动node_exporter

同样，我们采用二进制方式启动（容器方式类似）。下载并解压后，直接运行即可。

# 下载并解压（以0.41.0版本为例）
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xvf node_exporter-1.8.2.linux-amd64.tar.gz
cd node_exporter-1.8.2.linux-amd64

# 启动node_exporter，默认监听9100端口
./node_exporter

启动后，你可以通过 curl http://localhost:9100/metrics 验证指标是否正常输出。该端点会返回大量以 # HELP 和 # TYPE 开头的注释行，以及具体的指标数据行，例如：

# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 35241.92
node_cpu_seconds_total{cpu="0",mode="system"} 67.34

3.3.2 配置Prometheus抓取node_exporter

修改 prometheus.yml，在 scrape_configs 下添加一个新的job。然后，通过 kill -HUP <Prometheus进程PID> 或重启Prometheus服务使配置生效。

scrape_configs:
  - job_name: "node_exporter"
    static_configs:
      - targets: ["192.168.1.100:9100"]  # 替换为运行node_exporter的机器IP

3.4 验证数据采集：从Target状态到PromQL查询

配置完成后，我们需要验证整个链路是否通畅。Prometheus提供了两种最直接的验证方式。

3.4.1 检查Targets页面

访问 http://<Prometheus服务器IP>:9090/targets，你会看到所有配置的抓取任务列表。重点关注 State 列，如果显示为 UP，表示抓取成功；如果显示为 DOWN，则需要检查网络连通性、端口监听状态或配置文件中的地址是否正确。

3.4.2 使用PromQL查询指标

点击顶部菜单 Graph，进入查询页面。在输入框中输入以下PromQL表达式，点击 Execute 即可看到结果。

# 查询node_exporter启动后的运行时长（单位：秒）
time() - node_boot_time_seconds

# 查询CPU空闲时间占比（示例）
rate(node_cpu_seconds_total{mode="idle"}[5m])

如果返回了数值，恭喜你，Prometheus已经成功采集到了主机指标，数据采集链路正式打通。

3.5 实战案例：一次典型的接入排障过程

让我们通过一个真实场景来巩固所学知识。假设你在一台新分配的服务器 10.0.0.5 上部署了node_exporter，并在Prometheus中配置了抓取，但Targets页面显示 DOWN。

初始现象：Targets页面中 http://10.0.0.5:9100/metrics 状态为 DOWN，错误信息显示 Get "http://10.0.0.5:9100/metrics": dial tcp 10.0.0.5:9100: connect: connection refused。

分析判断过程：错误信息中的 connection refused 通常意味着目标端口没有进程在监听，或者被防火墙拦截。我们按照以下步骤排查：

1. 检查进程：在 10.0.0.5 上执行 ps aux | grep node_exporter，确认进程是否存在。
2. 检查端口：执行 ss -lntp | grep 9100，确认端口是否处于 LISTEN 状态。
3. 检查防火墙：执行 systemctl status firewalld 或 iptables -L -n，查看是否有规则拦截了来自Prometheus服务器的访问。

实际操作与结果：经过检查，发现node_exporter进程已退出。查看日志发现是因为缺少系统依赖库导致启动失败。重新编译或安装依赖后，再次启动node_exporter，Targets状态立即变为 UP。

复盘经验：大多数 DOWN 问题都源于三个层面：进程未启动、端口未监听、网络不通。建议在Prometheus服务器上使用 telnet 10.0.0.5 9100 或 curl -v http://10.0.0.5:9100/metrics 来快速定位是网络层问题还是应用层问题。

3.6 常见误区与总结复盘

在快速上手过程中，初学者容易陷入以下几个误区，需要特别留意：

• 误区一：混淆Pull与Push模式。Prometheus是Pull模型，它主动去目标拉取数据。如果目标在防火墙后面或地址变化，需要借助服务发现或Pushgateway（后续章节会讲）来解决，而不是试图让目标主动上报。
• 误区二：忽略标签的作用。在配置多个相同应用实例时，务必通过 labels 字段添加区分性标签（如 env="prod"），否则后续查询和告警将无法区分不同实例。
• 误区三：抓取间隔设置过短。全局 scrape_interval 设置为1s甚至更短，会对目标和Prometheus自身造成不必要的性能压力。默认15s对于绝大多数场景已经足够。
• 误区四：修改配置后不校验。直接重启Prometheus可能导致因YAML语法错误而启动失败。建议使用 ./promtool check config prometheus.yml 命令预先校验配置文件的正确性。