Micrometer: URI tag of http.server.requests meter contains templated URI

[edeandrea]

Seems that when looking at the http.server.requests metric of a Spring Boot/Spring MVC application the URI tag has the value of a templated URI and not the actual expanded URI.

For example, my controller is annotated with @RequestMapping("/things") and my action method has @GetMapping(path = "/{id}"), when looking at the output of the meter I see

Meter: name = http.server.requests, description = null, type = TIMER, tags = [ImmutableTag{key='exception', value='None'}, ImmutableTag{key='method', value='GET'}, ImmutableTag{key='status', value='200'}, ImmutableTag{key='uri', value='/things/{id}'}], measurements = [Measurement{statistic='COUNT', value=3.0}, Measurement{statistic='TOTAL_TIME', value=939.321339}, Measurement{statistic='MAX', value=923.181765}]

I was expecting to see

Meter: name = http.server.requests, description = null, type = TIMER, tags = [ImmutableTag{key='exception', value='None'}, ImmutableTag{key='method', value='GET'}, ImmutableTag{key='status', value='200'}, ImmutableTag{key='uri', value='/things/1'}], measurements = [Measurement{statistic='COUNT', value=3.0}, Measurement{statistic='TOTAL_TIME', value=939.321339}, Measurement{statistic='MAX', value=923.181765}]

Is this by design? I see it similarly on the RestTemplate customization with the http.client.requests metric where if I make an outbound REST call to /somewhereElse/{id} the URI is also template-ized there.

[jkschneider]

Absolutely intentional. This way you can plot latency against that endpoint and not the endpoint _given_ some particular parameters.

Shipping a resolved URI would explode the total number of tags at the monitoring system and can overwhelm the backend.

[paulosuzart]

Is there any plan to add the path parameters as part of the tags? This could be disabled by default and enabled if needed. This would avoid creating Timers by hand based on path parameter.

Of course it would be of developer responsibility to provide mechanisms to avoid an explosion of tag values on metrics system. But yet something in our scenario relevante to have.

[mweirauch]

@paulosuzart Ship your own WebMvcTagsProvider in this case. You can reuse stuff from the DefaultWebMvcTagsProvider and WebMvcTags.