前言在云原生与微服务架构盛行的今天服务的动态伸缩、弹性部署已成为基础设施的核心特征。面对频繁变化的实例 IP 和端口传统静态配置的监控方式显得力不从心。Prometheus 基于文件的服务发现File-based Service Discovery正是解决这一问题的轻量级方案。本文将从零开始系统讲解文件服务发现的工作原理、配置方法并通过一个完整的实战案例带你掌握如何在不重启 Prometheus 的情况下动态管理监控目标。一、什么是服务发现Service Discovery1.1 为什么需要服务发现在 Prometheus 的监控体系中抓取目标Target是需要被监控的端点列表。在入门阶段我们通常使用静态配置static_configs将目标的 IP 和端口直接写在prometheus.yml中yamlscrape_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 SDKubernetes 集群内的 Pod、Service、Endpoint 自动发现EC2 / GCE SDAWS / 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、自定义脚本、手动编辑等三、环境准备在开始配置之前请确保你已经具备以下条件项目说明操作系统LinuxCentOS 7/8 或 Ubuntu 20.04Prometheus已安装并正常运行参考本系列之前的文章Node Exporter已安装并运行在至少一台机器上用于演示权限有权限编辑 Prometheus 配置文件和创建目标文件四、配置文件详解4.1 Prometheus 主配置文件操作文件/etc/prometheus/prometheus.yml这是 Prometheus 的核心配置文件我们需要在其中添加file_sd_configs配置块。yamlglobal: 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监控任务的名称所有从该任务发现的目标都会带上jobfile-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:portlabels键值对对象为这些目标附加的自定义标签该文件的作用存储所有需要 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_exporter5.3 步骤二创建目标文件目录bash# 在 Prometheus 服务器上创建目标文件目录 sudo mkdir -p /etc/prometheus/targets该目录的作用集中存放所有服务发现的目标文件便于管理和维护。5.4 步骤三创建目标文件操作文件/etc/prometheus/targets/node_exporter.jsonbashsudo 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部分添加以下配置yamlscrape_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 步骤五验证配置文件并重启 Prometheusbash# 检查配置文件语法 promtool check config /etc/prometheus/prometheus.yml # 重启 Prometheus使配置生效 sudo systemctl restart prometheus # 或使用热加载推荐 sudo systemctl reload prometheus5.7 步骤六验证服务发现效果方式一通过 Prometheus UI 查看访问http://Prometheus_IP:9090/targets在 Targets 页面中你应该能看到node作业下的 3 个目标状态均为UP方式二通过 Service Discovery 页面查看访问http://Prometheus_IP:9090/service-discovery找到node作业可以看到从文件中加载的所有目标和标签5.8 步骤七动态添加新目标验证热加载现在假设有一台新的服务器192.168.1.104上线并运行了 Node Exporter。我们只需更新目标文件即可操作文件/etc/prometheus/targets/node_exporter.jsonbashsudo 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_interval1 分钟后新目标会自动出现在 Targets 列表中Prometheus 开始采集其指标。5.9 步骤八动态移除目标如果某台服务器下线只需从目标文件中移除对应的 IP 和端口Prometheus 会自动停止抓取该目标。六、进阶用法多文件管理与标签覆盖6.1 使用通配符管理多个文件如果监控的服务类型较多可以将不同类型的目标放在不同的文件中通过通配符统一加载yamlscrape_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.jsonjson[ { 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 主配置yamlscrape_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 适用场景总结基于文件的服务发现特别适合以下场景无法集成 API 的遗留系统老系统没有服务注册机制但可以通过脚本生成目标文件混合云环境同时使用多个云平台无法统一对接 API与配置管理工具结合Ansible、Puppet 等在部署时生成目标文件临时/测试环境需要快速添加或移除监控目标Prometheus 不支持的云平台如国内阿里云、腾讯云等八、操作文件速查表文件路径作用/etc/prometheus/prometheus.ymlPrometheus 主配置文件定义file_sd_configs及文件路径/etc/prometheus/targets/推荐的目标文件存放目录需手动创建/etc/prometheus/targets/node_exporter.jsonNode Exporter 目标文件JSON 格式/etc/prometheus/targets/mysql_exporter.jsonMySQL Exporter 目标文件示例/etc/prometheus/targets/*.ymlYAML 格式的目标文件支持通配符加载配置生效方式修改prometheus.yml→ 需要重启或热加载 Prometheus修改目标文件*.json/*.yml→无需任何操作自动生效九、总结本文系统介绍了 Prometheus 基于文件的服务发现File-based Service Discovery的完整知识体系服务发现的意义解决静态配置在动态环境中的维护难题实现监控目标的自动化管理工作原理外部系统生成目标文件 → Prometheus 定期读取 → 自动更新抓取目标列表 → 无需重启核心配置在/etc/prometheus/prometheus.yml中添加file_sd_configs配置块创建 JSON 或 YAML 格式的目标文件通过refresh_interval控制刷新频率实战案例通过监控 Node Exporter 集群的完整流程演示了文件的创建、配置、验证和动态更新适用场景混合云环境、遗留系统、配置管理工具集成、临时环境等一句话总结基于文件的服务发现是 Prometheus 中最通用、最灵活的动态目标管理方式——你只需要维护好目标文件Prometheus 会自动完成剩下的所有工作无需重启无需第三方依赖。
