Spring Boot 3.x结合Prometheus使用百分位数直方图时，如何避免高基数问题并配置实用的请求延迟桶？

我完全懂你的困扰——从Spring Boot 1自己撸监控逻辑，升级到3.x后想拥抱原生Metrics能力，结果默认的请求延迟桶配置直接把基数拉满，一堆没必要的细粒度桶占资源，看着都头疼。结合你提到的场景（用Prometheus+Grafana监控REST请求，核心需求是看超过1秒的请求占比），我给你梳理一套精准的解决方案：

先搞懂问题根源 #

你之前的配置踩了两个小坑：

1. 开启percentiles-histogram后，Micrometer默认会生成73个指数型分布的桶，再乘上exception、status等标签，基数直接爆炸；
2. 你配置了SLO但没关闭默认的百分位数直方图逻辑，导致自定义SLO和默认桶被合并，还是会生成一堆没用的小阈值桶（比如0.001s那种）。

精准配置：自定义桶+压减基数 #

1. 核心配置：替代默认桶，完全自定义SLO #

把以下配置放到你的application.properties（或yaml）里，完全抛弃默认的细粒度桶，只保留你关心的延迟阈值：

# 开启基于SLO的直方图（替代默认的百分位数直方图）
management.metrics.distribution.histogram.http.server.requests=true
# 定义你需要的延迟阈值，完全贴合业务需求
management.metrics.distribution.slo.http.server.requests=100ms,500ms,1s,3s
# 关闭默认的百分位数直方图，彻底避免生成多余桶
management.metrics.distribution.percentiles-histogram.http.server.requests=false
# 可选：关闭不需要的百分位数统计（如果不需要计算P95/P99这类值）
management.metrics.distribution.percentiles.http.server.requests=

这样配置后，每个请求端点只会生成你定义的SLO数量+1个桶（最后一个是le="+Inf"的总请求桶），比如你定义4个阈值，就只会有5个桶，基数直接砍到原来的1/15都不到。

2. 进一步压减标签基数 #

你提到exception标签会放大基数，这是个高频痛点，两个实用的优化方式：

• 异常标签分组：用自定义MeterFilter把具体异常类映射为通用分组，比如把所有业务异常统一标为business_exception，系统异常标为system_exception，而不是用全类名：

@Bean
public MeterFilter exceptionGroupingMeterFilter() {
    return new MeterFilter() {
        @Override
        public Meter.Id map(Meter.Id id) {
            if ("http.server.requests".equals(id.getName())) {
                Tag exceptionTag = id.getTags().stream()
                        .filter(tag -> "exception".equals(tag.getKey()))
                        .findFirst()
                        .orElse(null);
                if (exceptionTag != null && !"none".equals(exceptionTag.getValue())) {
                    // 按业务/系统异常分组，可根据你的实际包名调整
                    String groupedException = exceptionTag.getValue().startsWith("com.yourcompany.business")
                            ? "business_exception"
                            : "system_exception";
                    return id.withTags(id.getTags().and(Tag.of("exception", groupedException)));
                }
            }
            return id;
        }
    };
}

• URI标签规范化：确保Spring Boot自动把动态参数的URI替换为模板（比如/api/users/123变成/api/users/{id}），默认是开启的，若没生效检查这个配置：

management.metrics.web.server.auto-time-requests=true

验证配置效果 #

配置完成后，你访问端点后在Prometheus端点看到的metrics会变成这样（简洁很多）：

http_server_requests_seconds_bucket{error="none",exception="none",method="PUT",outcome="SUCCESS",status="200",uri="/my/uri",le="0.1"} 0
http_server_requests_seconds_bucket{error="none",exception="none",method="PUT",outcome="SUCCESS",status="200",uri="/my/uri",le="0.5"} 0
http_server_requests_seconds_bucket{error="none",exception="none",method="PUT",outcome="SUCCESS",status="200",uri="/my/uri",le="1.0"} 0
http_server_requests_seconds_bucket{error="none",exception="none",method="PUT",outcome="SUCCESS",status="200",uri="/my/uri",le="3.0"} 0
http_server_requests_seconds_bucket{error="none",exception="none",method="PUT",outcome="SUCCESS",status="200",uri="/my/uri",le="+Inf"} 1

核心需求实现：计算超过1秒的请求占比 #

在Grafana里用这个PromQL就能得到每个URI的请求中，延迟超过1秒的百分比：

sum by (uri) (rate(http_server_requests_seconds_bucket{le="+Inf"}[5m])) 
  - sum by (uri) (rate(http_server_requests_seconds_bucket{le="1.0"}[5m]))
/ sum by (uri) (rate(http_server_requests_seconds_bucket{le="+Inf"}[5m]))
* 100

如果要按方法、状态码等维度过滤，直接在PromQL里加标签条件即可。

额外注意点 #

• 你的Spring Boot 3.3.1完全支持这些配置：Micrometer 1.12+（对应Spring Boot 3.3.x）对Metrics配置做了更清晰的拆分，histogram和percentiles-histogram是分开的，不会混淆；
• 若需要计算P95/P99这类百分位数，不要关闭percentiles配置，但可以只定义你需要的百分位数（比如management.metrics.distribution.percentiles.http.server.requests=0.95,0.99），避免生成多余的统计量。

内容来源于stack exchange