4. 作业与实例管理

在 Prometheus 采集作业平台中，作业（Job） 定义了抓取目标（Target）的逻辑分组与采集参数，而 实例（Instance） 则是每个具体的抓取端点。本章深入剖析作业定义、实例分组机制，以及三种核心的服务发现方式：静态配置（static_configs）、文件发现（file_sd_configs）、Consul 发现（consul_sd_configs）和 Kubernetes 发现（kubernetes_sd_configs）。

4.1 作业与实例的核心概念

每个 scrape_config 定义一个作业。Prometheus 通过 job_name 唯一标识一个采集任务，并将抓取到的所有指标自动附加 job 和 instance 标签。

4.2 静态配置与实例分组

静态配置是最直接的服务发现方式，适用于基础设施稳定、目标数量少且不频繁变动的场景。通过 static_configs 直接列出目标地址，并利用 labels 实现实例分组。

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets:
          - '10.0.0.1:9100'
          - '10.0.0.2:9100'
        labels:
          group: 'web'
          region: 'us-east-1'
      - targets:
          - '10.0.1.1:9100'
          - '10.0.1.2:9100'
        labels:
          group: 'db'
          region: 'us-east-1'

上述配置将 4 个实例分为两个逻辑组：web 和 db。Prometheus 在抓取时会自动将 group 和 region 标签附加到所有时间序列上，便于后续的查询聚合与告警路由。

4.3 文件服务发现（file_sd_configs）

file_sd_configs 允许 Prometheus 从本地或共享文件系统中读取目标列表。文件格式支持 JSON 和 YAML，Prometheus 会定期（默认 5 分钟）重新读取文件，无需重启进程。

scrape_configs:
  - job_name: 'custom_targets'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/*.json'
        refresh_interval: 30s

目标文件示例（/etc/prometheus/targets/web.json）：

[
  {
    "targets": ["10.0.0.1:9100", "10.0.0.2:9100"],
    "labels": {
      "service": "web-frontend",
      "env": "production"
    }
  },
  {
    "targets": ["10.0.1.1:9100"],
    "labels": {
      "service": "web-backend",
      "env": "production"
    }
  }
]

4.4 Consul 服务发现（consul_sd_configs）

Consul 是 HashiCorp 推出的服务注册与发现工具。consul_sd_configs 允许 Prometheus 直接从 Consul 集群获取健康服务列表，并利用 Consul 的标签和元数据实现动态分组。

scrape_configs:
  - job_name: 'consul_services'
    consul_sd_configs:
      - server: 'localhost:8500'
        datacenter: 'dc1'
        services:
          - 'web'
          - 'api'
    relabel_configs:
      - source_labels: ['__meta_consul_service']
        target_label: 'service'
      - source_labels: ['__meta_consul_dc']
        target_label: 'datacenter'

Consul 发现的核心元数据标签：

4.5 Kubernetes 服务发现（kubernetes_sd_configs）

Kubernetes 服务发现是云原生场景下的首选方案。Prometheus 通过 Kubernetes API 动态发现 Pod、Service、Endpoint、Node 和 Ingress 等资源，并自动关联丰富的元数据标签。

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace
      - source_labels: [__meta_kubernetes_pod_container_port_number]
        target_label: port

Kubernetes 发现支持 5 种角色（role），每种角色提供不同的元数据：

4.6 实例分组机制与 relabel_configs

无论使用哪种服务发现方式，实例分组 的核心机制都是通过 relabel_configs 对元数据标签进行转换、过滤和聚合。分组后的标签将作为时间序列的永久标签，直接影响查询、告警和可视化。

relabel_configs:
  # 将 Consul 的服务名称映射为 job 标签
  - source_labels: ['__meta_consul_service']
    target_label: 'job'
  # 保留 Pod 的 app 标签，并添加环境标签
  - source_labels: ['__meta_kubernetes_pod_label_app']
    target_label: 'app'
  - target_label: 'environment'
    replacement: 'production'
  # 丢弃不包含 metrics 端口的 Pod
  - source_labels: ['__meta_kubernetes_pod_annotation_prometheus_io_scrape']
    regex: 'true'
    action: keep

分组后的标签结构示例：

# 原始实例
10.0.0.1:9100

# 经过 relabel 后附加的标签
job="node_exporter"
instance="10.0.0.1:9100"
group="web"
region="us-east-1"
app="nginx"
namespace="production"

4.7 四种服务发现方式对比

4.8 服务发现架构总览

下图展示了 Prometheus 采集作业平台中，四种服务发现方式如何将原始目标转化为带标签的抓取实例，并最终写入时间序列数据库。

4.9 本章小结

• 作业与实例 是 Prometheus 采集的基本单元，通过 job_name 和 instance 标签唯一标识。
• 静态配置 适合小规模固定环境，文件发现 提供轻量级动态更新，Consul 发现 适用于微服务注册中心，Kubernetes 发现 是云原生场景的标准方案。
• 实例分组 的核心是 relabel_configs，通过元数据标签的转换与过滤实现灵活的目标分类。
• 选择服务发现方式时，需综合考虑 规模、动态性、元数据需求 和 运维成本。