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

Bean in question:

https://github.com/spring-projects/spring-boot/blob/d4c7315369e7e9dce6eb1c77e5f23d1e670247c8/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/metrics/web/servlet/WebMvcMetricsAutoConfiguration.java#L99-L103

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.

Comment From: 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 */);
    }

}

Comment From: 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?

Comment From: 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.

Comment From: 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?

Comment From: berngp

Hi @wilkinsona , let me try to express the situation. In this case @josefhernandez has an app and he is using a platform library. On one side the library adds tags that relate with the region, environment, and other information related with the deployment. On the other side @josefhernandez wants to add additional tags specific to his application without overriding the ones provided by the library. The library could introduce new abstractions and have the contribution model that you express but we are thinking that is better to support it within Spring.

Comment From: berngp

If we are concerned of keeping DefaultWebMvcTagsProvider backward compatible we could introduce an AdditiveWebMvcTagsProvider that supports an ordered list of WebMvcTagsContributor's. The library could add a WebMvcTagsContributor with a high precedence while the application can create its own.

Comment From: mbhave

Thanks for the additional context @berngp. The issue has been triaged and is assigned to the 2.3.x milestone which means that we are considering adding support for this in Spring Boot itself. As @wilkinsona mentioned above, we're going to give the contributor approach a try. This should allow both the library and app to contribute tags that the DefaultWebMvcTagsProvider can use.

Comment From: wilkinsona

An implementation of the MVC side of this is available in this branch. We'd need to do something similar for WebFlux.