📚 课程目录第3章 Prometheus基础配置

3. Prometheus 基础配置：global、scrape_configs、rule_files、alerting 配置详解

Prometheus 的配置体系是其灵活性与可扩展性的核心。一个标准的 prometheus.yml 配置文件由四个顶级配置块组成：global（全局设置）、scrape_configs（采集配置）、rule_files（规则文件）和 alerting（告警配置）。本章将逐一拆解每个配置块的作用、关键参数及最佳实践。

3.1 global 配置块：全局默认行为

global 块定义了 Prometheus 实例的全局默认参数，这些参数会被 scrape_configs 和 alerting 中的配置继承，除非在子配置中显式覆盖。

参数名	默认值	说明
`scrape_interval`	1m	采集目标数据的默认时间间隔。生产环境通常设为 15s 或 30s。
`scrape_timeout`	10s	单次采集请求的超时时间。必须小于 `scrape_interval`。
`evaluation_interval`	1m	Prometheus 评估告警规则和记录规则的频率。
`external_labels`	空	全局标签，在发送告警或远程写入时附加到所有时间序列上。常用于标识集群或环境。

  关键实践： 在大型集群中，建议将 scrape_interval 设置为 15s，scrape_timeout 设置为 10s，以避免因采集超时导致的数据缺失。同时，务必设置 external_labels（如 cluster: prod-us-east），以便在全局视图或告警路由中区分数据来源。

3.2 scrape_configs 配置块：定义采集目标

scrape_configs 是 Prometheus 配置中最核心、最复杂的部分。它定义了 Prometheus 如何发现、连接和采集目标（Target）的指标数据。每个采集任务（Job）可以包含多个目标组（Target Group）。

3.2.1 核心参数

参数名	必填	说明
`job_name`	是	任务名称，作为标签 `job` 的值附加到所有采集的指标上。
`static_configs`	否	静态目标列表，直接指定 `targets`（地址列表）和 `labels`。
`relabel_configs`	否	在采集前对目标标签进行重写、过滤或修改的规则。
`metric_relabel_configs`	否	在采集后对指标标签进行重写或丢弃的规则。
`scheme`	否	采集协议，默认为 `http`，可设为 `https`。
`params`	否	采集请求的 URL 查询参数，例如 `params: {'module': ['http_2xx']}`。

3.2.2 静态配置示例

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.1.10:9100', '192.168.1.11:9100']
        labels:
          env: 'production'
          team: 'infra'
      - targets: ['192.168.1.20:9100']
        labels:
          env: 'staging'
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

提示： 使用 static_configs 适合目标数量较少且 IP 固定的场景。对于动态环境（如 Kubernetes、Consul），应使用对应的服务发现机制（如 kubernetes_sd_configs、consul_sd_configs），这些将在后续章节详细讲解。

3.3 rule_files 配置块：加载规则文件

rule_files 用于指定 Prometheus 加载的规则文件路径。规则文件包含两种类型：记录规则（Recording Rules） 和 告警规则（Alerting Rules）。

记录规则： 预先计算复杂或频繁使用的 PromQL 表达式，将结果存储为新的时间序列，提升查询性能。
告警规则： 定义告警条件，当 PromQL 表达式计算结果为真时，触发告警并发送至 Alertmanager。

rule_files:
  - "rules/node_alerts.yml"
  - "rules/service_records.yml"
  - "rules/*.yml"

注意： 规则文件路径支持通配符（如 rules/*.yml），但需确保文件格式正确。Prometheus 在启动或重新加载配置时会校验所有规则文件，若存在语法错误，将拒绝加载整个配置。建议在 CI/CD 流程中使用 promtool check rules 命令进行预校验。

3.4 alerting 配置块：对接 Alertmanager

alerting 块配置 Prometheus 如何与 Alertmanager 实例通信。它主要包含 alertmanagers 列表，每个 Alertmanager 实例可以配置独立的连接参数。

参数名	默认值	说明
`static_configs`	无	静态指定 Alertmanager 的地址列表。
`scheme`	http	连接 Alertmanager 的协议。
`path_prefix`	/	Alertmanager API 的路径前缀。
`timeout`	10s	发送告警的超时时间。
`relabel_configs`	无	在发送告警前对 Alertmanager 目标进行标签重写。

3.4.1 配置示例

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager1:9093', 'alertmanager2:9093']
      scheme: http
      timeout: 15s
      path_prefix: /alertmanager

  高可用建议： 生产环境至少配置 2 个 Alertmanager 实例以实现高可用。Prometheus 会将告警同时发送给所有配置的 Alertmanager，由 Alertmanager 自身通过 Gossip 协议进行去重和分组。

3.5 配置加载与校验

Prometheus 支持两种方式加载配置：

启动时加载： 通过 --config.file 参数指定配置文件路径。
运行时重载： 向 Prometheus 进程发送 SIGHUP 信号，或通过 API 端点 POST /-/reload 触发重载（需启用 --web.enable-lifecycle）。

使用 promtool 工具进行配置校验：

# 校验配置文件语法
promtool check config prometheus.yml

# 校验规则文件
promtool check rules rules/node_alerts.yml

3.6 配置结构总览

下图展示了 Prometheus 配置文件中四个核心配置块之间的数据流与依赖关系：

3.7 完整配置示例

以下是一个生产环境可用的最小化完整配置，整合了上述所有配置块：

# prometheus.yml
global:
  scrape_interval: 15s
  scrape_timeout: 10s
  evaluation_interval: 15s
  external_labels:
    cluster: 'prod-us-east'
    environment: 'production'

rule_files:
  - "rules/node_alerts.yml"
  - "rules/service_records.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager01:9093', 'alertmanager02:9093']
      scheme: http
      timeout: 15s

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

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['10.0.1.10:9100', '10.0.1.11:9100']
        labels:
          env: 'production'
      - targets: ['10.0.2.10:9100']
        labels:
          env: 'staging'

最佳实践： 将 scrape_configs 中的每个 Job 配置独立成单独的文件，通过 --config.file 的 scrape_config_files 指令（Prometheus 2.33+）或使用配置管理工具（如 Ansible、Helm）进行模板化，避免单个配置文件过于庞大。