Prometheus + Grafana 监控系统零基础上手指南

第一章：监控系统概述与选型

什么是监控系统？

想象一下，你运营着一个网站或服务器集群。用户反馈网站打开慢，你怎么定位问题？是服务器 CPU 打满了？网络带宽不够？还是某个接口响应慢？如果没有监控系统，你只能靠猜、靠试、甚至靠用户投诉来发现问题。这种被动运维的方式，效率低、影响大。

监控系统就是为了解决这些问题而诞生的。它的核心思想很简单：让看不见的变成看得见的。通过采集、存储和分析系统运行时的各类数据（CPU 使用率、内存占用、网络流量、请求延迟等），帮助运维人员实时掌握系统状态，快速定位故障根因。

一个成熟的监控系统通常具备以下能力：

• 数据采集：从各种目标（服务器、应用、网络设备）收集指标数据
• 数据存储：将时序数据持久化保存
• 可视化展示：通过图表、仪表盘呈现数据
• 告警通知：当指标异常时及时通知相关人员

Prometheus 简介

Prometheus 是由 SoundCloud 公司于 2012 年开源的系统监控和告警工具，2016 年加入 CNCF（云原生计算基金会），是与 Kubernetes 同级的核心项目。如今 Prometheus 已成为云原生时代监控领域的事实标准，被广泛应用于各种规模的 IT 基础设施。

核心特性

Prometheus 有以下几个核心特性：

多维数据模型：Prometheus 以时间序列的形式存储数据，每条数据由指标名称和一组键值对标签组成。这种设计让查询变得非常灵活——你可以按服务名、环境、区域等多种维度筛选和聚合数据。

拉模式采集：不同于传统推模式（被监控端主动上报），Prometheus 采用拉模式（Prometheus 主动抓取）。这种方式的优势在于：

• 监控端点无状态，架构简单
• 便于实现服务发现
• 数据一致性有保障

灵活的查询语言 PromQL：PromQL 是 Prometheus 的灵魂。通过它你可以对采集的指标进行过滤、聚合、计算，生成各种维度的分析视图。

无依赖分布式存储：Prometheus 是单节点设计，数据存储在本地磁盘。这不是说它只能监控单机——而是每个 Prometheus 实例独立运行，通过联邦机制实现集群级别的监控。

架构概览

Prometheus 的工作流程如下：

1. Prometheus Server 定时从配置的目标（Target）抓取指标数据
2. 采集的数据存储在本地的时序数据库中
3. 用户通过 Web UI 或 API 使用 PromQL 查询数据
4. 可选：配置 Recording Rules 预计算常用聚合；配置 Alertmanager 发送告警

简单来说，Prometheus = 数据采集 + 数据存储 + 数据查询。

适用场景

Prometheus 特别适合以下场景：

• 面向服务的架构（微服务）
• 需要多维度灵活查询的监控
• 云原生环境（Kubernetes 原生支持）
• 需要快速定位问题的可观测性建设

Prometheus 也有不擅长的场景：如果你的业务需要 100% 精确计费（如按 API 调用次数收费），或者需要跨服务的事务追踪，请选择其他专业工具。

Grafana 简介

Prometheus 解决了"采什么、怎么存、怎么查"的问题，但它自带的 Web UI 并不擅长数据可视化。这时就需要 Grafana 出场了。

Grafana 是一个开源的可视化平台，支持查询和展示来自多种数据源的数据。它的特点可以用一句话概括：把复杂的数据变成漂亮的图表。

支持的数据源

Grafana 真正厉害的地方在于它的数据源生态。目前官方支持 150+ 种数据源，涵盖：

也就是说，无论你的数据存在哪里，Grafana 基本都能对接。

核心功能

Grafana 的核心功能包括：

仪表盘：通过拖拽的方式组合多个图表，打造专属监控视图。仪表盘支持变量、模板，可以一套模板适配多种环境。

告警规则：除了可视化，Grafana 还支持配置告警规则。当指标超过阈值时，通过邮件、钉钉、飞书等渠道发送通知。

Explore：快速查询和探索数据的工具，不需要先创建仪表盘。

Grafana 版本

Grafana 有两个主要版本：

Grafana OSS（开源版）：包含所有核心功能，免费使用。

Grafana Enterprise（企业版）：在开源版基础上增加了一些高级功能（如数据源插件、商业支持），适合大型企业。

Prometheus + Grafana：黄金组合

为什么说 Prometheus + Grafana 是监控领域的黄金组合？

各司其职：Prometheus 专注于数据采集和存储，Grafana 专注于可视化。你不需要为了某个功能迁就另一个工具。

无缝集成：Grafana 提供了官方的 Prometheus 数据源插件，配置简单，查询体验和 Prometheus Web UI 一致。

生态丰富：Prometheus 社区贡献了大量 Exporter，可以监控 MySQL、Nginx、Kubernetes、Redis 等几乎所有常见技术栈。Grafana 则有海量的社区仪表盘可供参考。

免费且开源：两者都是开源项目，可以自由使用和二次开发。

用一句话总结这个组合：Prometheus 负责埋头采集数据，Grafana 负责把数据讲成故事。

本章小结

本章我们了解了监控系统的基本概念，以及 Prometheus 和 Grafana 各自的定位和优势。Prometheus 以拉模式、多维数据模型、PromQL 等特性成为云原生监控的首选；Grafana 以强大的可视化能力和广泛的数据源支持，成为指标展示的不二之选。两者组合，形成了从数据采集到可视化展示的完整闭环。

接下来的章节，我们将手把手实践这个组合：从安装 Prometheus 开始，到配置监控目标，再到用 Grafana 打造漂亮的仪表盘。

第二章：Prometheus 安装与快速入门

经过第一章的学习，你已经对 Prometheus 有了初步认识，了解了它是什么以及核心的数据模型和查询语言。从本章开始，我们正式进入动手实践环节，一起来完成 Prometheus 的安装、配置与初次体验。

本章将手把手带领你完成以下任务：

• 下载并解压 Prometheus Linux 二进制包
• 编写并理解 Prometheus 配置文件
• 启动 Prometheus 并访问内置 Web UI
• 验证监控数据是否正常采集

整个过程不依赖任何包管理器，无需 root 权限，非常适合初学者入门。

2.1 下载 Prometheus 安装包

Prometheus 官方为 Linux（amd64）、macOS（Darwin）和 Windows 等主流平台提供了预编译的二进制安装包。本章我们以 Linux amd64 平台为例进行演示。

2.1.1 访问下载页面

打开浏览器，访问 Prometheus 官方下载页面：https://prometheus.io/download/

向下滚动找到 Prometheus 主程序，选择适合你系统的版本。以 Linux amd64 为例，下载文件名类似 prometheus-3.2.1.linux-amd64.tar.gz（版本号可能不同，请以实际下载页面为准）。

2.1.2 使用命令行下载

如果你在 Linux 服务器上操作，可以直接用 curl 或 wget 下载（将版本号替换为实际版本）：

curl -LO https://github.com/prometheus/prometheus/releases/download/v3.2.1/prometheus-3.2.1.linux-amd64.tar.gz

💡 小提示：国内网络访问 GitHub 较慢时，可以使用前面提到的 GitHub 镜像地址，例如：

curl -LO https://mirror.skon.top/github.com/prometheus/prometheus/releases/download/v3.2.1/prometheus-3.2.1.linux-amd64.tar.gz

2.1.3 解压安装包

下载完成后，在终端中执行以下命令解压：

tar -xzvf prometheus-3.2.1.linux-amd64.tar.gz

解压成功后，会在当前目录下生成一个名为 prometheus-3.2.1.linux-amd64 的文件夹。切换到该目录，查看其中的文件结构：

cd prometheus-3.2.1.linux-amd64
ls -la

一个典型的目录结构如下：

.
├── console_libraries/      # 控制台模板库
├── consoles/              # 控制台页面
├── prometheus.yml         # 主配置文件
├── prometheus             # Prometheus 可执行文件
├── promtool               # 规则校验工具
└── LICENSE

其中 prometheus 就是我们接下来要启动的主程序，prometheus.yml 是配置文件。

2.2 配置文件结构解析

在启动 Prometheus 之前，我们需要先了解它的配置文件。Prometheus 的配置通过 YAML 格式的文件指定，名为 prometheus.yml。Prometheus 支持监控自身，因此一个最基本的配置就能让 Prometheus 监控自己。

2.2.1 最小配置示例

让我们从最简单的配置开始。请将以下内容写入 prometheus.yml 文件：

global:
  scrape_interval: 15s        # 全局抓取间隔，默认每 15 秒抓取一次目标

scrape_configs:
  - job_name: 'prometheus'    # 作业名称，作为标签附加到所有指标上
    static_configs:           # 静态配置方式
      - targets: ['localhost:9090']   # 抓取目标地址

这段配置的完整含义如下：

• global.scrape_interval：全局默认抓取间隔为 15 秒，即 Prometheus 每隔 15 秒向配置的目标发起一次 HTTP 请求获取指标数据。
• scrape_configs：定义了所有抓取目标的列表，是一个数组。
• job_name：每个抓取任务（Job）的名称，这里设为 prometheus。该名称会自动作为标签 job="prometheus" 附加到所有从该目标抓取的指标上。
• static_configs.targets：目标地址数组，格式为 主机:端口。这里配置的是 localhost:9090，即 Prometheus 自身暴露的指标端点。

2.2.2 常见配置参数一览

以下是 Prometheus 配置文件中最常用的一些参数说明：

⚠️ 注意：YAML 文件对缩进非常敏感，请使用空格（不要使用 Tab）进行缩进，建议每级缩进两个空格。

2.2.3 带标签分组的配置示例

在实际生产环境中，我们通常会为不同的目标组打上不同的标签，以便后续在查询时进行过滤。来看一个更完整的配置示例：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

  - job_name: 'node'
    scrape_interval: 10s
    static_configs:
      - targets: ['localhost:9100', 'localhost:9101']
        labels:
          group: 'production'
      - targets: ['localhost:9102']
        labels:
          group: 'canary'

上述配置中，node 作业覆盖了全局的抓取间隔（10 秒而非 15 秒），并通过 labels 为不同的目标组打上了 group 标签：production（生产环境）和 canary（金丝雀环境）。

2.3 启动 Prometheus 并访问 Web UI

配置文件准备好了，接下来启动 Prometheus。

2.3.1 直接启动

在 Prometheus 解压目录下执行以下命令：

./prometheus --config.file=prometheus.yml

正常情况下，你会看到类似以下输出：

ts=2026-03-26T08:00:00.000Z caller=main.go:543 level=info msg="Starting Prometheus" version="(version=3.2.1)"
ts=2026-03-26T08:00:00.001Z caller=main.go:544 level=info component=agent state=starting
ts=2026-03-26T08:00:00.002Z caller=main.go:595 level=info msg="Listening on :9090"
...

最后一行 Listening on :9090 表示 Prometheus 已经成功启动，正在监听 9090 端口。

2.3.2 访问 Web UI

打开浏览器，访问以下地址：

http://localhost:9090

如果一切正常，你会看到 Prometheus 的内置 Web 界面。界面主要包含以下几个页面：

• Status → Targets：查看所有抓取目标的状态，可以在这里确认每个目标是否在线以及最后抓取的时间。
• Graph：表达式浏览器，可以输入 PromQL 查询语句并查看结果。
• Status → Configuration：查看当前加载的配置文件内容。
• Status → Rules：查看加载的告警规则和录制规则。

💡 小提示：如果是在远程服务器上安装，需要确保 9090 端口已在防火墙中开放，或者通过 SSH 端口转发在本地浏览器中访问：ssh -L 9090:localhost:9090 user@server-ip。

2.3.3 后台运行与进程管理

如果你希望 Prometheus 在后台持续运行，可以使用 nohup 或 systemd 管理：

# 使用 nohup 后台运行
nohup ./prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

# 查看 Prometheus 进程
ps aux | grep prometheus

# 关闭 Prometheus（发送 SIGTERM 信号，优雅关闭）
kill -s SIGTERM $(pgrep prometheus)

2.4 验证监控数据

Prometheus 启动后，我们需要确认它是否真的在采集数据。

2.4.1 查看指标端点

Prometheus 自身会在 /metrics 路径上暴露所有采集到的指标数据。直接在浏览器中访问：

http://localhost:9090/metrics

你会看到一大段以 Prometheus 自身运行数据为主的文本内容，格式类似如下：

# HELP prometheus_target_interval_length_seconds Actual intervals between scrapes
# TYPE prometheus_target_interval_length_seconds summary
prometheus_target_interval_length_seconds{quantile="0.99"} 15.000542324
prometheus_target_interval_length_seconds{quantile="0.9"} 15.000234421
prometheus_target_interval_length_seconds_sum 1234567.890
prometheus_target_interval_length_seconds_count 82345

这些就是 Prometheus 导出的时间序列指标数据，每一行代表一个样本值。

2.4.2 使用表达式浏览器查询

回到 Web UI，点击顶部导航栏的 Graph，然后在查询框中输入以下 PromQL 语句，点击 Execute 执行查询：

prometheus_target_interval_length_seconds

你应该能看到多条返回结果，每条结果的指标名相同但标签（label）不同——这是因为 Prometheus 记录了不同分位数（quantile）下的抓取间隔。

如果只关心第 99 百分位的延迟，可以这样查询：

prometheus_target_interval_length_seconds{quantile="0.99"}

如果想统计当前共有多少条时间序列，可以输入：

count(prometheus_target_interval_length_seconds)

2.4.3 查看抓取目标状态

点击导航栏 Status → Targets，你会看到一个目标列表，显示 prometheus 作业的 localhost:9090 目标状态为 UP，表示抓取成功。如果状态为 DOWN，则需要检查目标服务是否正常运行，以及网络连通性是否正常。

2.5 一条命令完成快速启动

为了方便你快速体验，我们把前面的步骤浓缩为以下一组命令。假设你在 Linux amd64 服务器上操作：

# 1. 下载（请将版本号替换为最新版本）
curl -LO https://github.com/prometheus/prometheus/releases/download/v3.2.1/prometheus-3.2.1.linux-amd64.tar.gz

# 2. 解压
tar -xzvf prometheus-3.2.1.linux-amd64.tar.gz
cd prometheus-3.2.1.linux-amd64

# 3. 启动（使用默认最小配置，无需额外编辑文件）
./prometheus --config.file=prometheus.yml

# 4. 打开浏览器访问 http://localhost:9090

就是这样简单！Prometheus 开箱即用，即便不修改任何配置，也能立即监控自己。

2.6 本章小结

本章完成了以下关键任务：

1. 下载安装：从官方渠道获取 Prometheus Linux amd64 二进制包，解压后即可使用，无需安装任何依赖。
2. 配置解析：通过 YAML 格式的 prometheus.yml 文件定义抓取目标和抓取策略，掌握了 global、scrape_configs、job_name、targets 等核心配置项的含义。
3. 启动访问：使用 ./prometheus --config.file=prometheus.yml 启动服务，通过浏览器访问 http://localhost:9090 进入 Web UI。
4. 数据验证：通过 /metrics 端点和表达式浏览器确认 Prometheus 已成功采集并存储了自身的时间序列数据。

至此，Prometheus 的安装和基本使用已全部完成。在下一章中，我们将引入 Node Exporter——一个用于暴露 Linux 系统硬件和操作系统指标的轻量级Exporter，从而将 Prometheus 的监控范围从自身扩展到真实的服务器系统指标，为后续接入 Grafana 可视化打下基础。

📚 延伸阅读

• Prometheus 官方配置文档：https://prometheus.io/docs/prometheus/latest/configuration/configuration/
• Prometheus 官方快速入门：https://prometheus.io/docs/prometheus/latest/getting_started/
• Prometheus 中文社区：https://prometheus.ac.cn/

第三章：PromQL 基础查询

什么是 PromQL

PromQL（Prometheus Query Language）是 Prometheus 监控系统提供的一种功能性查询语言。它的设计目标很简单：让你能够从海量的时间序列数据中，精准地筛选、计算和聚合出想要的信息。无论是在 Prometheus 自带的 Web UI 中绘制图表，还是在 Grafana 中配置仪表盘，底层都在使用 PromQL 来完成数据查询。

PromQL 的查询可以分为两种类型：即时查询（Instant Query） 和 范围查询（Range Query）。即时查询在某个具体的时间点评估一次表达式，返回该时刻的一组时间序列；范围查询则在一定时间范围内，以固定步长反复评估表达式，返回每个时间点上的数据序列。在 Prometheus UI 中，"Table"选项卡对应即时查询，"Graph"选项卡对应范围查询。

理解 PromQL 的返回值类型非常重要。表达式的结果可以是以下四种数据类型之一：

• 即时向量（Instant Vector）：一组时间序列，每个序列在当前时间戳只有一个样本值，这是最常用的返回类型。
• 范围向量（Range Vector）：一组时间序列，每个序列在指定时间范围内有多个样本值。
• 标量（Scalar）：一个单独的数值，没有关联的时间序列标签。
• 字符串（String）：一个字符串值，目前在 PromQL 中暂未广泛使用。

时间序列与标签

在深入学习查询语法之前，我们需要先理解 Prometheus 中时间序列的组织方式。

每一条时间序列由以下三部分组成：

• 指标名称（Metric Name）：描述被测量的对象是什么，例如 http_requests_total 表示 HTTP 请求的总数。
• 标签（Labels）：键值对，用于区分同一指标的不同实例，例如 {job="api-server", status="200"}。
• 样本值（Sample Value）：某个时刻的实际测量数值。

标签是 Prometheus 数据模型中最强大的特性之一。通过标签的组合，我们可以从不同维度切分和筛选数据。例如，同一个指标名 cpu_usage 可能出现在 Web 服务器、数据库服务器、缓存服务器等多种实例上，通过标签就能把它们区分开来。

Prometheus 支持以下几种标签匹配操作符：

• =：精确匹配标签值。
• !=：不等于匹配，排除具有特定标签值的序列。
• =~：正则表达式匹配。
• !~：正则表达式不匹配。

# 精确匹配：只查询 API 服务器的请求
http_requests_total{job="api-server"}

# 正则匹配：查询所有以"api"开头的 job
http_requests_total{job=~"api.*"}

# 排除某个标签值
http_requests_total{job!="batch-worker"}

基础查询（选择器）

即时向量选择器

即时向量选择器是 PromQL 中最基础、最常用的查询语法。它的作用是：在指定时间点上，选取一组符合条件的时间序列。

最简单的情况是只写指标名称，查询该指标下所有的序列：

http_requests_total

加上标签过滤后，可以精确定位到某个服务或实例：

# 只查询 API 服务器且状态码为 200 的请求
http_requests_total{job="api-server", status="200"}

范围向量选择器

范围向量选择器用于查询一段时间内的数据序列。语法上是在即时向量选择器后面加上方括号，里面写时间范围：

# 查询 API 服务器在过去 5 分钟内的所有请求数据点
http_requests_total{job="api-server"}[5m]

方括号里的 5m 表示回溯 5 分钟，m 代表分钟。常用时间单位包括：s（秒）、m（分钟）、h（小时）、d（天）、w（周）。

Offset 修饰符

有时候我们需要查询过去某个时间点的数据，而不是当前时刻的值。这时可以使用 offset 修饰符：

# 查询 1 小时前的请求总量
http_requests_total offset 1h

# 查询 7 天前的增长率
rate(http_requests_total[5m] offset 7d)

@ 修饰符

@ 修饰符允许在指定的具体时间戳上评估查询，而不是使用当前时间。这在需要对比历史数据时非常有用：

# 查询 2024 年 1 月 1 日零点零分零秒时刻的 CPU 使用率
node_cpu_usage @ 1704067200

聚合操作

仅靠选择器往往无法满足分析需求，我们需要对选中的时间序列进行聚合计算。PromQL 内置了一系列聚合函数，最常用的包括：

聚合操作通常需要配合 by 或 without 子句使用，明确按照哪些标签进行分组聚合：

# 按 job 标签分组，统计每个服务的总请求数
sum by (job) (http_requests_total)

# 按 service 标签分组，计算平均响应时间
avg by (service) (http_request_duration_seconds_sum / http_request_duration_seconds_count)

# 统计所有运行的实例数量
count by (job) (up)

如果不使用 by 子句，聚合会将所有匹配的时间序列合并成一个全局结果：

# 所有实例的请求总量
sum(http_requests_total)

常用函数

rate() — 计算平均增长率

rate() 是 Prometheus 中使用最频繁的函数之一。它计算范围向量中每个时间序列的每秒平均增长率，专门用于处理单调递增的计数器数据（例如请求数、字节数等）。

# 计算 API 服务器过去 5 分钟的每秒平均请求速率
rate(http_requests_total{job="api-server"}[5m])

rate() 会自动处理计数器重置的情况（例如目标服务重启导致计数器归零），因此特别适合用于告警规则和绘制长期变化趋势的图表。

increase() — 计算增量

increase() 计算指定时间范围内指标的增量值，本质上是 rate() 乘以时间范围秒数的结果：

# 计算 API 服务器过去 1 小时的请求增量（总数）
increase(http_requests_total{job="api-server"}[1h])

在告警规则中推荐使用 rate()，而在需要向非技术人员解释数据时，increase() 的结果更加直观。

irate() — 计算瞬时增长率

与 rate() 计算平均值不同，irate() 基于范围向量中的最后两个数据点计算每秒瞬时增长率：

# 计算最近 5 分钟内最后两个点的瞬时请求速率
irate(http_requests_total{job="api-server"}[5m])

irate() 适合用来观察变化剧烈、波动大的指标，例如短期内的流量峰值。但正因为只看最后两个点，它不适合用于告警（容易产生误报）。总结下来：

• 告警场景：使用 rate()
• 长期趋势图：使用 rate()
• 短期波动图：使用 irate()

absent() — 检测序列是否存在

absent() 是一个非常有用的辅助函数。当传入的向量没有任何元素时，它返回一个值为 1 的单元素向量，常用于告警中检测某个指标是否停止上报：

# 如果 api-server 没有任何请求数据，说明可能出了问题
absent(http_requests_total{job="api-server"})
# => 如果不存在该序列，返回 {job="api-server"}，值为 1

label_join() 和 label_replace() — 标签操作

有时候我们需要对标签进行二次加工，这可以用 label_join() 和 label_replace() 实现：

# 将 instance 和 port 标签拼接成一个新的地址标签
label_join(http_requests_total, "address", ":", "instance", "port")

# 从 instance 中提取 IP 部分，创建新的 ip 标签
label_replace(http_requests_total, "ip", "$1", "instance", "(.*):\\d+")

时间聚合函数

如果需要在查询中对多个时间点进行聚合，可以使用 _over_time() 系列函数：

# 过去 10 分钟内 CPU 的平均使用率
avg_over_time(node_cpu_seconds_total{mode="idle"}[10m])

# 过去 1 小时内内存可用量的最大值
max_over_time(node_memory_MemAvailable_bytes[1h])

# 过去 30 分钟内请求延迟的第 95 百分位数
quantile_over_time(0.95, http_request_duration_seconds_bucket[30m])

实际使用建议

在使用 PromQL 时，有几点实践经验值得分享：

先在 Table 视图中验证查询结果。 在 Prometheus UI 的 Table 选项卡下构建和调试查询，等结果集符合预期后再切换到 Graph 视图绘制图表，可以避免因为查询范围过大导致界面卡顿。

注意时间范围的选择。 范围向量的时间窗口不宜过短（可能导致数据点稀疏），也不宜过长（会增加计算开销）。对于大多数场景，[5m] 到 [15m] 是比较合理的起点。

合理使用正则匹配。 正则表达式虽然灵活，但会带来额外的计算开销。在高频查询的场景中，尽量使用精确匹配或前缀匹配替代复杂正则。

小结

本章我们从零认识了 PromQL 的核心概念：时间序列的组成、即时向量和范围向量的查询方法、标签匹配操作符、聚合计算以及最常用的 rate / increase / irate 三个函数。这些内容构成了日常监控查询的基石——掌握好它们，你已经能够独立完成大部分的 Prometheus 数据探索工作了。

下一章我们将介绍 PromQL 的进阶内容，包括二元操作符、更多的聚合函数、以及如何用 PromQL 处理直方图和百分位数数据。

参考链接

• PromQL 官方文档
• Prometheus Query Functions
• Prometheus Operator 与 PromQL

第四章：Node Exporter 主机监控

在前两章中，我们学会了安装 Prometheus 并让它监控自身。然而 Prometheus 无法直接采集 MySQL、Nginx、操作系统等"没有 /metrics 接口"的目标。此时需要借助 Exporter——一种专门将第三方数据转换为 Prometheus 标准格式的中间层程序。本章以官方维护的 Node Exporter 为例，完整演示从安装到配置的全过程。

什么是 Exporter

Exporter 可以理解为一个"翻译官"。它运行在被监控目标旁边，通过系统调用、文件读取或协议连接等方式采集原始数据，然后以 /metrics 格式暴露出来，供 Prometheus 抓取。

常见的 Exporter 包括：

所有 Exporter 都遵循同一模式：采集数据 → 转换为 Prometheus 格式 → 暴露 /metrics 端点。掌握一种，其他上手很快。

Node Exporter 安装与启动

Node Exporter 是 Prometheus 官方提供的 Linux/Unix 系统监控 Exporter，以单个静态二进制文件形式分发，无需安装任何依赖。

下载并运行

以 Linux amd64 为例：

# 下载（替换版本号为最新版本）
wget https://github.com/prometheus/node_exporter/releases/download/v1.10.2/node_exporter-1.10.2.linux-amd64.tar.gz
tar xvfz node_exporter-1.10.2.linux-amd64.tar.gz
cd node_exporter-1.10.2.linux-amd64

# 启动
./node_exporter

看到如下输出即表示启动成功，Node Exporter 已在 9100 端口上监听：

INFO[0000] Listening on :9100  source="node_exporter.go:111"

注册为 systemd 服务

生产环境建议以服务方式运行。创建 systemd Unit 文件：

[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable node-exporter
sudo systemctl start node-exporter

验证指标是否正常

curl http://localhost:9100/metrics

返回内容中应以 node_ 为前缀——说明 Node Exporter 已在正常采集系统数据了。

配置 Prometheus 抓取 Node Exporter

在 prometheus.yml 的 scrape_configs 下添加抓取任务：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

监控多台服务器时，只需在 targets 中添加更多地址：

  - job_name: 'node'
    scrape_interval: 30s
    static_configs:
      - targets:
          - '10.10.10.200:9100'
          - '10.10.10.128:9100'
        labels:
          group: 'linux-servers'

修改配置后热重载：

kill -SIGHUP $(pgrep prometheus)

访问 http://localhost:9090/targets，确认 node 任务状态为 UP。

常用监控指标解读

Node Exporter 暴露的指标均以 node_ 为前缀。下面按四大维度讲解常用指标，配合 PromQL 示例。

CPU 监控

node_cpu_seconds_total 记录各模式下的 CPU 时间消耗，通过 rate() 计算使用率：

# CPU 总使用率（平均值）
1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)

# 按模式查看 CPU 时间占比
avg by (mode) (rate(node_cpu_seconds_total[5m]))

内存监控

核心指标为 node_memory_MemTotal_bytes（总内存）和 node_memory_MemAvailable_bytes（可用内存）：

# 内存使用率（百分比）
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
  / node_memory_MemTotal_bytes * 100

# Swap 已用空间
node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes

Swap 使用量过高通常意味着物理内存不足，需要考虑扩容或优化。

磁盘监控

关注存储空间和 I/O 性能：

# 各挂载点磁盘使用率（百分比）
(1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100

# 磁盘读取速率（bytes/s）
rate(node_disk_read_bytes_total[5m])

# 磁盘写入速率（bytes/s）
rate(node_disk_written_bytes_total[5m])

网络监控

网卡流量监控：

# 网卡入方向流量（bytes/s），注意替换 device 名称
rate(node_network_receive_bytes_total{device="eth0"}[5m])

# 网卡出方向流量（bytes/s）
rate(node_network_transmit_bytes_total{device="eth0"}[5m])

注意：网卡设备名因系统而异，可能为 eth0、ens33、enp0s3 等，可通过 node_network_receive_bytes_total 上的设备标签确认。

小结

本章完成了以下内容：

1. 理解 Exporter 的定位——它是 Prometheus 与各类目标之间的数据"翻译层"。
2. 完成 Node Exporter 安装与启动——二进制文件直接运行或注册为 systemd 服务，在 9100 端口暴露指标。
3. 配置 Prometheus 抓取任务——在 prometheus.yml 中添加 node job，实现周期性数据拉取。
4. 掌握四大核心指标的 PromQL 查询——CPU 利用率、内存使用率、磁盘空间与 I/O、网络流量。

这些内容构成了主机监控的基础。下一章我们将学习如何用 Grafana 将这些指标数据可视化，构建美观的监控仪表盘。

参考链接

• Node Exporter 官方 GitHub
• Node Exporter 下载页面
• Prometheus 配置参考
• Node Exporter Textfile Collector