4. 配置文件详解:global、alerting、rule_files、scrape_configs 四大核心配置块解析
Prometheus 的配置体系以 YAML 格式为核心,所有行为由单一配置文件(通常为 prometheus.yml)驱动。理解 global、alerting、rule_files、scrape_configs 这四大配置块,是掌握 Prometheus 控制面配置与调优的基础。本章将逐一解析每个配置块的结构、关键参数及最佳实践。
配置加载机制: Prometheus 支持通过
SIGHUP 信号或 HTTP API /-/reload 热加载配置,无需重启进程。但需注意,配置语法错误会导致加载失败,建议使用 promtool check config 命令预先验证。
4.1 global 配置块:全局行为基准
global 块定义所有 Job 的默认行为,是配置文件的顶层入口。其参数可被单个 Job 的 scrape_config 覆盖。
| 参数名 | 默认值 | 说明 | 调优建议 |
|---|---|---|---|
scrape_interval |
1m | 全局抓取间隔 | 控制面环境建议 15s–30s;高精度场景可降至 5s |
scrape_timeout |
10s | 单次抓取超时时间 | 必须小于 scrape_interval,建议设为间隔的 80% |
evaluation_interval |
1m | 规则评估周期(告警/记录规则) | 与 scrape_interval 保持一致或为其整数倍 |
external_labels |
空 | 全局附加标签,用于联邦集群或远程存储 | 必须包含 cluster、env 等标识,避免标签冲突 |
# global 配置示例
global:
scrape_interval: 15s # 每 15 秒抓取一次
scrape_timeout: 10s # 抓取超时 10 秒
evaluation_interval: 15s # 每 15 秒评估一次规则
external_labels:
cluster: 'production'
env: 'control-plane'
陷阱:
scrape_timeout 若大于 scrape_interval,会导致抓取队列堆积,引发数据空洞。务必保证 scrape_timeout < scrape_interval。
4.2 alerting 配置块:告警路由中枢
alerting 块定义 Prometheus 与 Alertmanager 的通信方式。它不定义告警规则,只定义告警通知的发送目标。
# alerting 配置示例
alerting:
alertmanagers:
- static_configs:
- targets:
- 'alertmanager-01:9093'
- 'alertmanager-02:9093'
scheme: http
timeout: 10s
api_version: v2
| 子参数 | 说明 | 控制面环境建议 |
|---|---|---|
static_configs |
静态指定 Alertmanager 实例地址 | 生产环境至少 2 个实例做高可用 |
scheme |
HTTP 或 HTTPS | 控制面内网建议 HTTP,跨网络必须 HTTPS |
timeout |
发送告警的超时时间 | 默认 10s,网络抖动场景可增至 30s |
api_version |
Alertmanager API 版本(v1 或 v2) | 推荐 v2,支持更丰富的告警元数据 |
高可用设计: 配置多个 Alertmanager 地址时,Prometheus 会并行发送告警到所有实例。Alertmanager 集群内部通过 Gossip 协议去重,避免重复通知。
4.3 rule_files 配置块:规则动态加载
rule_files 块指定 Prometheus 加载的告警规则和记录规则文件路径。支持 Glob 模式匹配,便于按目录组织规则。
# rule_files 配置示例
rule_files:
- "rules/node_exporter_alerts.yml"
- "rules/kubernetes_alerts/*.yml"
- "rules/recording_rules.yml"
| 规则类型 | 文件示例 | 用途 | 评估频率 |
|---|---|---|---|
| 告警规则 (Alerting Rules) | node_exporter_alerts.yml |
定义触发告警的条件表达式 | 由 evaluation_interval 控制 |
| 记录规则 (Recording Rules) | recording_rules.yml |
预计算复杂查询,提升仪表盘响应速度 | 由 evaluation_interval 控制 |
最佳实践: 将告警规则与记录规则分离到不同文件,按业务模块(如
kubernetes/、database/、network/)组织子目录,便于权限管理和版本控制。
4.4 scrape_configs 配置块:抓取任务核心
scrape_configs 是配置文件中结构最复杂、参数最多的块。每个 job_name 定义一个抓取任务,包含目标发现、标签管理、抓取参数等。
# scrape_configs 配置示例
scrape_configs:
- job_name: 'node-exporter'
scrape_interval: 30s
static_configs:
- targets:
- 'node-01:9100'
- 'node-02:9100'
labels:
group: 'compute'
relabel_configs:
- source_labels: [__address__]
regex: '(.*):.*'
replacement: '${1}'
target_label: 'instance_ip'
| 子配置块 | 功能 | 控制面环境关键参数 |
|---|---|---|
static_configs |
静态目标列表 | 适用于基础设施组件(Node Exporter、kube-state-metrics) |
kubernetes_sd_configs |
基于 Kubernetes API 动态发现 | 必须配置 role: pod/service/endpoints |
relabel_configs |
标签重写、过滤、保留 | 用于标准化标签、丢弃不需要的指标 |
metric_relabel_configs |
指标级别标签操作 | 用于丢弃高基数标签或重命名指标 |
params |
自定义 HTTP 查询参数 | 用于传递 collect[] 参数控制采集器 |
性能陷阱: 每个
scrape_config 的 relabel_configs 和 metric_relabel_configs 会在每次抓取时执行。过多的重写规则(超过 50 条)会显著增加 CPU 开销,建议控制在 20 条以内。
4.5 四大配置块协同工作流
下图展示了 Prometheus 启动后,四大配置块如何协同完成从配置加载到数据存储、告警触发的完整流程。
4.6 配置调优实战:控制面环境推荐参数
针对控制面环境(Kubernetes 控制平面组件、etcd、API Server 等),以下是一组经过验证的推荐配置参数:
| 配置块 | 参数 | 推荐值 | 理由 |
|---|---|---|---|
| global | scrape_interval |
15s | 控制面指标变化快,15s 可平衡精度与开销 |
| global | evaluation_interval |
15s | 与抓取间隔一致,避免规则评估滞后 |
| alerting | timeout |
10s | 内网通信延迟低,10s 足够 |
| scrape_configs | scrape_timeout |
12s | 小于 15s 间隔,留有余量 |
| scrape_configs | relabel_configs |
≤ 15 条 | 避免 CPU 开销过高 |
| rule_files | 文件数量 | ≤ 50 个 | 过多文件增加启动加载时间 |
配置验证命令:
# 使用 promtool 验证配置文件语法
promtool check config prometheus.yml
# 检查规则文件语法
promtool check rules rules/node_exporter_alerts.yml
4.7 常见配置错误与排查
- 缩进错误: YAML 对缩进敏感,使用空格而非 Tab,建议统一为 2 空格缩进。
- targets 格式错误:
targets必须为列表格式,即使只有一个目标也要加-前缀。 - 标签冲突:
relabel_configs中若target_label与已有标签重名,会覆盖原值,可能导致数据混乱。 - 规则文件路径错误:
rule_files使用相对路径时,基准目录为 Prometheus 进程的工作目录,建议使用路径。 - Alertmanager 不可达: 若
alerting块配置的 Alertmanager 地址不可达,Prometheus 仍会正常抓取,但告警无法发送,需检查网络连通性。
快速排查命令: 使用
curl http://localhost:9090/api/v1/status/config 查看当前加载的配置;使用 curl http://localhost:9090/api/v1/alertmanagers 检查 Alertmanager 连接状态。