静态配置不支持热更新，但可通过 file_sd_configs 实现类静态管理+真动态生效：将 targets 移至外部 JSON 文件，由 Prometheus 轮询加载；修改 prometheus.yml 使用 file_sd_configs 替代 static_configs，创建目标文件并触发 reload 即可。
静态配置本身不支持热更新，但可以和 file_sd_configs 配合使用，实现“类静态”的管理习惯 + “真动态”的生效能力——关键在于把目标地址从 static_configs 中完全剥离，交由外部文件托管，并让 Prometheus 主动轮询这些文件。
核心思路：用 file_sd 替代 static_configs，保留结构清晰性
不要在 scrape_configs 里写 static_configs，而是统一改用 file_sd_configs。这样既延续了手动维护目标列表的可控感，又获得自动重载能力。
- 原静态写法（需 reload 或重启）：
static_configs: - targets: ["192.168.1.10:9100", "192.168.1.11:9100"] - 推荐替代写法（热更新）：
file_sd_configs: - files: ["/etc/prometheus/targets/nodes.json"]
配置步骤：三步完成平滑切换
只需修改 Prometheus 主配置一次，后续所有 Target 增删都无需触碰主配置文件。
-
1. 修改 prometheus.yml：注释或删除原有
static_configs，新增一个 job 使用file_sd_configs
示例：- job_name: "linux-servers"<br> file_sd_configs:<br> - files: ["/etc/prometheus/targets/nodes.json"]<br> refresh_interval: 30s
-
2. 创建目标定义文件（如
/etc/prometheus/targets/nodes.json）：[<br> { "targets": ["192.168.1.10:9100"], "labels": {"env": "prod", "role": "db"} },<br> { "targets": ["192.168.1.11:9100"], "labels": {"env": "prod", "role": "app"} }<br>]
注意：每个对象是一个独立 target 组，可带不同 labels -
3. 触发首次重载：执行
curl -X POST http://localhost:9090/-/reload（确保启动时加了--web.enable-admin-api）
或发送 SIGHUP 信号：kill -SIGHUP $(pidof prometheus)
热变更操作：增删改目标全在文件里完成
只要文件内容变化，Prometheus 在 refresh_interval（如 30s）内自动识别并更新 Targets 列表，全程无中断、不丢数据。
-
添加新节点：向 JSON 数组追加一个对象，例如：
{ "targets": ["192.168.1.12:9100"], "labels": {"env": "staging", "role": "cache"} } - 下线旧节点：直接从数组中删除对应对象（或注释掉——但 JSON 不支持注释，建议用脚本生成）
- 批量更新：可用 Ansible、Shell 脚本或 CI/CD 流水线自动生成目标文件，实现与基础设施变更联动
验证与排错要点
变更后快速确认是否生效，避免“以为更新了其实没加载”。
- 访问
http://<prometheus-ip>:9090/targets</prometheus-ip>，筛选对应job_name，检查状态是否为 UP - 查看 Targets 页面右上角的 Last Scrape 时间，确认是否在最近 refresh_interval 内刷新过
- 若未生效，检查：
– 文件路径权限是否允许 Prometheus 进程读取
– JSON 格式是否合法（可用jq . nodes.json验证）
– Prometheus 日志中是否有file_sd: error loading file类报错
