第2篇 Prometheus 服务发现：动态目标管理实战

随着容器化与微服务架构的普及，被监控对象的形态发生了根本变化。过去以物理机、虚拟机为主体的固定目标，如今逐步被 Kubernetes 编排下的 Pod、Service 等实例所取代。这些实例的 IP 由集群动态分配，重启即变、扩缩容以秒计，生命周期短则数秒、长也不过数日，监控目标集合始终处于频繁的更迭之中。

面对这种局面，Prometheus 传统的静态配置方式逐渐捉襟见肘。在static_configs中逐个登记 Target 虽然简单直接，但每一个目标都依赖手工维护，配置一旦变更，就需要重新加载甚至重启服务，既增加了运维负担，也可能在重载过程中造成监控采集中断。当目标规模持续扩大、变化频率不断上升时，这种模式几乎不可行。

为此，Prometheus 引入了服务发现（Service Discovery，SD）机制。它通过定期从 Kubernetes API、Consul 等服务注册中心、DNS 记录或本地文件中获取目标列表，在实例增减时自动更新抓取目标，无需手工修改配置或重启服务。配合标签过滤（例如按env、app等筛选），还能实现精细化的目标选择。需要明确的是，服务发现只负责“发现”目标，并不承担目标注册的职责。

承接上篇监控体系的搭建，本篇聚焦服务发现与动态目标管理，将依次介绍常用的服务发现方式及其适用场景、各类方式的选型对比、relabel_configs重标签机制，并结合实际配置给出落地要点，最终让监控目标能够随业务的弹性变化自动跟随。

一、常用服务发现（Service Discovery，SD）方式

方式	适用场景	特点
‌文件发现‌（file_sd_configs）	中小规模、无统一注册中心	写 YAML/JSON 文件即可，改文件自动生效
‌Consul 发现‌（consul_sd_configs）	微服务架构	支持健康检查、元数据过滤
‌Kubernetes 发现‌（kubernetes_sd_configs）	K8s 环境	自动发现 Pod、Service、Node 等角色
‌DNS 发现‌（dns_sd_configs）	域名指向动态 IP 的场景	用 SRV 或 A 记录发现目标
‌HTTP 发现‌（http_sd_configs）	自定义注册中心	通过 URL 拉取目标列表
‌云平台发现‌（EC2、Azure 等）	IaaS 架构	对接云厂商 API 自动发现实例

• relabel_configs‌ 可对发现的目标做过滤和标签重写，比如只保留健康实例、添加业务标签。
• 服务发现只是“发现目标”，不负责注册——目标信息需要你按约定格式发布到对应注册中心。
• 大规模集群（千级以上）建议用 API 型发现（如 K8s SD），DNS 解析效率可能下降。
• 如果使用 Nacos 等注册中心，也可通过其提供的 HTTP SD API 接入 Prometheus。

二、启动单机 Nacos Server

主要是为验证 Prometheus 服务发现效果，因此没有按高可用搭建，也没有考虑持久化。

1、生成安全密钥

$ openssl rand -hex 16 | base64 NGE2NzgwNDk0ZDVjOGFmZGM4NmZiMmJkMjc2ZDcyOWIK

2、启动服务

docker run -d --name nacos \ --restart=no \ --network my-bridge \ -p 8080:8080 \ -p 8848:8848 \ -p 9848:9848 \ -e TZ="Asia/Shanghai" \ -e MODE=standalone \ -e NACOS_AUTH_TOKEN=NGE2NzgwNDk0ZDVjOGFmZGM4NmZiMmJkMjc2ZDcyOWIK \ -e NACOS_AUTH_IDENTITY_KEY=nacos \ -e NACOS_AUTH_IDENTITY_VALUE=nacos123 \ -e nacos.prometheus.metrics.enabled=true \ -e SPRING_DATASOURCE_PLATFORM=mysql \ -e MYSQL_SERVICE_HOST=mysql5 \ -e MYSQL_SERVICE_PORT=3306 \ -e MYSQL_SERVICE_DB_NAME=nacos \ -e MYSQL_SERVICE_USER=root \ -e MYSQL_SERVICE_PASSWORD=NjBlNWM3Me \ -e MYSQL_SERVICE_DB_PARAM="serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf-8&useSSL=false&rewriteBatchedStatements=true&autoReconnect=true&useSSL=false" \ nacos/nacos-server:v3.2.4

注意：

nacos.prometheus.metrics.enabled=true：Nacos 3 的 Prometheus SD 支持默认是关闭的，需要显式开启。

• MODE=standalone：单机模式，非集群；内置 Derby 数据库
• NACOS_AUTH_TOKEN=xxx：JWT 签名密钥，Base64 字符串，Nacos3.x 鉴权必填
• NACOS_AUTH_IDENTITY_KEY=nacos：服务身份校验 Key
• NACOS_AUTH_IDENTITY_VALUE=nacos123：服务身份校验 Value

三、Prometheus 对接‌ Nacos

官方没有直接提供类似Consul 发现‌（consul_sd_configs）模式的 Nacos SD，但可以通过 HTTP SD‌（http_sd_configs）接入 Prometheus。

主要配置如下，重新加载配置后在 prometheus 控制台可发现 targets 增多。

- job_name: 'nacos-discovery' http_sd_configs: - url: 'http://<nacos-server-ip>:8848/nacos/prometheus/namespaceId/<your-namespace-id>' basic_auth: username: 'nacos-user' password: 'nacos-password' refresh_interval: 30s # 可选，默认 60s # 如果业务应用的 metrics 路径不是默认的 /metrics，需在此指定 metrics_path: '/actuator/prometheus'

将<nacos-server-ip>、<your-namespace-id>替换为实际值。Prometheus 会定期调用该接口，自动为每个实例创建抓取目标。

配置示例：http://10.0.2.15:8848/nacos/prometheus/namespaceId/public

三、‌文件发现‌（file_sd_configs）

如果是大规模集群，或是使用了Kubernetes，或是已有成熟的节点监控机制，服务发现机制是很便利的策略，但是由于：

• 不能区分节点是异常宕机下线，还是正常被回收
• 不能判断应监控节点是否都已纳入监控，如新建的ECS漏接入监控后比较难被发现

因此，在个人、中小企业中，还是更推荐采用文件发现‌方式，更进一步，维护的target还可与其他平台交叉核对是否有遗漏。

主要配置：

- job_name: "cim" metrics_path: /metrics relabel_configs: - source_labels: [__address__] target_label: instance file_sd_configs: - files: - scrape_config/cim-local.yml refresh_interval: 5s

编写本系统文章时，Prometheus 配置主要约定如下：

• job_name：系统/应用标识
• 标签 svc：服务标识
• 标签 type：监控对象类型标识，如 node表示主机层，jvm表示java应用

引入文件示例：

- targets: - 10.0.2.15:9100 labels: svc: nodb type: node - targets: - 10.0.2.15:8082 labels: svc: nodb type: jvm __metrics_path__: "/actuator/prometheus"

四、小结

服务发现的核心，在于让抓取目标从「手工登记」变为「动态跟随」，解决的是容器化与微服务环境中实例 IP 漂移、频繁伸缩所带来的静态配置维护难题；同时也须牢记，服务发现只负责「发现」，不负责目标注册。围绕这一目标，本篇要点归纳如下：

• 方式选型按环境决定：Kubernetes 环境优先使用kubernetes_sd_configs；跨环境统一管理可选 Consul 等服务注册中心；云上 IaaS 可借助云厂商 API 发现；域名动态解析场景用dns_sd_configs；自定义注册中心则用http_sd_configs。千级以上大规模集群建议采用 API 型发现，避免 DNS 解析带来的效率下降。
• Nacos 落地实践：官方未提供nacos_sd_configs原生发现，但可借助其 HTTP SD 接口配合http_sd_configs接入。但需注意， Nacos 3 需显式开启nacos.prometheus.metrics.enabled=true。
• 文件发现的取舍与规范：服务发现难以区分节点是异常宕机还是正常回收，也难以察觉新建实例是否漏接入监控；因此在个人与中小企业场景更推荐file_sd_configs，便于排查遗漏并与其他平台交叉核对。

动态目标管理的本质，是让监控目标随业务弹性变化自动跟随。如果目标变化频率很低，作者优先推荐采用 File SD。