当然可以优化！Prometheus本身的原生配置语法不支持你示例里的模板变量（比如{{host_targets}}），但有几种官方推荐的方法来实现你想要的「复用主机列表+每个作业指定端口」的需求，下面是具体方案：

方案1：使用文件服务发现（file_sd_configs） #

这是最灵活且官方推荐的方式，核心思路是把主机列表单独存成一个文件，每个采集作业通过服务发现加载这个列表，再通过标签重写来拼接端口。

步骤1：创建主机列表文件 #

比如创建/etc/prometheus/hosts.json，内容如下：

[
  {
    "targets": ["host1", "host2", "host3", ..., "host50"],
    "labels": {
      "group": "production_hosts"
    }
  }
]

步骤2：修改Prometheus配置文件 #

每个作业通过file_sd_configs加载主机列表，再用relabel_configs把端口拼接到目标地址上：

scrape_configs:
  - job_name: "job1"
    file_sd_configs:
      - files: ["/etc/prometheus/hosts.json"]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __address__
        replacement: "${1}:9100"  # 拼接9100端口

  - job_name: "job2"
    file_sd_configs:
      - files: ["/etc/prometheus/hosts.json"]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __address__
        replacement: "${1}:9101"  # 拼接9101端口

  - job_name: "job3"
    file_sd_configs:
      - files: ["/etc/prometheus/hosts.json"]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __address__
        replacement: "${1}:9102"  # 拼接9102端口

这种方式的好处是：主机列表变更时只需要修改hosts.json，不需要改动Prometheus主配置；还可以给主机添加自定义标签，方便后续查询过滤。

方案2：用配置管理工具生成Prometheus配置 #

如果你的基础设施用Ansible、Chef这类配置管理工具维护，可以直接在配置模板里定义主机组变量，自动生成最终的prometheus.yml。

比如用Ansible的Jinja2模板示例：

# prometheus.yml.j2
scrape_configs:
{% set host_targets = ["host1", "host2", ..., "host50"] %}
{% for job in [{"name": "job1", "port": 9100}, {"name": "job2", "port": 9101}, {"name": "job3", "port": 9102}] %}
  - job_name: "{{ job.name }}"
    static_configs:
      - targets: {% for host in host_targets %}"{{ host }}:{{ job.port }}"{% if not loop.last %}, {% endif %}{% endfor %}
{% endfor %}

Ansible会在部署时渲染这个模板，生成包含所有目标的完整配置文件。

方案3：YAML锚点与别名（有限复用） #

YAML本身支持锚点（&）和别名（*）来复用配置片段，但这种方式只能复用静态配置，没办法动态拼接端口，适合重复内容更多的场景，比如：

scrape_configs:
  - &base_job
    static_configs:
      - targets: ["host1", "host2", ..., "host50"]

  - job_name: "job1"
    <<: *base_job
    relabel_configs:
      - source_labels: [__address__]
        target_label: __address__
        replacement: "${1}:9100"

  - job_name: "job2"
    <<: *base_job
    relabel_configs:
      - source_labels: [__address__]
        target_label: __address__
        replacement: "${1}:9101"

本质和方案1的relabel逻辑一样，只是用YAML特性减少了static_configs的重复书写。

总结一下：如果要长期维护且灵活度高，优先选方案1（文件服务发现）；如果已经在用配置管理工具，方案2也很方便；方案3适合临时简化配置。

内容的提问来源于stack exchange，提问作者Cleared