Property management.metrics.web.server.auto-time-requests is not taken into account in case of reactive web application

[EdgarsM]

In current Spring Boot version (2.0.3.RELEASE) configuration property management.metrics.web.server.auto-time-requests is not taken into account so it is not possible to disable automatic incoming HTTP request timing. It might be an issue if web application acts as a proxy (e.g. as in case of spring-cloud-gateway) and request URIs contain variables that are not replaced by placeholders. As a result metrics get accumulated (because there are separate metric instead of single one containing variable placeholder just as in case of Spring controllers) until OutOfMemoryError occurs.
Current workaround is to exclude org.springframework.boot.actuate.autoconfigure.metrics.web.reactive.WebFluxMetricsAutoConfiguration auto configuration.
Disabling auto request timing in case of reactive web application should work same as in case of servlet based web application (WebMvcMetricsAutoConfiguration).

[jkschneider]

Cross-posting from the related s-c-gateway issue:

We can introduce a MeterFilter#maximumAllowableTags for this metric much like we do for RestTemplate metrics where we can't guarantee that folks don't incorrectly use RestTemplate with path variable substitution.

If you'd like, you can create a variation on this that does something else like logging periodically when the maximum is reached and pointing folks to probably the better solution which is to use their domain knowledge of the structure of their URIs to construct a MeterFilter that rewrites tag values to reduce cardinality.

[philwebb]

Thanks @jkschneider, that sounds like a nice addition but I think we should also make WebFluxMetricsAutoConfiguration respect the management.metrics.web.server.auto-time-requests flag. I'll keep this issue for that bug and raise a new one to support MeterFilter#maximumAllowableTags

[bclozel]

Also, see #12757

[wilkinsona]

We don't do anything with @Timed annotations in MetricsWebFilter at the moment so honouring management.metrics.web.server.auto-time-requests would have pretty much the same effect as disabling the auto-configuration. The effect wouldn't be exactly the same as the filter would still be there, it just wouldn't do anything. I'm a bit torn on this one. On the one hand, honouring the auto-time-requests property means that the intent would be very clear. On the other hand, disabling the auto-configuration is better as it gets rid of the filter entirely. Perhaps MetricsWebFilter really ought to honour @Timed annotations in the WebFlux (not WebFlux.Fn) case ?

[jkschneider]

@wilkinsona Up for consideration soon is how we could better support @Timed on arbitrary methods in Spring without using AOP. There may be some overlap.