4. 静态服务发现：基于配置文件的目标管理

在 Prometheus 的采集架构中，服务发现决定了 “抓谁” 和 “怎么抓”。静态服务发现（static_config）是最基础、最直接的目标管理方式，它不依赖任何外部注册中心或 API，完全通过 Prometheus 配置文件中的 targets 列表来定义采集端点。对于节点数量固定、网络拓扑稳定的场景，静态配置是运维复杂度最低的选择。

4.1 静态服务发现的核心机制

静态服务发现的工作原理可以概括为：配置即发现。Prometheus 在启动或热加载时，直接解析 scrape_configs 下的 static_configs 块，将其中列出的 targets 转换为内部的目标列表，并按照 scrape_interval 周期性地发起 HTTP 请求。

4.2 配置文件结构与参数详解

一个标准的 static_config 块包含 targets 和 labels 两个核心字段。targets 定义抓取地址（<host>:<port>），labels 为这些目标附加额外的标签，用于后续的指标过滤、分组和告警路由。

# prometheus.yml 示例片段
scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets:
          - '10.0.0.1:9100'
          - '10.0.0.2:9100'
          - '10.0.0.3:9100'
        labels:
          region: 'us-east-1'
          env: 'production'
      - targets:
          - '10.0.1.1:9100'
          - '10.0.1.2:9100'
        labels:
          region: 'eu-west-1'
          env: 'staging'
    # 全局覆盖参数（可选）
    scrape_interval: 15s
    scrape_timeout: 10s
    metrics_path: '/metrics'
    scheme: 'http'

4.3 多目标分组与标签策略

静态配置支持在一个 static_configs 数组内定义多个 targets 块，每个块可以携带不同的 labels。这种分组方式在混合环境（如多机房、多环境）中非常实用。

scrape_configs:
  - job_name: 'web_app'
    static_configs:
      # 生产环境主集群
      - targets: ['web-01.prod:8080', 'web-02.prod:8080', 'web-03.prod:8080']
        labels:
          cluster: 'prod-main'
          tier: 'frontend'
      # 生产环境备用集群
      - targets: ['web-04.prod:8080', 'web-05.prod:8080']
        labels:
          cluster: 'prod-dr'
          tier: 'frontend'
      # 测试环境
      - targets: ['web-test-01.staging:8080']
        labels:
          cluster: 'staging'
          tier: 'frontend'

通过这种分组，可以在 PromQL 中利用 cluster 和 tier 标签进行灵活的聚合查询：

# 查询生产主集群的平均请求延迟
avg by (instance) (http_request_duration_seconds{cluster="prod-main"})

# 对比生产与测试环境的错误率
sum by (cluster) (rate(http_requests_total{status=~"5.."}[5m]))

4.4 静态服务发现的局限性

虽然静态配置简单可靠，但在大规模或动态环境中存在明显短板。下表对比了静态发现与动态发现的差异：

4.5 配置文件管理与自动化

对于静态配置的维护，推荐采用 配置生成器 + 版本控制 的模式，避免直接编辑 YAML 导致格式错误或目标遗漏。

1. 模板化：使用 Jinja2、Go template 或 Jsonnet 定义目标列表模板。
2. 自动化生成：通过 CMDB、Ansible inventory 或 Terraform 输出动态生成 prometheus.yml。
3. 校验与重载：使用 promtool check config 验证语法，再触发热加载。

# 使用 promtool 校验配置
promtool check config /etc/prometheus/prometheus.yml

# 校验通过后触发热加载
curl -X POST http://localhost:9090/-/reload

4.6 性能与可靠性考量

静态服务发现虽然简单，但在大规模部署时仍需关注以下优化点：

• 配置文件大小：单个 prometheus.yml 文件不宜超过 10MB，否则热加载解析时间会显著增加。建议将目标列表拆分为多个文件，使用 rule_files 或 scrape_config_files 引入。
• 目标健康检查：静态配置不会自动剔除故障目标。建议配合 up 指标和告警规则，及时发现并手动清理不可达目标。
• 标签冲突：static_configs 中定义的 labels 会覆盖从 job_name 继承的标签。务必在 relabel_configs 中做好标签冲突的规划。

# 告警规则示例：检测静态目标是否离线
groups:
  - name: static_target_alerts
    rules:
      - alert: StaticTargetDown
        expr: up{job="node_exporter"} == 0
        for: 5m
        annotations:
          summary: "静态目标 {{ $labels.instance }} 已离线超过 5 分钟"