The WebMvcMetricsFilter uses the HandlerMapping.BEST_MATCHING_HANDLER_ATTRIBUTE to determine which handler the metric should be labeled with.
Since useTrailingSlashMatch is true by default most mvc controllers configured with a request mapping like:
@GetMapping(path = "/foo", produces = {MediaType.APPLICATION_JSON_VALUE})
will match both /foo and /foo/ and as a result BEST_MATCHING_HANDLER_ATTRIBUTE for this request mapping can have 2 values.
This leads to split metrics for the same request mapping: one for /foo and one for /foo/.
For now I have worked around this with a MeterRegistryCustomizer that strips the trailing slash, but I wonder if this does not deserve a more structural solution, e.g inside the metrics filter itself.
Comment From: philwebb
@rswart Thanks for the report. I've transferred this issue to the Spring Framework team to see if they can deal with this when setting the BEST_MATCHING_HANDLER_ATTRIBUTE value. I think that might be the best solution since it will fix any other applications that rely on the attribute.
Comment From: rstoyanchev
will match both /foo and /foo/ and as a result BEST_MATCHING_HANDLER_ATTRIBUTE for this request mapping can have 2 values
I'm probably missing something. The attribute reflects the matched handler. Shouldn't that be the same in both cases?
Comment From: philwebb
@rswart Did you mean HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE? I think that's the attribute that we use to add the uri tag. See WebMvcTags.
Comment From: rswart
Yes, apologies. I didn't look into it deeply enough.
So apparently 2 patterns are created for the same handler when useTrailingSlashMatch is true leading to 2 separate metrics in micrometer.
Comment From: rstoyanchev
The BEST_MATCHING_HANDLER_ATTRIBUTE correctly reflects the pattern used to match the handler. There is no promise that it will present a unique value that is insensitive to trailing slashes.
I am quite certain that what is a "fix" for some will cause regression for others. A valid counter-argument would be that it's better to present the complete information, and the trailing slash can then be easily filtered out or ignored. I think it would make more sense for a metrics filter to decide whether to strip trailing slashes or not, possibly making that configurable.
Comment From: rstoyanchev
I am closing this from a Spring Framework perspective, but feel free to re-open and transfer back to Spring Boot if that makes sense.
Comment From: bclozel
The team decided to strip trailing slashes in our metrics filter, but still offer a configuration property in case trailing slashes are meaningful for some applications.