如何将Spring Boot Actuator与Micrometer数据合并到单个端点？

根据你的场景，核心需求是统一指标端点，同时兼容两种指标命名规则（Actuator的mem等 vs Micrometer的jvm_memory等）。下面是几个实操性强的方案，按推荐优先级排序：

方案1：配置Micrometer输出Actuator风格的指标名（推荐） #

这是最直接的方案，不需要额外服务，只需调整现有使用Micrometer的应用配置，让它们输出与Actuator一致的指标名。这样所有应用都可以通过/prometheus端点暴露指标，云服务商只需拉取这一个端点，且Grafana中适配Actuator的仪表盘直接可用，少数适配Micrometer的仪表盘也能通过保留原名称兼容。

具体配置方式 #

方式A：通过YAML配置命名规则

在使用Micrometer的应用的application.yml中添加指标重命名规则：

management:
  metrics:
    naming:
      rules:
        # 将Micrometer的jvm_memory_*映射为Actuator的mem_*
        - pattern: 'jvm_memory_usage_(.*)'
          name: 'mem_$1'
        # 将jvm_threads_*映射为threads_*
        - pattern: 'jvm_threads_(.*)'
          name: 'threads_$1'
        # 按需添加其他指标的映射规则，比如CPU、磁盘等
        - pattern: 'system_cpu_usage'
          name: 'cpu'
        - pattern: 'disk_free'
          name: 'free_disk_space'

方式B：通过Java代码自定义命名策略

如果需要更灵活的逻辑（比如根据标签动态重命名），可以编写配置类：

import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.config.MeterFilter;
import org.springframework.boot.actuate.autoconfigure.metrics.MeterRegistryCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class MicrometerNamingConfig {
    @Bean
    public MeterRegistryCustomizer<MeterRegistry> metricsRenameCustomizer() {
        return registry -> registry.config()
                .meterFilter(MeterFilter.renameMeter(name -> {
                    // 映射Micrometer指标名到Actuator风格，未匹配的保留原名称
                    return switch (name) {
                        case "jvm_memory_usage_max" -> "mem_max";
                        case "jvm_memory_usage_used" -> "mem_used";
                        case "jvm_threads_live" -> "threads_live";
                        case "system_cpu_usage" -> "cpu";
                        default -> name;
                    };
                }));
    }
}

优势 #

• 无需额外运维成本，直接复用现有Micrometer端点
• 完全兼容多数Actuator风格的Grafana仪表盘
• 未映射的指标保留原名称，适配少数Micrometer风格仪表盘

方案2：搭建中间代理服务聚合指标 #

如果不想修改现有应用的配置，可以搭建一个轻量级的Spring Boot代理服务，负责：

1. 分别调用目标应用的/metrics（Actuator）和/prometheus（Micrometer）端点
2. 将/metrics的JSON格式指标转换为Prometheus文本格式
3. 合并两种格式的指标（可选择性重命名指标名以兼容两种仪表盘）
4. 暴露一个统一的端点（比如/unified-metrics）供云服务商拉取

核心实现思路 #

• 使用RestTemplate或WebClient获取两个端点的指标数据
• 编写转换器将Actuator的JSON指标（比如{"mem": 12345}）转换为Prometheus格式（mem 12345）
• 合并转换后的Actuator指标和Micrometer的Prometheus指标，可添加应用标签区分来源
• 暴露一个@GetMapping("/unified-metrics")接口返回合并后的文本

优势 #

• 完全不侵入原有应用，适合无法修改应用配置的场景
• 可以灵活控制指标的合并、重命名和过滤逻辑

劣势 #

• 需要额外维护一个代理服务，增加运维复杂度

方案3：Grafana层面适配（补充方案） #

如果上述方案都无法实施，可以在Grafana中通过变量或查询重写来兼容两种指标名：

• 创建Grafana变量（比如$metric_prefix），允许用户选择mem或jvm_memory
• 使用Grafana的查询重写功能，自动替换指标名（比如将mem_*替换为jvm_memory_*，反之亦然）

劣势 #

• 需要修改每个Grafana仪表盘的查询逻辑，维护成本较高
• 无法实现单一端点拉取，可能不符合云服务商的限制

关于你的疑问：是否可配置Micrometer以/metrics为数据源？ #

不需要直接将/metrics作为Micrometer的数据源，因为Micrometer本身就是Spring Boot 2.x+推荐的指标库，Actuator的/metrics端点底层也是基于Micrometer实现的。通过方案1的配置，让Micrometer输出Actuator风格的指标名，就相当于把Micrometer的端点变成了兼容Actuator的统一指标源。

内容的提问来源于stack exchange，提问作者Joe Zitzelberger