配置文件的作用
prometheus.yml 是 Prometheus 的主配置：global 段定义全局默认值，scrape_configs 定义抓取任务，rule_files 声明记录与告警规则文件，alerting 段指向上游 Alertmanager。它支持运行期热加载，改完不必重启进程；但数据保留期这类参数仍走命令行，热加载对它们无效。
基本信息
| 默认路径 | /etc/prometheus/prometheus.yml |
|---|---|
| 指定方式 | 启动参数 --config.file |
| 校验工具 | promtool check config prometheus.yml |
| 热加载 | 启动时加 --web.enable-lifecycle，再 POST /-/reload |
| 版本差异 | 2.x 与 3.x 的配置大体兼容，升级前仍应查看迁移说明 |
典型使用场景
- 新增采集任务：为新系统加一个 job，声明目标发现方式与抓取间隔
- 接入告警：配置 alerting 段并挂上 rules 目录，让规则评估结果可送达
- 多集群区分：用 external_labels 给样本打上集群标识，便于汇总查询
- 远程写归档：把样本同时写入长期存储，本地只保留热数据
- 灰度验证：先在小环境跑 promtool 校验与 reload，再同步到生产
基础可用的配置骨架
基础可用的配置骨架
global:
scrape_interval: 15s # 默认抓取间隔
evaluation_interval: 15s # 规则评估间隔
external_labels: # 写入样本的全局标识
cluster: prod
replica: a
rule_files:
- rules/*.yml
alerting:
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:9093']
scrape_configs:
- job_name: node
static_configs:
- targets: ['10.0.1.11:9100']远程写与热加载
远程写与热加载
# remote_write：把样本同时写入长期存储
# remote_write:
# - url: http://mimir:9009/api/v1/push
# 改完配置先校验语法，再触发热加载
promtool check config /etc/prometheus/prometheus.yml
curl -X POST http://127.0.0.1:9090/-/reload常用段落一览
| 段落 | 作用 | 关键键 |
|---|---|---|
| global | 全局默认与外部标签 | scrape_interval、evaluation_interval、external_labels |
| scrape_configs | 抓取任务定义 | job_name、static_configs、relabel_configs |
| rule_files | 规则文件路径列表 | 支持通配符路径 |
| alerting | Alertmanager 地址 | alertmanagers、static_configs |
| remote_write | 样本远程写入 | url、queue_config |
热加载需要启动时开启 --web.enable-lifecycle；未开启时改配置不会生效，必须重启进程，重启期间告警评估会中断。
规则文件改动同样通过热加载生效。多个规则文件时，建议在测试环境用 promtool check rules 逐个校验再同步到生产。
组织大型配置的方式
配置膨胀后常见做法是拆分与生成：把每个系统或团队的抓取任务拆成独立片段，用配置管理或模板工具在部署前渲染成一份主配置。拆分后仍要保证 job 名与标签口径统一，否则同一个服务会以多套命名出现在看板里。
从静态配置到服务发现
static_configs 适合主机数量固定的场景；节点频繁上下线时应改用服务发现：Kubernetes 环境按角色与命名空间筛选目标，云环境使用厂商发现机制，再配合 relabel 只保留真正需要采集的实例。服务发现也意味着目标集合由集群状态决定，改动前先确认筛选条件。
改动的生效方式
- 抓取段落：热加载生效，改完 reload 一次即可
- 规则文件内容：先 promtool check rules 校验，再热加载生效
- Alertmanager 地址：热加载生效，改完确认连接可用
- 远程写地址：热加载生效，但要注意队列积压情况
- external_labels：热加载生效，已写入的历史样本不受影响
- 数据保留期与存储路径：命令行参数，必须重启进程
改配置的标准动作
| 步骤 | 命令 | 目的 |
|---|---|---|
| 改前备份 | cp prometheus.yml prometheus.yml.bak | 回滚有据可依 |
| 语法校验 | promtool check config prometheus.yml | 避免带着错误配置重载 |
| 规则校验 | promtool check rules rules/*.yml | 提前发现表达式问题 |
| 触发热加载 | curl -X POST http://127.0.0.1:9090/-/reload | 不中断抓取地生效 |
主配置没有包含指令，多份片段必须由配置生成工具在部署前渲染成一份文件；手工拼接容易在合并时产生重复的 job_name。
版本升级注意
两个大版本之间的配置大体兼容，但被移除或改名的键会让服务直接启动失败。稳妥流程是先用新版本二进制执行 promtool check config 校验现有配置，再在测试环境跑一轮抓取与规则评估，确认监控链路完整后再升级生产。
配置要进版本库并走评审：抓取规则的改动会直接影响告警覆盖面，单人直接改生产是监控失效的常见起点。