修改 Prometheus 主配置文件 prometheus.yml，在 global 字段下调整 scrape_interval 数值，完成后重载配置即可生效。
先说结论：该参数控制抓取监控数据的频率，默认值为 1 分钟，生产环境常调整为 15 秒以平衡精度与负载。
- 适合需要调整监控数据粒度的场景
- 修改前务必备份原配置文件
- 变更后验收 Targets 页面状态
配置示例
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_timeout: 10s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']重载配置方法
修改保存后，需重载配置使变更生效，以下三种方式任选其一：
1. Systemd 管理（推荐生产环境）
systemctl reload prometheus2. 发送信号重载
首先获取 Prometheus 进程 ID：
pgrep -f prometheus
# 或
ps -ef | grep prometheus获取 PID 后发送信号：
kill -HUP <prometheus_pid>3. HTTP API 重载
注意：默认情况下该接口不可用，启动 Prometheus 时必须添加 `--web`.enable-lifecycle 参数。
curl -X POST http://localhost:9090/-/reload启用 Lifecycle API 配置
若需使用 HTTP API 重载，需检查启动参数。若使用 systemd 管理，编辑服务文件：
sudo systemctl edit prometheus在配置中添加参数：
[Service]
ExecStart=
ExecStart=/usr/bin/prometheus `--web`.enable-lifecycle ...修改后需重启服务生效：systemctl restart prometheus。
验证是否生效
- 查看 Web 界面：访问 Status -> Targets 页面，观察各 Job 的 Interval 列是否变为新设置的值。
- 检查内部指标：查询
prometheus_config_last_reload_successful指标，值为 1 表示最近一次重载成功。 - 观察数据密度：在 Graph 页面查询
up指标，调整时间范围后观察数据点密度是否随间隔变化而改变。
常见坑与风险
- 超时时间冲突：
scrape_timeout必须小于scrape_interval。若间隔设置得比超时还短，会导致抓取任务排队或失败。 - 局部覆盖全局：
scrape_configs下的具体 job 可以单独设置 scrape_interval，这会覆盖 global 设置，排查时需优先检查 job 级配置。 - 重载失败回滚：如果重载后服务异常，需立即还原备份的配置文件并再次重载，避免监控数据长时间中断。
- API 权限限制：未添加
`--web`.enable-lifecycle参数时，调用 reload 接口会返回 403 或无响应。
参考来源
- Prometheus 官方配置文件说明
- Prometheus 生命周期管理文档