📈 第02章 · prometheus.yml 配置

scrape_configs/job/labels

prometheus.yml 配置¶

上一章认识了 Prometheus,这一章进入它的"大脑"——配置文件 prometheus.yml。所有"抓谁、拉多久、打什么标签、去哪告警"都在这里声明。配置写得对不对,直接影响数据是否齐全。我们先讲概念,再逐段拆解你服务器上正在生效的那份真实配置。

文件在哪、怎么校验¶

Debian 包安装的 Prometheus,配置默认在:

ls -l /etc/prometheus/prometheus.yml

普罗米修斯的配置语法是 YAML,缩进用空格、容器配置不能乱,写错一个缩进就整体失效。改完必须先校验再热加载:

promtool check config /etc/prometheus/prometheus.yml
# SUCCESS: 0 rules found   ← 校验通过

安全/易错 校验是"最后一关防线"。很多线上故障都是"改了配置直接 restart,结果服务起不来"——正确姿势永远是:先 promtool check config,再 systemctl reload prometheus(热加载,不中断)或 restart。绝不跳过校验。

global:全局默认值¶

global 设置所有 job 的默认抓取与规则评估节奏:

global:
  scrape_interval:     15s   # 抓取间隔:每 15 秒去目标拉一次
  evaluation_interval: 15s   # 规则评估间隔:每 15 秒算一次告警规则
  external_labels:
    monitor: 'example'

键	含义	本机默认
`scrape_interval`	目标默认抓取频率	15s
`evaluation_interval`	告警规则多久评估一次	15s
`external_labels`	导出到外部系统的固定标签	`monitor='example'`

external_labels 不写进本地时序,而是在向 Alertmanager / 远程存储 / 联邦等外部系统转发时贴上,方便区分环境。这里 monitor: 'example' 是一张"环境标签"。

scrape_configs:告诉它抓谁¶

这是最重要的一段,配置每个 job 的抓取目标:

scrape_configs:
  - job_name: 'prometheus'          # job 名会作为标签 job="prometheus"
    scrape_interval: 5s             # 覆盖全局,仅这个 job 每 5s 抓一次
    scrape_timeout: 5s              # 该 job 的超时
    static_configs:
      - targets: ['localhost:9090'] # 抓 Prometheus 自己的 /metrics

  - job_name: node                  # 抓 node-exporter 的 /metrics
    static_configs:
      - targets: ['localhost:9100']

元素	作用
`job_name`	给这批目标起名,成为 `job` 标签
`scrape_interval`	该 job 抓取频率,覆盖全局
`scrape_timeout`	单次抓取超时,默认 10s,需 < scrape_interval
`static_configs`	静态列目标(适合固定 IP/主机)
`targets`	目标地址列表,可填多个

提示在本机配置里,prometheus job 特意把间隔改成 5s、超时 5s,比全局 15s 更勤——这是为了"自身监控"能更快发现 Prometheus 自己是否异常。job 粒度覆盖全局,是经常被忽视的灵活点。

抓取 prometheus 自身可以用 5s,因为目标就是同一个进程、响应快;但如果目标很远、抓取很慢,却把 scrape_timeout 设得比 scrape_interval 还大,就会堆积请求、越抓越乱。

标签:标注与重打标¶

每个被抓到的指标自动带 job 和 instance 标签。你还可以在 static_configs 里用 labels 加自定义标签:

static_configs:
  - targets: ['localhost:9100']
    labels:
      environment: 'production'

重打标(relabeling)则可以在抓取前后改写/过滤标签,例如给指标加服务名,或者丢弃某些不需要的指标。它用 relabel_configs 声明,属于进阶功能,这一章先用静态不碰。

alerting:声明告警的"去送信"地址¶

alerting:
  alertmanagers:
  - static_configs:
    - targets: ['localhost:9093']

这里写的是"我要把告警发给谁"。localhost:9093 是 Alertmanager 的默认端口。注意的是:配置写好了,不代表告警服务就真的在跑——9093 目前没有监听,说明该服务器上还没安装启动 Alertmanager(告警规则与 Alertmanager 详见第 5 章)。

rule_files:挂载告警规则文件¶

rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

这里列出要加载的规则文件。注意目前两行都是注释状态——所以即使你写了告警规则文件,Prometheus 也不会评估它们,直到取消注释并且路径正确。这是下一章要动的地方。

易错规则文件路径是相对于 Prometheus --config.file 所在工作目录的 相对路径。写绝对路径最不容易错。改配置但忘了取消注释 rule_files,是最常见的"为什么告警不触发"的原因。

完整配置的写法节奏¶

一个从零开始的完整 prometheus.yml,推荐顺序是:

global:抓取/评估间隔、外部标签;
alerting:Alertmanager 地址;
rule_files:规则文件列表;
scrape_configs:每个 job 的目标与覆盖参数。

# 改完三件套:校验 → 重载 → 看目标 up
promtool check config /etc/prometheus/prometheus.yml && \
systemctl reload prometheus
curl -s localhost:9090/api/v1/targets | python3 -m json.tool | grep -E '"job"|"health"'

真实抓取状态验证(本机两个 job 都为 up):

{"job":"node","health":"up","lastError":""}
{"job":"prometheus","health":"up","lastError":""}

易错点¶

YAML 缩进必须全空格、别混 Tab:一个 Tab 就会整个 config 解析失败。
scrape_timeout 不能大于 scrape_interval:否则抓取还没结束又开新一轮,请求堆积。
targets 用 localhost 时进程通常绑定 127.0.0.1:若目标监听的不是本机回环,或监听不同网卡,就要写正确 IP,否则抓不到。
改完必须 promtool check config + reload:跳过校验直接 restart,配置错误会直接让服务退出,监控全断。
rule_files 路径写相对路径:写绝对路径更稳,且别忘取消注释。