DefaultJerseyTagsProvider clashes with WebMvcObservationAutoConfiguration

[bergerdenes]

When using Jersey (not Spring) annotated endpoints and also using Micrometer Prometheus integration, the "prometheus" actuator endpoint shows "UNKNOWN" in the uri instead of the path pattern.

ServerHttpObservationFilter does not fill pathPattern.
In the org.springframework.http.server.observation.DefaultServerRequestObservationConvention class, the protected KeyValue uri(ServerRequestObservationContext context) method tries to get context.getPathPattern() but it is always null.

Reproduction sample project with instructions: https://github.com/bergerdenes/metrics-repro

The suggested workaround, @SpringBootApplication(exclude=WebMvcObservationAutoConfiguration.class) annotation solves the issue.

Details are at spring-projects/spring-framework#32099 (I was redirected from there)

[bclozel]

I think we can summarize the situation as follows: when Spring Boot auto-configures an application with 'org.springframework.boot:spring-boot-starter-actuator' as well as both 'org.springframework.boot:spring-boot-starter-jersey' and 'org.springframework.boot:spring-boot-starter-web' on the classpath, both Spring MVC and Jersey HTTP instrumentations are contributed as well.

Each instrumentation contributes the same metric name, which can cause conflicts like described in the linked issue.

I think we can consider several solutions:

• call this out as a limitation in the documentation, as having both Jersey and Spring MVC in the same application might not be common?
• update the auto-configurations to ensure that we don't contribute the Spring MVC observation fitter if the Jersey instrumentation is auto-configured

[bergerdenes]

The only problem with @SpringBootApplication(exclude=WebMvcObservationAutoConfiguration.class) is that in this case, we cannot obtain metrics from the Spring actuator endpoints (i.e. /info, /health, etc.)

[bclozel]

Here two competing systems are trying to contribute to the same metric. Have you considered renaming one of the observations to separate both? You can use actuator.management.observations.http.server.requests.name to rename the server observations.

[bergerdenes]

Can you please elaborate what you mean? You may open a branch from my repro project (or open a PR)

[bclozel]

I mean doing the following in application.properties:

actuator.management.observations.http.server.requests.name=spring.http.server.requests

This will rename the HTTP server observations for Spring and leave the http.server.requests namespace for the Jersey variant.

[bergerdenes]

The suggestion does not help at all. It keeps the URI properties UNKNOWN.
I tried setting the same for management.observations.http.server.requests.name but in that case the metrics actuator does not return anyting.

[bclozel]

Sorry I forgot that the Jersey metrics would also follow the same property. I guess the only choice here is to disable the MVC instrumentation and only rely on the Jersey one.

[bclozel]

We have discussed this as a team and think that there are several ways to fix this.

Remove the MVC starter as it's not used

First, if your application does not need Spring MVC then the org.springframework.boot:spring-boot-starter-web dependency should be removed, and you could then map Jersey to the base / path:

@ApplicationPath("/")
@Configuration
public class EndpointConfig extends ResourceConfig {

and adapt the application configuration as a result:

management:
  endpoints:
    web:
      base-path: "/"
      exposure:
        include: info,health,prometheus
      path-mapping:
        prometheus: metrics

I've checked that all requests are being instrumented as expected.

Configure the MVC Observation filter

If your application needs both Jersey and MVC, manually configuring the Observation Filter makes sense: Spring Boot won't necessarily know which paths your application intends to use with MVC or Jersey and which instrumentation should prevail in each case. Something like:

    @Bean
    public FilterRegistrationBean<ServerHttpObservationFilter> webMvcObservationFilter(ObservationRegistry registry) {
        ServerHttpObservationFilter filter = new ServerHttpObservationFilter(registry);
        FilterRegistrationBean<ServerHttpObservationFilter> registration = new FilterRegistrationBean<>(filter);
        registration.setOrder(Ordered.HIGHEST_PRECEDENCE + 1);
        registration.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ASYNC);
        registration.addUrlPatterns("/mvc/*");
        return registration;
    }

In light of that, I'm closing this issue as we don't think we can make auto-configurations depend on each other and deduce what's expected for the application.

Thanks!