Prometheus relabel实现动态metrics path
内容提要
Prometheus的relabel功能可动态设置metrics路径，避免为不同路径编写多个job。通过将自定义标签（如_new_path）替换为__metrics_path__，实现单一job监控多个端点。该方案适用于静态配置和自动发现场景，简化配置管理。
延伸解读
relabel 顺序与覆盖规则
relabel 按配置顺序执行，后执行的规则会覆盖先执行的同名标签。在示例中，先通过 replace 将 __meta_consul_service_metadata_instance 写入 __address__，再将 service_name 写入 __metrics_path__，顺序不可颠倒，否则可能因标签不存在或值被覆盖导致抓取路径错误。理解这一顺序性有助于排查配置问题。
静态与动态场景的通用性
该方案在静态配置和自动发现（如 Consul）中均适用，核心思路一致：利用额外标签携带路径信息，再通过 relabel 映射到 __metrics_path__。静态配置中手动为每个 target 添加 _new_path 标签，动态发现中则依赖服务注册的元数据（如 service_name）。这种统一方法减少了重复 job 的维护成本，但需确保元数据标签存在且命名一致。
官方未支持路径的替代方案
Prometheus 官方未在 target 中直接支持路径（issue #1852），relabel 是社区常用的变通方法。该方案通过改写 __metrics_path__ 实现动态路径，但需注意：若目标路径包含特殊字符或正则元字符，需调整 regex 和 replacement 的转义；同时，relabel 仅影响抓取路径，不影响其他标签，若需保留原始路径信息，可额外保留 _new_path 标签。
Q&A
Prometheus如何实现动态metrics path？
通过relabel功能，将自定义标签（如_new_path）的值替换到__metrics_path__标签中，从而动态设置每个target的metrics路径，避免为不同路径编写多个job。
为什么需要动态metrics path？
因为Prometheus的target字段只能指定主机和端口，不能包含路径。当多个服务暴露在不同路径（如/payment-service/metrics、/order-service/metrics）时，通常需要为每个路径配置单独的job，配置繁琐。动态metrics path可以简化配置。
在静态配置下如何使用relabel实现动态metrics path？
在static_configs中为每个target添加自定义标签（如_new_path），然后在relabel_configs中使用replace动作，将_new_path的值替换到__metrics_path__标签，并加上前缀/metrics/。例如：source_labels: [_new_path], regex: (.*), target_label: __metrics_path__, replacement: /metrics/$1。
在自动发现场景（如Consul）下如何利用relabel实现动态metrics path？
在自动发现场景中，可以通过relabel将服务发现元数据中的标签（如__meta_consul_service_metadata_service_name）的值直接替换到__metrics_path__，从而动态设置metrics路径，无需额外添加标签。
Prometheus官方是否支持在target中直接指定路径？
不支持。Prometheus的target字段只能指定主机和端口，不能包含路径。官方仓库有相关issue（#1852）提出需求，但未被通过。
relabel在Prometheus抓取过程中起什么作用？
relabel可以在目标被抓取之前重写其标签，每个采集配置可以配置多个relabel，并按照顺序应用于每个target的标签。利用这一特性，可以动态修改__metrics_path__等内部标签。
