Unexplainable "root" uri in spring boot prometheus metrics

user_12789957 0
Viewed 1017

In our Prometheus metrics in our Spring Boot API, there is a very mysterious root "endpoint" that appears to be called sometimes. This looks like someone probing our API, but the endpoint does not exist. The really strange part is that I don't see how this "URI" can even be called, since it doesn't start with a forward slash (/) ? We also see this request in our pod logs, but not in our ingress-controller logs. Where could it come from? "root" - status 403

prometheus spring-boot-actuator spring-boot
2 Answers

I ran into the same issue with a lot of head scratching. It turns out in my case, @Timing annotations were attached to all of my rest controllers which quietly overrode the default http metrics provided from actuator.

user_28985350

From WebMvcTags always reports "root" as uri when servlet Filter handles the request #17147

In a Spring-MVC Boot app, http.server.requests metrics are always reported with a root uri if the request, which would be mapped to Spring-MVC controller under normal circumstances, is handled by a servlet Filter instead. This happens for example when using Spring Security.
The reason is that the WebMvcTags uses the path info of the request in these situations, which is always null because the DispatcherServlet is mapped as a default servlet: the whole path is then present in the servlet path instead.

The answer from the Spring Boot Team:

The team has discussed this again, and we don't think we can address that problem.

  • as explained, taking the servlet path from the request would create an explosion of metrics
  • other paths (like a Filter mapping path) won't be useful
  • we won't call in the MVC infrastructure to map that request, as it creates security concerns and can be quite involved (CORS support, interceptors)

Also, getting the Controller mapping would not really help. If a request is really slow and the Filter processing the request is at fault, we would report the Controller path pattern and confuse developers about the misbehaving parts of their applications. Maybe the Servlet filter name would be more useful here, but there's no way to get that in the filter chain, and that information would not really map to a uri tag.

As a result, we're closing this issue.

user_4791590
Related