前言

        在云原生与微服务架构盛行的今天，服务的动态伸缩、弹性部署已成为基础设施的核心特征。面对频繁变化的实例 IP 和端口，传统静态配置的监控方式显得力不从心。Prometheus 基于文件的服务发现（File-based Service Discovery） 正是解决这一问题的轻量级方案。

        本文将从零开始，系统讲解文件服务发现的工作原理、配置方法，并通过一个完整的实战案例，带你掌握如何在不重启 Prometheus 的情况下动态管理监控目标。

一、什么是服务发现（Service Discovery）

1.1 为什么需要服务发现

        在 Prometheus 的监控体系中，抓取目标（Target） 是需要被监控的端点列表。在入门阶段，我们通常使用 静态配置（static_configs） 将目标的 IP 和端口直接写在 prometheus.yml 中：

yaml

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets:
        - '192.168.1.101:9100'
        - '192.168.1.102:9100'
        - '192.168.1.103:9100'

这种方式的缺陷显而易见：

问题	说明
维护成本高	每次新增或移除服务器，都需要手动修改配置文件
需要重启	修改配置后必须重启 Prometheus 才能生效
无法适应动态环境	在容器、云平台等动态环境中，实例 IP 频繁变化，静态配置完全不可行

        服务发现（Service Discovery） 正是为解决这些问题而生——它让 Prometheus 能够自动发现需要监控的目标，并动态更新抓取列表。

1.2 Prometheus 服务发现的几种方式

        Prometheus 支持多种服务发现机制：

服务发现方式	适用场景
static_configs	小型固定环境，目标基本不变
file_sd_configs	需要动态更新但无法集成第三方平台的环境
Consul SD	使用 Consul 作为服务注册中心的微服务架构
Kubernetes SD	Kubernetes 集群内的 Pod、Service、Endpoint 自动发现
EC2 / GCE SD	AWS / Google Cloud 云平台自动发现

        其中，基于文件的服务发现是最通用、最灵活的方式——它不依赖于任何平台或第三方服务，Prometheus 会定时从文件中读取最新的 Target 信息。

1.3 什么是基于文件的服务发现

        基于文件的服务发现允许 Prometheus 通过读取磁盘上的文件来发现监控目标。这些文件通常包含 JSON 或 YAML 格式的目标列表。当文件内容发生变化时，Prometheus 会自动更新抓取目标列表，无需重启服务。

这种方式介于静态配置和完全动态的服务发现之间——它比静态配置更灵活，又比 Consul、Kubernetes 等服务发现更简单、更通用。

二、基于文件的服务发现的工作原理

        文件服务发现的工作流程可以概括为四个步骤：

text

┌─────────────────────────────────────────────────────────────────┐
│  ① 外部系统（脚本/CMDB/Ansible/手动）生成目标文件                 │
│     └── 文件格式：JSON 或 YAML                                   │
│                          ↓                                     │
│  ② Prometheus 定时轮询读取文件内容                             │
│     └── 通过 refresh_interval 控制刷新频率（默认5分钟）        │
│                          ↓                                     │
│  ③ 对比内容变化，自动更新内存中的抓取目标列表                   │
│     └── 目标新增 → 自动开始抓取                                │
│     └── 目标移除 → 自动停止抓取                                │
│                          ↓                                     │
│  ④ 按规律周期性采集指标数据                                    │
└─────────────────────────────────────────────────────────────────┘

关键特性：

• 热加载：文件变化后自动生效，无需重启 Prometheus

• 格式灵活：支持 JSON 和 YAML 两种格式

• 多种写入方式：文件可以由任何外部进程生成——配置管理工具（Ansible）、自定义脚本、手动编辑等

三、环境准备

        在开始配置之前，请确保你已经具备以下条件：

项目	说明
操作系统	Linux（CentOS 7/8 或 Ubuntu 20.04+）
Prometheus	已安装并正常运行（参考本系列之前的文章）
Node Exporter	已安装并运行在至少一台机器上（用于演示）
权限	有权限编辑 Prometheus 配置文件和创建目标文件

四、配置文件详解

4.1 Prometheus 主配置文件

操作文件：/etc/prometheus/prometheus.yml

        这是 Prometheus 的核心配置文件，我们需要在其中添加 file_sd_configs 配置块。

yaml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  # ============================================
  # 基于文件的服务发现示例
  # ============================================
  - job_name: 'file-sd-demo'
    file_sd_configs:
      # 要监听的目标文件列表（支持通配符）
      - files:
          - 'targets/*.json'
          - 'targets/*.yml'
        # 文件刷新间隔（默认 5 分钟）
        refresh_interval: 30s

各配置项说明：

配置项	说明
job_name	监控任务的名称，所有从该任务发现的目标都会带上 job="file-sd-demo" 标签
file_sd_configs	文件服务发现配置块
files	要监听的文件列表，支持通配符（*、**）
refresh_interval	文件刷新间隔，Prometheus 会定期重新读取文件内容

关于 refresh_interval：该参数默认为 5 分钟。值得注意的是，Prometheus 本身会通过文件系统事件监听文件变更并实时刷新，refresh_interval 更多是作为一种补偿机制。在大多数场景下，保持默认值即可。

该文件的作用：定义 Prometheus 的全局配置和所有抓取任务，其中 file_sd_configs 告诉 Prometheus 去哪些文件中读取动态目标列表。

4.2 目标文件（Target File）

目标文件是文件服务发现的核心——它包含了所有需要监控的目标列表和标签信息。

操作文件：/opt/prometheus/targets/node_targets.json（路径可自定义）

JSON 格式示例：

json

[
  {
    "targets": [
      "192.168.1.101:9100",
      "192.168.1.102:9100"
    ],
    "labels": {
      "env": "production",
      "team": "infrastructure",
      "datacenter": "bj"
    }
  },
  {
    "targets": [
      "192.168.1.103:9100"
    ],
    "labels": {
      "env": "staging",
      "team": "development",
      "datacenter": "sh"
    }
  }
]

YAML 格式示例：

yaml

- targets:
    - "192.168.1.101:9100"
    - "192.168.1.102:9100"
  labels:
    env: "production"
    team: "infrastructure"
    datacenter: "bj"

- targets:
    - "192.168.1.103:9100"
  labels:
    env: "staging"
    team: "development"
    datacenter: "sh"

各字段说明：

字段	类型	说明
targets	字符串数组	要监控的目标地址列表（格式：<host>:<port>）
labels	键值对对象	为这些目标附加的自定义标签

该文件的作用：存储所有需要 Prometheus 动态发现的监控目标及其元数据标签。Prometheus 会定期读取此文件，并根据文件内容的变化自动更新抓取目标列表。

重要提示：在目标文件中，可以使用 job 标签覆盖 Prometheus 主配置中 job_name 的默认值。这意味着你可以在同一个 file_sd_configs 中管理多个不同作业的目标。

4.3 文件路径规划建议

在生产环境中，建议按照以下规范组织文件：

text

/etc/prometheus/
├── prometheus.yml              # Prometheus 主配置文件
├── targets/                    # 目标文件目录（推荐单独创建）
│   ├── node_exporter.json      # Node Exporter 目标
│   ├── mysql_exporter.json     # MySQL Exporter 目标
│   ├── redis_exporter.json     # Redis Exporter 目标
│   └── blackbox_http.yml       # Blackbox HTTP 探测目标
└── rules/
    └── alerts.yml              # 告警规则文件

这样组织的好处：

• 不同服务/组件的目标文件相互隔离，便于管理

• 修改某个文件只影响对应的监控任务

• 支持通过通配符批量加载

五、实战案例：监控动态 Node Exporter 集群

        下面通过一个完整的实战案例，演示如何用文件服务发现来监控一组动态变化的 Node Exporter 实例。

5.1 场景描述

        假设我们有 3 台 Linux 服务器，每台都运行着 Node Exporter（端口 9100）。这些服务器可能会动态增减（如云平台自动伸缩），我们希望 Prometheus 能自动发现新增的服务器并开始监控，同时在服务器下线后自动停止抓取。

5.2 步骤一：确保 Node Exporter 正常运行

        在所有需要监控的服务器上安装并启动 Node Exporter（参考本系列之前的文章）：

bash

# 在每台服务器上
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz
sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false node_exporter

# 创建 systemd 服务（/etc/systemd/system/node_exporter.service）
sudo systemctl daemon-reload
sudo systemctl start node_exporter
sudo systemctl enable node_exporter

5.3 步骤二：创建目标文件目录

bash

# 在 Prometheus 服务器上创建目标文件目录
sudo mkdir -p /etc/prometheus/targets

该目录的作用：集中存放所有服务发现的目标文件，便于管理和维护。

5.4 步骤三：创建目标文件

操作文件：/etc/prometheus/targets/node_exporter.json

bash

sudo tee /etc/prometheus/targets/node_exporter.json <<'EOF'
[
  {
    "targets": [
      "192.168.1.101:9100",
      "192.168.1.102:9100",
      "192.168.1.103:9100"
    ],
    "labels": {
      "env": "production",
      "service": "node_exporter"
    }
  }
]
EOF

该文件的作用：定义当前需要监控的所有 Node Exporter 目标及其标签。

5.5 步骤四：配置 Prometheus

操作文件：/etc/prometheus/prometheus.yml

在 scrape_configs 部分添加以下配置：

yaml

scrape_configs:
  # ... 其他 job 配置 ...

  # 基于文件的服务发现 - Node Exporter
  - job_name: 'node'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/node_exporter.json'
        refresh_interval: 1m

该文件的作用：告诉 Prometheus 从 /etc/prometheus/targets/node_exporter.json 文件中动态读取 Node Exporter 的目标列表，并每隔 1 分钟刷新一次。

5.6 步骤五：验证配置文件并重启 Prometheus

bash

# 检查配置文件语法
promtool check config /etc/prometheus/prometheus.yml

# 重启 Prometheus（使配置生效）
sudo systemctl restart prometheus

# 或使用热加载（推荐）
sudo systemctl reload prometheus

5.7 步骤六：验证服务发现效果

方式一：通过 Prometheus UI 查看

1. 访问 http://<Prometheus_IP>:9090/targets

2. 在 Targets 页面中，你应该能看到 node 作业下的 3 个目标，状态均为 UP

方式二：通过 Service Discovery 页面查看

1. 访问 http://<Prometheus_IP>:9090/service-discovery

2. 找到 node 作业，可以看到从文件中加载的所有目标和标签

5.8 步骤七：动态添加新目标（验证热加载）

现在，假设有一台新的服务器 192.168.1.104 上线并运行了 Node Exporter。我们只需更新目标文件即可：

操作文件：/etc/prometheus/targets/node_exporter.json

bash

sudo tee /etc/prometheus/targets/node_exporter.json <<'EOF'
[
  {
    "targets": [
      "192.168.1.101:9100",
      "192.168.1.102:9100",
      "192.168.1.103:9100",
      "192.168.1.104:9100"    # 新增的目标
    ],
    "labels": {
      "env": "production",
      "service": "node_exporter"
    }
  }
]
EOF

无需重启 Prometheus！等待 refresh_interval（1 分钟）后，新目标会自动出现在 Targets 列表中，Prometheus 开始采集其指标。

5.9 步骤八：动态移除目标

如果某台服务器下线，只需从目标文件中移除对应的 IP 和端口，Prometheus 会自动停止抓取该目标。

六、进阶用法：多文件管理与标签覆盖

6.1 使用通配符管理多个文件

如果监控的服务类型较多，可以将不同类型的目标放在不同的文件中，通过通配符统一加载：

yaml

scrape_configs:
  - job_name: 'file-sd-all'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/*.json'
          - '/etc/prometheus/targets/*.yml'
        refresh_interval: 1m

文件目录结构：

text

/etc/prometheus/targets/
├── node_exporter.json      # Node Exporter 目标
├── mysql_exporter.json     # MySQL Exporter 目标
├── redis_exporter.json     # Redis Exporter 目标
└── blackbox_http.yml       # Blackbox HTTP 探测目标

该方式的作用：将不同服务的监控目标分离到不同文件中，便于各自独立更新，互不影响。

6.2 在目标文件中覆盖 job 名称

在目标文件中可以使用 job 标签覆盖 Prometheus 主配置中的 job_name：

目标文件（/etc/prometheus/targets/mixed.json）：

json

[
  {
    "targets": ["192.168.1.101:9100", "192.168.1.102:9100"],
    "labels": {
      "job": "node_exporter",
      "env": "production"
    }
  },
  {
    "targets": ["192.168.1.101:9104"],
    "labels": {
      "job": "mysql_exporter",
      "env": "production"
    }
  }
]

Prometheus 主配置：

yaml

scrape_configs:
  - job_name: 'file-sd-default'    # 会被文件中的 job 标签覆盖
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/mixed.json'

这样，同一个文件中可以管理多个不同作业的目标，每个目标使用自己的 job 标签。

七、文件服务发现的优缺点

7.1 优点

优点	说明
无需重启	文件变化后自动生效，实现热加载
不依赖第三方	不需要 Consul、Etcd 等外部服务
格式灵活	支持 JSON 和 YAML 两种格式
易于集成	可与 Ansible、CMDB、自定义脚本等任意系统配合
适合混合云	在无法直接对接云平台 API 的环境中尤为适用

7.2 缺点

缺点	说明
不是实时发现	存在刷新间隔延迟（默认 5 分钟）
需要额外维护	需要有外部机制生成或更新目标文件
扩展性有限	目标数量很大时，文件解析可能成为瓶颈

7.3 适用场景总结

基于文件的服务发现特别适合以下场景：

1. 无法集成 API 的遗留系统：老系统没有服务注册机制，但可以通过脚本生成目标文件

2. 混合云环境：同时使用多个云平台，无法统一对接 API

3. 与配置管理工具结合：Ansible、Puppet 等在部署时生成目标文件

4. 临时/测试环境：需要快速添加或移除监控目标

5. Prometheus 不支持的云平台：如国内阿里云、腾讯云等

八、操作文件速查表

文件路径	作用
/etc/prometheus/prometheus.yml	Prometheus 主配置文件，定义 file_sd_configs 及文件路径
/etc/prometheus/targets/	推荐的目标文件存放目录（需手动创建）
/etc/prometheus/targets/node_exporter.json	Node Exporter 目标文件（JSON 格式）
/etc/prometheus/targets/mysql_exporter.json	MySQL Exporter 目标文件（示例）
/etc/prometheus/targets/*.yml	YAML 格式的目标文件（支持通配符加载）

配置生效方式：

• 修改 prometheus.yml → 需要重启或热加载 Prometheus

• 修改目标文件（*.json / *.yml）→ 无需任何操作，自动生效

九、总结

本文系统介绍了 Prometheus 基于文件的服务发现（File-based Service Discovery）的完整知识体系：

1. 服务发现的意义：解决静态配置在动态环境中的维护难题，实现监控目标的自动化管理

2. 工作原理：外部系统生成目标文件 → Prometheus 定期读取 → 自动更新抓取目标列表 → 无需重启

3. 核心配置：

   • 在 /etc/prometheus/prometheus.yml 中添加 file_sd_configs 配置块

   • 创建 JSON 或 YAML 格式的目标文件

   • 通过 refresh_interval 控制刷新频率

4. 实战案例：通过监控 Node Exporter 集群的完整流程，演示了文件的创建、配置、验证和动态更新

5. 适用场景：混合云环境、遗留系统、配置管理工具集成、临时环境等

一句话总结：基于文件的服务发现是 Prometheus 中最通用、最灵活的动态目标管理方式——你只需要维护好目标文件，Prometheus 会自动完成剩下的所有工作，无需重启，无需第三方依赖。