Instrument WebFlux.fn to record the URI pattern tag on http.server.requests metric

[wilkinsona]

@dharezlak raised this on Gitter. The problem is that, when using WebFlux.fn, the best matching pattern attribute isn't set. This causes MetricsWebFilter to create a unique URI tag for every unique URI rather than creating one tag per pattern.

@bclozel suspects that it won't be possible to set the best matching pattern attribute in the WebFlux.fn case, so we probably need to explore making the tagging smarter somehow.

[philwebb]

/cc @jkschneider

[bclozel]

At the framework level, we could use the request predicates to store the path pattern information as a request attribute; this would still require to properly invalidate that information if a predicate doesn't match (see SPR-16692 for a related issue).

Now, even if we manage to add that information as a request attribute, we could still run into cases like this:

@Bean
public RouterFunction router(TestHandler myHandler) {
	return RouterFunctions.route(method(HttpMethod.GET), myHandler::handle);
}

This router will route any GET request to the given handler.

Maybe we should change the WebFluxTags implementation and only add a "uri" tag if we fetch the pattern information (i.e. never use the actual request path for that)? If we do this, we'd lose information but avoid cardinality explosion. @jkschneider, do you see another way to avoid such cases?

[jkschneider]

this would still require to properly invalidate that information if a predicate doesn't match (see SPR-16692 for a related issue).

We have special treatment for 404's where we map the path to NOT_FOUND so as not to blow up tag cardinality. Is this workable here too?

[bclozel]

Technically, many of those requests would be handled still, so I don't think NOT_FOUND would be a proper way to tag them (the associated responses would not be HTTP 404).

Can we consider no uri tag an empty "" tag?

[jkschneider]

They would be handled because they are static resources?

[bclozel]

Right now, WebFlux.fn does not provide us with the path pattern information; let's say this feature is added in Spring Framework. Even if it is, consider now the following example:

@Bean
public RouterFunction router(TestHandler myHandler) {
	return RouterFunctions.route(method(HttpMethod.GET), myHandler::handle);
}

This RouterFunction matches and handles requests without ever considering the request uri. We're just handling all GET requests. In that case, NOT_FOUND is not really applicable since the request has been handled. If we use the request path for the uri tag, tag cardinality might be an issue.

This is why I'm asking if an empty (or no uri tag at all) can/should be considered.

[jkschneider]

I kind of feel like the path pattern should be something like /* for that example?

For nested resources like this, something like /people/{id}/*?

cc / @adriancole

[bclozel]

See SPR-17098