1. 从静态配置到动态发现为什么服务发现是Prometheus落地的分水岭如果你维护过超过十台机器的Prometheus实例大概率经历过这样的场景每次新扩一台节点就得手动改一遍prometheus.yml然后热加载或者重启。一开始还能忍等到节点数量上到几十台、上百台或者容器化环境里Pod每天翻来覆去地重建这种人肉维护target列表的方式就彻底崩了。服务发现机制就是在这个节点上从能用变成好用的关键分水岭。Prometheus的服务发现本质上解决的是一个很朴素的问题监控目标从哪来。静态配置里target是你手写死的服务发现里target是Prometheus主动去某个信息源拉取、动态生成的。这个信息源可以是云厂商的API、可以是容器编排平台的元数据接口、可以是DNS记录、也可以是本地的一个JSON文件。Prometheus内置了十几种服务发现机制覆盖了绝大多数主流的基础设施形态。这篇文章面向的是已经跑通了Prometheus基础抓取、正在往生产环境规模化落地的同学。我会把服务发现的核心机制、几种主流类型的实操配置、relabeling这个绕不开的坎、以及我自己踩过的坑完整地拆一遍。如果你还在用静态配置单机玩看完这篇你应该能理解为什么服务发现值得花时间学如果你已经在用但总觉得配置写得糊里糊涂这篇能帮你把逻辑理顺。先说一个反直觉的结论服务发现本身不复杂复杂的是relabeling。很多人觉得服务发现难其实难的不是怎么发现而是发现之后怎么筛选、怎么改写、怎么打标签。这个认知很重要它决定了你学习时的精力分配。2. 服务发现的通用工作模型Prometheus到底在背后做了什么2.1 发现、标签、抓取三段式流程不管用哪种服务发现机制Prometheus内部的处理流程都是同一套三段式发现目标 → 附加元标签 → 生成抓取配置。第一步Prometheus按照你配置的*_sd_configs周期性地去对应的信息源拉取目标列表。比如你用Kubernetes服务发现它就会去调用API Server拿到Pod、Service、Endpoints等资源你用文件服务发现它就去读你指定的JSON文件。这个拉取是有周期的默认跟scrape_interval相关但实际刷新频率由各SD实现自己控制。第二步每个被发现的目标都会带上一堆元标签meta labels这些标签以__meta_开头比如__meta_kubernetes_pod_name、__meta_filepath。这些元标签是服务发现给你的原始素材它们本身不会成为最终指标上的标签而是供你在relabeling阶段加工使用。第三步经过relabeling处理后剩下的标签和target地址一起构成一个真正的抓取任务。这里有个关键点以__开头的标签在relabeling结束后会被丢弃除非你显式地把它们重命名成不带下划线的标签。这个规则是理解整个标签体系的核心。2.2 元标签的命名规律与生命周期元标签的命名不是随意的它遵循一套约定__meta_发现类型_资源_字段。比如元标签示例含义__meta_kubernetes_pod_namePod名称__meta_kubernetes_namespace命名空间__meta_consul_serviceConsul服务名__meta_filepath文件SD的文件路径__meta_ec2_instance_id云主机实例ID理解这个命名规律你就能在写relabeling规则时猜出该用哪个标签不用每次都翻文档。我自己的习惯是配置前先让Prometheus把原始元标签dump出来看一眼这样最稳妥。元标签的生命周期很短它们只在relabeling阶段存在。relabeling结束后所有__开头的标签被清理只有被你target_label重写过的、或者通过labelmap映射过的标签才会保留到最终指标上。这个设计的好处是避免元数据污染指标坏处是新手经常忘了元标签不会自动变成指标标签导致配了半天发现指标上啥标签都没有。2.3 刷新周期与抓取周期的关系这里有个容易混淆的点服务发现的刷新周期和抓取周期是两回事。抓取周期是scrape_interval决定多久抓一次指标服务发现刷新周期决定多久重新拉一次target列表。默认情况下Prometheus会在每次抓取前检查target列表是否需要刷新但实际刷新频率受各SD实现限制。举个实际例子Kubernetes SD默认的刷新间隔跟API Server的watch机制配合基本能做到准实时而文件SD依赖你配置的refresh_interval默认是5分钟。这意味着如果你用文件SD新加的目标最多要等5分钟才会被抓取。这个延迟在故障排查时经常被忽略——我明明改了文件怎么没生效答案往往就是刷新周期没到。提示调试服务发现时把refresh_interval临时调小比如10s能大幅缩短你的验证循环。生产环境再调回合理值。3. 主流服务发现类型实操从文件到Kubernetes3.1 文件服务发现最被低估的万能胶文件服务发现file_sd看起来最土但它其实是最灵活的一种。因为它把目标从哪来这个问题完全解耦了——你可以用任何脚本、任何语言生成一个JSON文件Prometheus只管读。配置长这样scrape_configs: - job_name: file-sd-demo file_sd_configs: - files: - /etc/prometheus/targets/*.json refresh_interval: 30s对应的JSON文件格式[ { targets: [10.0.0.1:9100, 10.0.0.2:9100], labels: { env: prod, role: node-exporter } } ]这个格式的关键在于targets是必填的地址列表labels是附加到这批目标上的自定义标签。注意这里的labels是直接生效的不需要relabeling——这是file_sd的一个特殊之处它给的标签不带__前缀直接就是最终标签。我为什么说它被低估因为在混合云、自建机房、或者一些没有标准SD支持的场景里file_sd是唯一的出路。你可以写个定时任务从CMDB、从数据库、从任意地方拉目标列表生成JSONPrometheus自动加载。这种自己动手的方案灵活性反而最高。实操心得文件更新时建议用原子写先写临时文件再mv覆盖避免Prometheus读到写了一半的JSON导致解析失败。这个坑我在生产环境踩过一次表现为target列表突然清空排查了半天才发现是脚本直接覆盖写导致的。3.2 Kubernetes服务发现五种角色的选择逻辑Kubernetes SD是使用频率最高、也最容易配错的一种。它提供了五种发现角色rolenode、service、pod、endpoints、endpointslice、ingress。选哪个角色取决于你要监控什么。role发现对象典型用途node集群节点监控节点本身serviceService对象发现Service的ClusterIPpodPod对象直接抓PodendpointsEndpoints抓Service背后的实际PodendpointsliceEndpointSliceendpoints的升级版ingressIngress监控入口这里有个高频误区很多人用pod角色去抓应用指标结果抓到了一堆还没Ready的Pod。正确做法通常是用endpoints或endpointslice角色因为它们只包含Ready的、真正在提供服务的目标。pod角色适合抓那些每个Pod都要抓、不管Ready与否的场景比如日志采集器的指标。一个典型的endpoints配置scrape_configs: - job_name: kubernetes-endpoints kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.) - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port] action: replace target_label: __address__ regex: ([^:])(?::\d)?;(\d) replacement: $1:$2这段配置的逻辑是只抓那些带了prometheus.io/scrape: true注解的Service路径和端口也从注解里读。这是社区里非常流行的一套约定好处是应用团队自己通过注解就能控制要不要被监控、从哪个端口抓不用改Prometheus配置。3.3 云厂商与Consul类服务发现如果你在云上跑云厂商的SD能直接通过API拿到实例列表。以EC2为例配置里可以按标签、按区域、按安全组过滤scrape_configs: - job_name: ec2-nodes ec2_sd_configs: - region: ap-northeast-1 port: 9100 filters: - name: tag:Monitoring values: [enabled]filters是关键它让你在API层面就过滤掉不需要的实例减少Prometheus的处理负担。我见过有人不加filter把整个账号几百台实例全拉进来再靠relabeling筛结果Prometheus内存飙升。能在源头过滤的绝不留到relabeling这是性能优化的基本原则。Consul SD适合服务注册中心是Consul的架构。它支持按服务名、按标签、按数据中心过滤还能拿到Consul的健康检查状态。配置上跟其他SD大同小异核心还是relabeling那套。DNS服务发现则适合那些有稳定DNS记录的场景比如用SRV记录暴露服务。它的优点是零依赖——只要有DNS就行缺点是DNS的TTL和缓存机制会让发现不够实时且拿不到丰富的元数据。4. Relabeling服务发现真正的技术深水区4.1 relabel_configs与metric_relabel_configs的分工很多人把这两个搞混。记住一句话relabel_configs管targetmetric_relabel_configs管指标。relabel_configs在抓取之前执行作用于target和它的元标签决定抓不抓、怎么抓、抓来的数据带什么标签。metric_relabel_configs在抓取之后执行作用于已经抓到的每一条指标决定哪些指标丢弃、哪些标签改写。前者是服务发现的核心后者是数据清洗的工具。这个分工很重要因为它们的执行时机不同能访问的标签也不同。relabel_configs里你能看到__meta_*元标签metric_relabel_configs里你看到的是指标自带的标签看不到元标签。4.2 八个action的语义与选择relabeling的action有八个replace、keep、drop、hashmod、labelmap、labeldrop、labelkeep、lowercase、uppercase。常用的就前几个。keep只保留匹配的目标其余丢弃。最常用于白名单过滤。drop丢弃匹配的目标。用于黑名单。replace替换或创建标签。最灵活也最容易写错。labelmap把匹配的元标签批量映射成普通标签。适合一次性把一堆__meta_kubernetes_pod_label_*变成pod_label_*。hashmod按哈希取模分片。用于把抓取任务分散到多个Prometheus实例是做分片的关键。replace的默认行为要特别注意如果不写action默认就是replace如果不写target_label默认是替换__address__。这两个默认值坑过无数人。我建议永远显式写出action和target_label哪怕多打几个字也比debug时抓瞎强。4.3 一个完整的relabeling实战拆解来看一个真实场景Kubernetes里我想抓所有带特定注解的Pod把Pod的标签映射成指标标签并且只保留生产命名空间的。relabel_configs: # 1. 只保留带注解的 - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true # 2. 只保留prod命名空间 - source_labels: [__meta_kubernetes_namespace] action: keep regex: prod # 3. 把Pod标签映射成普通标签 - action: labelmap regex: __meta_kubernetes_pod_label_(.) # 4. 记录命名空间 - source_labels: [__meta_kubernetes_namespace] action: replace target_label: namespace # 5. 记录Pod名 - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: pod逐条解释第1、2条是过滤用keep把不符合的target直接扔掉第3条用labelmap把Pod上所有标签比如appnginx批量变成app标签第4、5条把命名空间和Pod名从元标签提升成正式标签。这里有个顺序问题过滤类action应该放在前面因为一旦被drop/keep掉后面的规则就不会执行了能省计算。而labelmap这种批量操作放在过滤之后避免对已经被丢弃的目标做无用功。注意labelmap的regex如果写得太宽可能把一堆你不需要的标签也映射进来导致指标标签爆炸。建议先用窄一点的regex确认效果后再放宽。5. 踩坑实录那些让我熬夜的服务发现故障5.1 元标签没转正指标上光秃秃这是我早期最常犯的错。配好了Kubernetes SDtarget也发现了抓取也成功了但一看指标除了job和instance啥标签都没有。原因就是我以为元标签会自动变成指标标签实际上它们全被清理了。排查方法很简单去Prometheus的/targets页面看如果target列表正常但Labels列很干净基本就是这个原因。解决就是补上replace或labelmap规则。这个坑的本质是没理解元标签的生命周期属于概念性错误踩一次就记住了。5.2 端口拼接错误导致抓取失败Kubernetes SD发现的__address__默认是PodIP:Port但这个Port往往是容器端口不一定是你exporter监听的端口。如果你不重写__address__Prometheus就会去抓一个错误的端口表现为target状态是down错误信息是connection refused。正确做法是从注解里读端口然后重写- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace target_label: __address__ regex: ([^:])(?::\d)?;(\d) replacement: $1:$2这个regex的意思是把__address__里的IP提取出来拼上注解里的端口。([^:])抓IP(?::\d)?匹配可能存在的旧端口并丢弃(\d)抓新端口。这种丢弃旧端口、拼接新端口的写法在K8s SD里几乎是标配建议直接背下来。5.3 服务发现刷新延迟引发的假故障有一次线上告警说某个服务失联我上去一看target列表里确实没有它。但手动curl那个地址是通的。折腾了十几分钟才反应过来那个服务是刚扩容的而文件SD的refresh_interval是5分钟还没到刷新时间。这个坑的教训是服务发现的延迟要纳入你的故障排查清单。当你确认目标本身没问题、但Prometheus就是没发现它时先想想刷新周期。生产环境里对于变化频繁的目标刷新周期要调小对于稳定的目标可以调大以减轻负担。5.4 relabeling规则顺序错误导致过滤失效relabeling规则是顺序执行的前一条的结果会影响后一条。我见过有人把labelmap放在keep前面结果labelmap先把元标签映射没了后面的keep找不到__meta_*标签过滤直接失效把所有目标都抓了进来。排查这类问题的技巧是在/targets页面看最终结果然后逐条注释掉规则二分定位是哪条规则出的问题。虽然笨但有效。更好的办法是用promtool check config先做语法检查再配合/targets做行为验证。6. 规模化场景下的服务发现优化思路6.1 用hashmod做抓取分片当目标数量大到单个Prometheus扛不住时需要多个实例分片抓取。hashmod就是干这个的relabel_configs: - source_labels: [__address__] modulus: 3 target_label: __tmp_hash action: hashmod - source_labels: [__tmp_hash] regex: 0 action: keep这段配置的意思是对__address__做哈希取模3结果存到临时标签__tmp_hash然后只保留结果为0的目标。这样三个Prometheus实例分别配regex: 0/1/2就能把目标均匀分片。注意__tmp_hash这种临时标签最后会被清理不会污染指标。分片的关键是哈希源要稳定。用__address__做哈希源只要地址不变分片结果就稳定。如果你用Pod名做哈希源Pod重建后名字变了分片就会漂移导致某些目标被重复抓或漏抓。6.2 减少元标签处理开销元标签越多relabeling的计算量越大。在目标规模上万时这个开销不可忽视。优化思路有两个一是在SD层面就过滤比如EC2的filters、K8s的namespace选择器减少进入relabeling的目标数二是精简labelmap的regex别用(.)这种全匹配。Kubernetes SD支持在配置里直接指定namespacekubernetes_sd_configs: - role: pod namespaces: names: [prod, staging]这样Prometheus只会去watch这两个命名空间的Pod从源头减少了数据量。比在relabeling里用keep过滤高效得多。6.3 服务发现配置的版本管理服务发现配置往往比静态配置复杂得多而且经常需要调整。我的建议是把prometheus.yml纳入Git管理每次改动走PR流程。原因很简单relabeling规则一旦写错可能导致大面积抓取失败有个版本记录能让你快速回滚。另外配置里尽量写注释说明每条relabeling规则的意图。我见过太多祖传配置没人知道某条规则为什么存在删了怕出事留着又冗余。注释是给未来的自己和同事留的后路。7. 我个人的几条实操建议服务发现这块配置写多了会发现它有一套自己的手感。分享几条我总结的经验都是踩坑换来的。第一调试时永远先看/targets页面。这个页面会显示每个target的发现状态、抓取状态、以及最终的标签。它是排查服务发现问题最直接的工具比看日志快得多。如果target压根没出现问题在SD配置如果出现了但状态是down问题在地址或网络如果up但标签不对问题在relabeling。第二善用Prometheus的配置热加载。改完配置后用curl -X POST http://localhost:9090/-/reload触发重载不用重启。但要注意热加载失败时Prometheus会保留旧配置并记录错误所以重载后一定要去日志里确认一下有没有报错。第三元标签先dump再写规则。不确定某个SD提供了哪些元标签时先写一条labelmap把所有__meta_*映射出来抓一次看结果确认标签名后再写精确的规则。这个先看后写的习惯能省掉大量试错。第四过滤规则宁严勿宽。服务发现最大的风险是抓多了——把不该抓的目标抓进来轻则浪费资源重则触发误告警。所以过滤条件尽量收紧确认没问题后再逐步放宽。反过来做先宽后严很容易在放宽期间引入问题。第五给服务发现配置留出可观测性。Prometheus自身有一些关于服务发现的指标比如prometheus_sd_discovered_targets、prometheus_sd_refresh_failures_total。把这些指标也监控起来能在服务发现出问题时第一时间发现。特别是refresh_failures_total它涨了就说明Prometheus拉取目标列表失败了往往意味着API权限、网络或配额出了问题。服务发现这套机制说到底就是让Prometheus自己找到该监控的东西。它的价值在规模小的时候体现不出来但一旦你的基础设施开始动态变化它就是刚需。把relabeling的逻辑理顺把元标签的生命周期搞清楚剩下的就是熟练度问题。多配几次多踩几个坑自然就通了。