Prometheus + Grafana 监控系统零基础上手指南（进阶篇）

第五章：Grafana 安装与 Prometheus 联动

前面几章我们已经完成了 Prometheus 的安装、配置以及 Node Exporter 的部署，系统能够正常采集并存储各项监控指标数据。然而，当我们需要更直观、更灵活地展示这些数据时，Prometheus 内置的 Web UI 就显得有些简陋了——它不支持仪表盘定制、不支持多图表联动、也无法设置告警规则。这时候就需要引入 Grafana 来补足这些能力。

Grafana 是目前开源社区最流行的监控可视化平台，支持超过数十种数据源，提供丰富的图表类型、灵活的仪表盘构建以及强大的告警功能。在 Prometheus 生态中，Grafana 几乎已经成为标准配置。本章将详细介绍如何通过 Docker 一键启动 Grafana，并完成与 Prometheus 的联动配置。

一、Grafana 安装（Docker 一键启动）

Grafana 的安装方式非常多，最简单快捷的方式就是使用 Docker。我们只需要一条命令就能将 Grafana 启动起来，不需要关心复杂的依赖关系。

docker run -d \
  --name=grafana \
  -p 3000:3000 \
  -e GF_SECURITY_ADMIN_USER=admin \
  -e GF_SECURITY_ADMIN_PASSWORD=admin123 \
  -e GF_USERS_ALLOW_SIGN_UP=false \
  -v grafana-data:/var/lib/grafana \
  grafana/grafana:latest

上述命令的参数说明如下：

• --name=grafana：给容器指定一个易记的名称，方便后续管理。
• -p 3000:3000：将主机的 3000 端口映射到容器的 3000 端口，Grafana 默认通过 3000 端口提供 Web 服务。
• -e GF_SECURITY_ADMIN_USER=admin：设置管理员用户名为 admin。
• -e GF_SECURITY_ADMIN_PASSWORD=admin123：设置管理员密码为 admin123，建议生产环境中使用更复杂的密码。
• -e GF_USERS_ALLOW_SIGN_UP=false：禁止新用户自行注册，确保系统安全。
• -v grafana-data:/var/lib/grafana：将 Grafana 的数据目录持久化到 Docker 卷中，避免容器重启后数据丢失。

容器启动后，等待约十几秒让 Grafana 完成初始化。可以通过以下命令查看容器运行状态：

docker ps | grep grafana

如果看到 grafana 容器处于 Up 状态，说明启动成功。此时打开浏览器，访问 http://<服务器IP>:3000，使用刚才设置的用户名 admin 和密码 admin123 登录。首次登录时，Grafana 会提示你修改默认密码，按照提示操作即可。

二、配置 Prometheus 数据源

登录 Grafana 后，第一件事就是告诉 Grafana 去哪里找 Prometheus 的数据。这个操作称为「添加数据源」。

点击左侧菜单栏中的「Connections」，在搜索框中输入「Prometheus」，找到 Prometheus 数据源卡片后点击进入，然后点击「Add new data source」。

在配置页面中，需要填写以下关键信息：

其中 URL 的填写需要特别注意：如果 Grafana 和 Prometheus 都运行在同一台机器上，且 Prometheus 通过 Docker 或直接部署，使用 localhost 是正确的。但如果在生产环境中 Prometheus 部署在另一台服务器上，则需要填写对应的 IP 地址或域名。例如 http://10.10.10.200:9090。

此外，如果 Prometheus 启用了身份验证（例如 --web.config.file 配置了认证），还需要在「Auth」区域开启相应的认证开关，并填入用户名和密码或 API Token。例如开启 Basic auth，填入对应的用户名和密码即可。

配置完成后，点击页面底部的「Save & test」按钮。Grafana 会自动向 Prometheus 发送一个测试请求，如果一切配置正确，会看到绿色的「Database OK」提示。这说明 Grafana 已经能够成功连接到 Prometheus 并读取数据了。

三、验证数据连接

数据源添加成功后，我们可以通过一个简单的查询来验证数据是否能够正常返回。回到 Grafana 主界面，点击左侧菜单中的「Explore」入口。

在 Explore 页面中，顶部的数据源选择框应该已经默认选中了我们刚添加的 Prometheus 数据源。在指标查询输入框中，输入一个常见的指标名称，例如 up。这是 Prometheus 自动采集的一个指标，用于标识每个被监控目标的上线状态。

输入完成后按下回车，Grafana 会执行查询并返回一条时序曲线。如果看到一条值为 1 的水平直线（表示目标在线），说明 Prometheus 已经成功采集了数据，Grafana 也能正确获取到这些数据。

如果查询没有返回任何结果，或者提示错误信息，请按以下顺序排查：

首先，确认 Prometheus 本身是否正常运行。可以在 Prometheus 服务器上直接访问 http://localhost:9090，在「Status → Targets」页面查看所有监控目标的状态是否均为 UP。其次，检查防火墙是否放行了 Prometheus 的 9090 端口和 Grafana 的 3000 端口。最后，确认 Prometheus 的 URL 配置中是否包含了正确的协议前缀（http:// 或 https://），遗漏前缀是新手常犯的错误。

四、Explore 探索数据

Explore 是 Grafana 提供的一个交互式数据探索工具，类似于 Prometheus 自带的 Web UI，但功能更为强大。它允许用户在不创建仪表盘的情况下，自由地编写 PromQL 查询、查看指标趋势，并对数据进行临时分析。

在 Explore 页面中，除了可以在查询框中直接输入 PromQL 表达式之外，Grafana 还提供了一个辅助功能：点击查询框右侧的「Metrics browser」，可以浏览 Prometheus 中所有已注册的指标名称及其描述信息。这对于不熟悉有哪些可用指标的初学者来说非常友好，能够帮助快速定位到想要查看的指标。

例如，点击「Metrics browser」后输入 node_，可以看到所有以 node_ 开头的指标，这些正是 Node Exporter 采集的系统级指标。常见的指标包括：

• node_cpu_seconds_total：CPU 使用时间累计值。
• node_memory_MemTotal_bytes：内存总量。
• node_memory_MemAvailable_bytes：可用内存大小。
• node_filesystem_avail_bytes：文件系统可用空间。
• node_network_receive_bytes_total：网络接收字节数。

选择一个指标后，Grafana 会自动将其填入查询框，我们可以进一步添加标签过滤条件。例如：

node_memory_MemAvailable_bytes{instance="localhost:9100"}

上述查询的含义是：查看 localhost:9100 这台主机当前的可用的内存字节数。通过调整时间范围和查询条件，我们可以快速了解系统的实时运行状态。

值得注意的是，Explore 页面中的查询是即时执行的，非常适合学习和调试 PromQL 表达式。当你对某个指标不确定时，可以先在 Explore 中反复尝试，找到合适的查询语句后再将其应用到正式的仪表盘面板中。这种工作方式能够大大提高仪表盘构建的效率。

本章小结

本章完成了 Grafana 的安装和与 Prometheus 的联动配置。我们通过 Docker 一键启动了 Grafana，添加了 Prometheus 作为数据源，验证了数据连接的正常性，最后使用 Explore 功能对 Prometheus 中的监控指标进行了初步探索。这些操作为后续构建专业的监控仪表盘奠定了基础。在下一章中，我们将介绍如何利用 Grafana 的仪表盘功能，快速搭建一个功能完善的主机监控面板。

第六章：Grafana 仪表盘创建实战

什么是仪表盘

在 Grafana 中，仪表盘（Dashboard） 是监控可视化的核心。它由一个或多个面板（Panel） 组成，每个面板展示一个查询结果。通过组合不同的面板，你可以在一张视图中掌握整个系统的运行状态。

创建第一个仪表盘

步骤一：新建仪表盘

在 Grafana 左侧菜单中，点击 + → Dashboard，然后点击 Add new panel。

步骤二：编写查询

在面板编辑界面，你会看到查询编辑器。Grafana 为 Prometheus 提供了两种查询模式：

• Builder 模式：可视化拖拽，适合新手
• Code 模式：直接编写 PromQL，适合进阶用户

让我们用 Code 模式输入一个简单的查询：

# 查询 CPU 使用率
1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)

点击右上角的 Apply，面板就会显示在仪表盘上。

常用图表类型

Grafana 支持多种可视化类型。选择面板后，点击右上角的可视化图标可以切换：

时序图（Time series）

最常用的类型，适合展示随时间变化的指标。例如服务器 CPU、内存、网络流量等。

配置建议：

• Line width：设为 2，更粗的线更醒目
• Fill opacity：设为 20%，让曲线下方有轻微填充
• Gradient mode：选择 Opacity，增加层次感

仪表盘（Gauge）

适合展示当前值与阈值的对比，例如磁盘使用率、内存使用率。

# 内存使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
  / node_memory_MemTotal_bytes * 100

配置建议：

• Show threshold labels：显示阈值标签
• Show threshold markers：显示阈值刻度
• Orientation：选择 Auto 或 Circular

表格（Table）

适合展示离散数据，例如服务状态、告警列表。

PromQL 实战查询

让我们通过几个实战案例学习 PromQL 在 Grafana 中的应用。

案例一：多服务器 CPU 对比

在同一张图上展示多台服务器的 CPU 使用率：

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

Grafana 会自动为每个 instance 生成一条曲线，实现对比效果。

案例二：请求量排行

使用 Stat 面板展示请求量最高的服务：

topk(5, sum by (job) (rate(http_requests_total[5m])))

案例三：HTTP 状态码分布

使用 Pie chart 展示各状态码的占比：

sum by (status) (rate(http_requests_total[5m]))

仪表盘变量

变量让仪表盘更加灵活。你可以用一个仪表盘适配多个环境。

创建变量

在仪表盘设置中，点击 Variables → Add variable：

使用变量

在查询中用 $变量名 引用：

rate(node_cpu_seconds_total{instance="$server"}[5m])

用户切换变量时，所有使用该变量的查询都会自动更新。

导入社区仪表盘

Grafana 拥有丰富的社区生态。你可以直接导入别人做好的仪表盘：

1. 访问 Grafana Dashboards
2. 搜索 Node Exporter 或 Prometheus
3. 点击目标仪表盘，复制 Dashboard ID
4. 在 Grafana 中：+ → Import → 粘贴 ID → 选择数据源 → Import

常用推荐：

• 1860（Node Exporter Full）：最完整的服务器监控仪表盘
• 3662（Prometheus 2.0 Overview）：Prometheus 自身状态概览

小结

本章我们学习了：

1. 创建仪表盘：新建 → 添加面板 → 编写查询 → 应用
2. 常用图表类型：时序图适合趋势，仪表盘适合当前值，表格适合离散数据
3. PromQL 实战：多服务器对比、topk 排行、状态码分布
4. 仪表盘变量：用变量实现一套模板适配多个环境
5. 导入社区仪表盘：快速获得专业级监控视图

下一章我们将学习 Grafana 告警规则配置，让监控系统能够主动发现问题。

📚 延伸阅读

• Grafana 面板文档
• Grafana 仪表盘文档
• Grafana 社区仪表盘

第七章：Grafana 告警规则配置

7.1 Grafana 告警概述

监控系统的核心价值在于能够在系统出现异常时及时发现问题。传统的人工巡检方式效率低下且容易遗漏，而 Grafana 告警系统则提供了自动化、实时的告警能力。Grafana 告警能够持续监控传入的指标数据或日志条目，一旦特定条件被触发，系统会立即通过配置好的通知渠道告知运维人员，从而为系统稳定运行提供第一道防线。

Grafana 告警系统采用了与 Prometheus 告警模型相似的架构设计，将告警生成器与告警通知管理器（Alertmanager）解耦。这种设计增强了系统的可扩展性和容错能力。在整个告警工作流中，Grafana 会定期评估告警规则，当条件满足时触发告警实例，并通过 Alertmanager 将通知发送到配置好的联系点。整个过程无需人工干预，完全自动化运行。

Grafana 支持两种告警规则类型：Grafana 管理的告警规则和数据源管理的告警规则。Grafana 管理的告警规则最为灵活，允许跨多个数据源创建查询，适用于大多数场景。数据源管理的告警规则则仅支持 Grafana Mimir 和 Grafana Loki，专门针对需要高可用和水平扩展的大规模监控场景。

7.2 创建告警规则

7.2.1 告警规则的核心组成

一个完整的 Grafana 告警规则由以下几个关键部分构成：

• 查询（Queries）：从支持的数据源中选择要评估的数据集，可以是 Prometheus、Loki 等多种数据源。
• 告警条件（Alert Condition）：设置阈值条件，当查询结果满足或超过该条件时触发告警。
• 评估间隔（Evaluate Every）：指定告警规则的评估频率，例如每分钟评估一次。
• 持续时间（For）：指示条件必须持续满足多长时间才会真正触发告警实例，用于抑制瞬时波动产生的误报。
• 标签与注释：用于告警分组、路由和传递告警上下文信息。

7.2.2 创建 Grafana 管理的告警规则

进入 Grafana Web 界面后，在左侧导航栏中点击「告警（Alerting）」→「告警规则（Alert rules）」，然后点击「新建告警规则（New alert rule）」开始创建。

# 以 Prometheus 数据源为例，创建 CPU 使用率告警规则
# 查询 Node Exporter 暴露的 CPU 空闲率
rate(node_cpu_seconds_total{mode="idle"}[5m])

在查询编辑器中编写 PromQL 语句，然后切换到「告警」选项卡，设置告警名称、评估间隔和触发条件。通常将 CPU 空闲率低于 20% 作为告警阈值，即 CPU 使用率超过 80%。将「持续时间（For）」设置为 5 分钟，可以有效避免因短暂的负载峰值导致的误报。

创建完成后，告警规则会出现在告警规则列表中，支持查看告警状态（正常、待定、触发中）、最近评估时间和当前值等关键信息。

7.3 配置通知渠道

告警触发后需要通过通知渠道及时送达相关人员。Grafana 支持多种通知渠道，包括邮件、钉钉、飞书、Webhook 等。

7.3.1 邮件通知

在「告警」→「通知渠道（Contact points）」中点击「添加联系点」，选择「Email」类型。配置以下参数：

# 邮件通知配置示例
类型: Email
地址: [email protected]
主题: "[Grafana Alert] {{ .Labels.alertname }}"

邮件通知支持自定义模板，可以使用 Grafana 的模板语法嵌入告警名称、标签、值等详细信息。需要确保 SMTP 服务已正确配置，否则邮件无法发送。

7.3.2 钉钉通知

钉钉是国内市场广泛使用的办公协作工具，Grafana 支持通过钉钉机器人发送告警通知。

# 钉钉通知配置
类型: DingDing
钉钉机器人 Webhook 地址: https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN

在钉钉群中添加「自定义机器人」，复制其 Webhook 地址粘贴到配置中即可。告警消息会以卡片形式推送到群聊中，支持显示告警名称、标签和当前值。

7.3.3 飞书通知

飞书（Lark）通知同样通过 Webhook 方式接入，与钉钉类似。Grafana 提供原生的飞书集成，配置十分便捷。

# 飞书通知配置
类型: Feishu
飞书机器人 Webhook 地址: https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_HOOK_ID

首先在飞书群中添加「自定义机器人」，获取 Webhook 地址后填入 Grafana 即可。飞书通知支持富文本消息格式，能够以更直观的方式呈现告警信息。

7.3.4 通知策略

除了直接发送到联系点，Grafana 还提供**通知策略（Notification Policies）**进行更灵活的告警路由。通过为不同告警规则配置标签匹配规则，可以将不同严重程度的告警路由到不同的联系点。例如，将带有 severity=critical 标签的告警同时发送到值班电话和值班群，而将 severity=warning 的告警仅发送到邮件列表。

通知策略还支持告警分组功能。当系统发生大规模故障时，可能会同时触发成百上千个告警实例，通过标签分组和时间窗口等待，可以将大量同类告警合并到一条通知中，避免告警风暴淹没关键信息。

7.4 告警状态管理

Grafana 告警具有三个核心状态，理解这些状态对于有效管理告警至关重要：

• 正常（OK）：告警条件未满足，系统运行正常。
• 待定（Pending）：告警条件已满足，但尚未达到持续时间阈值。此时告警尚未真正触发，系统在等待确认。
• 触发（Firing）：告警条件持续满足超过设定的「持续时间」后进入此状态，系统开始发送通知。

在「告警」界面中可以集中查看所有告警规则及其当前状态。Grafana 还支持静默（Silences）和静音时间（Mute Timings）功能，可以在特定时间段内暂停告警通知，例如在计划内的维护窗口期间。静默支持设置精确的时间范围和匹配条件，不会中断告警规则的评估，只是暂停通知发送。

告警恢复时，Grafana 会自动发送「告警已解决」通知，告知运维人员问题已自动恢复或已手动处理。这一机制确保告警的完整生命周期都有记录可查。

7.5 实战案例：CPU 使用率告警

7.5.1 场景描述

假设某台 Web 服务器运行 Node Exporter，需要对 CPU 使用率超过 80% 持续 5 分钟的情况发出告警，并通过飞书通知值班人员。

7.5.2 步骤一：验证指标可用性

首先在 Grafana 的 Explore 页面验证 PromQL 查询语句是否正确：

# 查询 CPU 空闲率（5分钟平均值）
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

当该查询结果小于 20 时，表示 CPU 使用率超过 80%。

7.5.3 步骤二：创建告警规则

1. 导航至「告警」→「告警规则」→「新建告警规则」。
2. 选择 Prometheus 数据源，输入上述查询语句。
3. 切换到「告警」选项卡，填写以下配置：

告警名称: Web Server High CPU
条件: avg() of query(A) IS BELOW 20
评估间隔: 1m
持续时间（For）: 5m
标签:
  severity: critical
  service: web-server

4. 选择通知策略或直接指定飞书联系点作为通知目标。

7.5.4 步骤三：配置飞书 Webhook

在飞书群中添加自定义机器人后，将获取的 Webhook 地址配置为新的联系点：

联系点名称: 飞书值班群
类型: Feishu
Webhook URL: https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_HOOK_ID

7.5.5 步骤四：测试与验证

创建告警规则后，Grafana 会立即开始评估。可以通过手动调整告警条件或在服务器上制造负载来验证告警是否正确触发。飞书群中应收到类似以下格式的告警消息：

🚨 [Grafana Alert] Web Server High CPU
告警名称: Web Server High CPU
严重程度: critical
实例: 10.10.10.200:9100
当前值: 85.3%
持续时间: 5m 23s

当 CPU 使用率恢复正常后，Grafana 会自动发送「告警已解决」通知，完成告警的完整生命周期管理。

7.6 小结

本章详细介绍了 Grafana 告警系统的配置与使用方法。Grafana 告警通过定期评估规则、将告警与通知解耦的设计，为监控系统提供了强大的自动化告警能力。在实际运维中，合理设置告警阈值、评估间隔和持续时间，是减少误报和漏报的关键。飞书、钉钉等即时通讯工具的集成，使得告警通知能够第一时间送达相关人员，显著缩短故障响应时间。建议读者结合自身业务场景，在测试环境中充分验证告警规则后再投入生产使用。

第八章：实战案例与进阶技巧

前几章我们完成了 Prometheus 和 Grafana 的基础部署与使用，本章将通过实际案例深入探讨容器监控、数据库监控、服务发现等进阶主题，帮助读者掌握生产环境中常用的监控技巧。

一、Docker 容器监控（cAdvisor）

cAdvisor 是 Google 开源的容器监控工具，能够自动采集容器级别的资源使用数据，是 Docker 监控的首选方案。

1.1 部署 cAdvisor

cAdvisor 支持 Docker 部署，启动命令如下：

version: '3.8'
services:
  cadvisor:
    image: gcr.io/google-containers/cadvisor:latest
    container_name: cadvisor
    privileged: true
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    ports:
      - "8080:8080"
    restart: unless-stopped

启动后访问 http://localhost:8080 即可查看容器监控界面。

1.2 配置 Prometheus 采集 cAdvisor

在 prometheus.yml 中添加 cAdvisor 采集任务：

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

cAdvisor 提供的主要指标包括：

二、MySQL 数据库监控

MySQL 是最常用的关系型数据库，使用 mysqld_exporter 可以轻松实现 MySQL 监控。

2.1 安装与配置 mysqld_exporter

首先需要为 exporter 创建数据库用户：

CREATE USER 'exporter'@'%' IDENTIFIED BY 'your_password';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'exporter'@'%';
GRANT SELECT ON performance_schema.* TO 'exporter'@'%';

然后启动 mysqld_exporter：

export DATA_SOURCE_NAME='exporter:your_password@(localhost:3306)/'
./mysqld_exporter --collect.info_schema.processlist

2.2 关键监控指标

mysqld_exporter 暴露的关键指标包括：

# Prometheus 配置
scrape_configs:
  - job_name: 'mysql'
    static_configs:
      - targets: ['mysql-exporter:9104']

推荐关注的指标：

• mysql_global_status_threads_connected：当前连接数
• mysql_global_status_slow_queries：慢查询数量
• mysql_global_variables_max_connections：最大连接数
• rate(mysql_global_status_commands_total{command="select"}[5m])：查询 QPS

三、Prometheus 服务发现

服务发现是 Prometheus 的核心特性之一，能够自动感知监控目标的变化，特别适合动态的容器化环境。

3.1 基于文件的服务发现

通过监控文件变化实现服务发现，适合与 Ansible、SaltStack 等配置管理工具配合使用：

scrape_configs:
  - job_name: 'file-sd'
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/*.yml
        refresh_interval: 30s

targets 目录下的目标文件格式：

- targets:
    - '192.168.1.10:9100'
  labels:
    env: production
    service: web

3.2 Docker Swarm 服务发现

在 Docker Swarm 环境中，可以使用 dns_sd_config 进行服务发现：

scrape_configs:
  - job_name: 'docker-swarm'
    dns_sd_configs:
      - names:
          - 'tasks.node-exporter'
        type: 'A'
        port: 9100
        refresh_interval: 10s

3.3 Kubernetes 服务发现

Prometheus 可以直接与 Kubernetes API 交互，自动发现集群中的服务：

scrape_configs:
  - job_name: 'kubernetes-nodes'
    kubernetes_sd_configs:
      - role: node
    relabel_configs:
      - source_labels: [__meta_kubernetes_node_name]
        regex: (.+)
        target_label: instance
        replacement: ${1}

支持的 Kubernetes 角色：

• node：集群节点
• service：集群服务
• pod：Pod 实例
• endpoints：服务端点
• ingress：入口规则

3.4 Relabel 高级用法

relabel_configs 允许在采集前修改标签，是服务发现的核心机制：

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      # 只采集带有 prometheus.io/scrape=true 注解的 Pod
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      # 从注解中提取采集路径
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
        replacement: ${1}
      # 从服务名生成应用标签
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: labelmap
        regex: (.+)

四、Recording Rules 预计算

Recording Rules 用于预先计算高频查询的结果，将复杂的 PromQL 查询结果缓存为新的时间序列，大幅提升查询性能。

4.1 配置 Recording Rules

创建规则文件 /etc/prometheus/rules/recording_rules.yml：

groups:
  - name: system_rules
    interval: 30s
    rules:
      # 节点 CPU 使用率
      - record: instance:cpu_usage:rate5m
        expr: |
          100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
      
      # 节点内存使用率
      - record: instance:memory_usage:percentage
        expr: |
          100 * (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))
      
      # 磁盘 IOPS
      - record: instance:disk_reads:rate1m
        expr: rate(node_disk_reads_completed_total[1m])
      
      - record: instance:disk_writes:rate1m
        expr: rate(node_disk_writes_completed_total[1m])
      
      # 网络流量
      - record: instance:network_receive:rate5m
        expr: rate(node_network_receive_bytes_total[5m])
      
      - record: instance:network_transmit:rate5m
        expr: rate(node_network_transmit_bytes_total[5m])

在 prometheus.yml 中加载规则文件：

rule_files:
  - "/etc/prometheus/rules/*.yml"

4.2 Recording Rules 最佳实践

使用 Recording Rules 时应注意：

1. 命名规范：采用 level:metric:aggregation 格式命名，便于理解和查询
2. 合理间隔：根据数据变化频率选择评估间隔，避免资源浪费
3. 逐层聚合：按需创建不同聚合级别的规则，从低到高逐步汇总
4. 标签保留：使用 keep_common() 函数保留关键标签

五、常用 Exporter 推荐

Prometheus 生态系统提供了丰富的 Exporter，覆盖各类基础设施和应用：

5.1 blackbox_exporter 的使用

blackbox_exporter 支持 HTTP、HTTPS、DNS、TCP、ICMP 等多种协议的探测：

scrape_configs:
  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com
          - https://api.example.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

5.2 快速部署建议

生产环境中建议使用 Docker Compose 或 Kubernetes 部署 Exporter。node-exporter 需要挂载主机的 /proc 和 /sys 目录，并排除不需要的文件系统：

services:
  node-exporter:
    image: prom/node-exporter:v1.7.0
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
    ports:
      - "9100:9100"
    restart: unless-stopped

⚠️ 注意：不要挂载 /:/rootfs:ro，这会导致指标数据混乱。只需挂载 /proc 和 /sys 即可。

六、总结

本章介绍了 Prometheus 监控体系中的几个重要进阶主题：cAdvisor 实现了细粒度的容器监控，mysqld_exporter 让数据库监控变得简单，服务发现机制使监控系统具备自动感知能力，Recording Rules 优化了复杂查询的性能。通过合理运用这些技术，可以构建起一套完整的生产级监控平台。

下一章我们将探讨告警规则的配置与 AlertManager 的使用，实现从监控到告警的完整闭环。