Allow tags to be added to those provided by default for WebMVC and WebFlux

[jfernandez]

Bean in question:

spring-boot/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/metrics/web/servlet/WebMvcMetricsAutoConfiguration.java

Lines 99 to 103 in d4c7315

	@Bean
	public MetricsWebMvcConfigurer metricsWebMvcConfigurer(MeterRegistry meterRegistry,
	WebMvcTagsProvider tagsProvider) {
	return new MetricsWebMvcConfigurer(meterRegistry, tagsProvider);
	}

We've ran into several use-cases where a Springboot apps want to add additional tags on top of the default ones we provide. Making this bean take a list of WebMvcTagsProviders would enable that.

[wilkinsona]

Thanks for the suggestion. Have you considered writing your own WebMvcTagsProvider that delegates to DefaultWebMvcTagsProvider? It would look something like this:

class CustomWebMvcTagsProvider implements WebMvcTagsProvider {

	private final WebMvcTagsProvider delegate = new DefaultWebMvcTagsProvider();

	@Override
	public Iterable<Tag> getTags(HttpServletRequest request, HttpServletResponse response, Object handler,
			Throwable exception) {
		return Tags.of(this.delegate.getTags(request, response, handler, exception))
				.and(/* additional tags */);
	}

	@Override
	public Iterable<Tag> getLongRequestTags(HttpServletRequest request, Object handler) {
		return Tags.of(this.delegate.getLongRequestTags(request, handler))
				.and(/* additional tags */);
	}

}

[jfernandez]

@wilkinsona Yes, a delegate pattern would work, but as one of Spring’s core tenets is extensibility I think the code for that is best suited to be in Spring Boot itself. Would you accept a PR for adding this delegate pattern to Spring Boot?

[wilkinsona]

I don't think we can drop something like that straight in due to the way the auto-configuration works. A slightly modified approach might be possible though.

As things stand, we auto-configure an instance of DefaultWebMvcTagsProvider and it backs off when there is a user-provided WebMvcTagsProvider bean. If we left this as-is and changed metricsWebMvcConfigurer to consume List<WebMvcTagsProvider> you'd then have to define two beans: a DefaultWebMvcTagsProvider and your own WebMvcTagsProvider implementation. Defining two beans would be necessary as we can't change the auto-configuration of DefaultWebMvcTagsProvider so that it doesn't back of when there's a user-provided WebMvcTagsProvider. If we did so, it would break existing applications that rely upon replacing the existing tags.

One possibility would be to introduce a new interface, something like WebMvcTagsContributor. We could then update DefaultWebMvcTagsProvider in a backwards-compatible manner to take a List<WebMvcTagsContributor> and delegate to them. By default, there would be no WebMvcTagsContributor beans, but you could provide one or more to add to the default tags.

I'll flag this one for team attention to see what the rest of the team thinks of this approach.

[wilkinsona]

@jfernandez We're going to explore the contributor approach. Out of interest, can you share with us some details of the sorts of tags that you want to be able to add?