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

鸿观工坊
5 阅读6分钟

随着容器化与微服务架构的普及，被监控对象的形态发生了根本变化。过去以物理机、虚拟机为主体的固定目标，如今逐步被 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。

avatar
文章
阅读
粉丝