随着容器化与微服务架构的普及被监控对象的形态发生了根本变化。过去以物理机、虚拟机为主体的固定目标如今逐步被 Kubernetes 编排下的 Pod、Service 等实例所取代。这些实例的 IP 由集群动态分配重启即变、扩缩容以秒计生命周期短则数秒、长也不过数日监控目标集合始终处于频繁的更迭之中。面对这种局面Prometheus 传统的静态配置方式逐渐捉襟见肘。在static_configs中逐个登记 Target 虽然简单直接但每一个目标都依赖手工维护配置一旦变更就需要重新加载甚至重启服务既增加了运维负担也可能在重载过程中造成监控采集中断。当目标规模持续扩大、变化频率不断上升时这种模式几乎不可行。为此Prometheus 引入了服务发现Service DiscoverySD机制。它通过定期从 Kubernetes API、Consul 等服务注册中心、DNS 记录或本地文件中获取目标列表在实例增减时自动更新抓取目标无需手工修改配置或重启服务。配合标签过滤例如按env、app等筛选还能实现精细化的目标选择。需要明确的是服务发现只负责“发现”目标并不承担目标注册的职责。承接上篇监控体系的搭建本篇聚焦服务发现与动态目标管理将依次介绍常用的服务发现方式及其适用场景、各类方式的选型对比、relabel_configs重标签机制并结合实际配置给出落地要点最终让监控目标能够随业务的弹性变化自动跟随。一、常用服务发现Service DiscoverySD方式方式适用场景特点‌文件发现‌file_sd_configs中小规模、无统一注册中心写 YAML/JSON 文件即可改文件自动生效‌Consul 发现‌consul_sd_configs微服务架构支持健康检查、元数据过滤‌Kubernetes 发现‌kubernetes_sd_configsK8s 环境自动发现 Pod、Service、Node 等角色‌DNS 发现‌dns_sd_configs域名指向动态 IP 的场景用 SRV 或 A 记录发现目标‌HTTP 发现‌http_sd_configs自定义注册中心通过 URL 拉取目标列表‌云平台发现‌EC2、Azure 等IaaS 架构对接云厂商 API 自动发现实例relabel_configs‌ 可对发现的目标做过滤和标签重写比如只保留健康实例、添加业务标签。服务发现只是“发现目标”不负责注册——目标信息需要你按约定格式发布到对应注册中心。大规模集群千级以上建议用 API 型发现如 K8s SDDNS 解析效率可能下降。如果使用 Nacos 等注册中心也可通过其提供的 HTTP SD API 接入 Prometheus。二、启动单机 Nacos Server主要是为验证 Prometheus 服务发现效果因此没有按高可用搭建也没有考虑持久化。1、生成安全密钥$ openssl rand -hex 16 | base64 NGE2NzgwNDk0ZDVjOGFmZGM4NmZiMmJkMjc2ZDcyOWIK2、启动服务docker run -d --name nacos \ --restartno \ --network my-bridge \ -p 8080:8080 \ -p 8848:8848 \ -p 9848:9848 \ -e TZAsia/Shanghai \ -e MODEstandalone \ -e NACOS_AUTH_TOKENNGE2NzgwNDk0ZDVjOGFmZGM4NmZiMmJkMjc2ZDcyOWIK \ -e NACOS_AUTH_IDENTITY_KEYnacos \ -e NACOS_AUTH_IDENTITY_VALUEnacos123 \ -e nacos.prometheus.metrics.enabledtrue \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOSTmysql5 \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos \ -e MYSQL_SERVICE_USERroot \ -e MYSQL_SERVICE_PASSWORDNjBlNWM3Me \ -e MYSQL_SERVICE_DB_PARAMserverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf-8useSSLfalserewriteBatchedStatementstrueautoReconnecttrueuseSSLfalse \ nacos/nacos-server:v3.2.4注意nacos.prometheus.metrics.enabledtrueNacos 3 的 Prometheus SD 支持默认是关闭的需要显式开启。MODEstandalone单机模式非集群内置 Derby 数据库NACOS_AUTH_TOKENxxxJWT 签名密钥Base64 字符串Nacos3.x 鉴权必填NACOS_AUTH_IDENTITY_KEYnacos服务身份校验 KeyNACOS_AUTH_IDENTITY_VALUEnacos123服务身份校验 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.enabledtrue。文件发现的取舍与规范服务发现难以区分节点是异常宕机还是正常回收也难以察觉新建实例是否漏接入监控因此在个人与中小企业场景更推荐file_sd_configs便于排查遗漏并与其他平台交叉核对。动态目标管理的本质是让监控目标随业务弹性变化自动跟随。如果目标变化频率很低作者优先推荐采用 File SD。