-
Couldn't load subscription status.
- Fork 41.6k
Description
#11843 applies MeterFilter beans, but the user cannot control the order in which the MeterFilters are applied, which may matter depending on what all the MeterFilters do.
For instance, I would like to turn on percentile histograms for my application's endpoints, but I want them off for all Actuator endpoints and unmapped requests because this adds ~70 time series for each endpoint per instance (and per status/exception!). My initial thought was to use the property management.metrics.distribution.percentiles-histogram like below.
management:
metrics:
distribution:
percentiles-histogram:
http.server.requests: trueThen I would only need to make a MeterFilter to turn this off if the uri tag seemed like an Actuator request (since there isn't a more direct way to do this without #13435) or unmapped request:
@Bean
MeterFilter noActuatorHistogramsFilter() {
return new MeterFilter() {
@Override
public DistributionStatisticConfig configure(Meter.Id id, DistributionStatisticConfig config) {
if ("http.server.requests".equals(id.getName()) && id.getTag("uri") != null && (id.getTag("uri").contains("actuator") || id.getTag("uri").equals("/**"))) {
return DistributionStatisticConfig.builder()
.percentilesHistogram(false)
.build()
.merge(config);
}
return config;
}
};
}Looking at the MetricsAutoConfiguration class and seeing that the PropertiesMeterFilter has an @Order(0), I thought my custom MeterFilter bean would be applied after it, but this was not the case.
Lines 57 to 61 in a170bfc
| @Bean | |
| @Order(0) | |
| public PropertiesMeterFilter propertiesMeterFilter(MetricsProperties properties) { | |
| return new PropertiesMeterFilter(properties); | |
| } |
The way I can work around this is to not use the property-based meter filter at all and just put all the logic I want in my own MeterFilter, but I think being able to control of the order of MeterFilter is a generally good idea regardless of this specific use-case.