Skip to content

Missing path pattern in Spring Framework 6 web Observability support #2212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bclozel opened this issue Jan 3, 2023 · 1 comment
Closed

Missing path pattern in Spring Framework 6 web Observability support #2212

bclozel opened this issue Jan 3, 2023 · 1 comment
Assignees
@odrotbohm
Labels
type: enhancement A general enhancement
Milestone
4.0.1 (2022.0.1)

Comments

@bclozel
Copy link
Member

bclozel commented Jan 3, 2023

As of Spring Boot 3.0, the Micrometer metrics support has been deprecated/removed in favor of broader observability support in Spring projects directly. In the case of Spring MVC and Spring WebFlux, specific filters (like ServerHttpObservationFilter) were created in Spring Framework 6.0.

The filters have been implemented in a generic fashion and do not rely on web frameworks specifics. This means that instead of looking into web frameworks internals to know which mapping pattern matched the incoming request, the framework itself needs to provide this information.

More concretely, in Spring Boot 2.x, WebMvcTags and WebFluxTags needed to know about Spring Data REST internals to pick up the matching pattern. With the new infrastructure, things should be done the other way around: Spring Data REST should get the current observation, if present, and set the matching path like this. I guess this should be done in RepositoryRestHandlerMapping and the reactive variant as well?

Sorry for not noticing this before, this has been reported in spring-projects/spring-boot#33673
@bclozel bclozel mentioned this issue Jan 3, 2023
Closed
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 3, 2023
@odrotbohm odrotbohm added this to the 4.0.1 (2022.0.1) milestone Jan 6, 2023
@odrotbohm odrotbohm self-assigned this Jan 6, 2023
@odrotbohm
Copy link
Member

It looks like the original arrangement (looking up a repository-specific pattern like /somRepo/{id} from a request attribute)stemmed from this ticket. Essentially, users were trying to gather metrics by "HTTP resources exposed per repository" rather than from the general pattern (/{repository}/…) which standard MVC-pattern-based metrics would resolve in. Thus, we need to register the same augmented pattern as path pattern on the ServerRequestObservationContext.

@mp911de mp911de added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 9, 2023
odrotbohm added a commit that referenced this issue Jan 9, 2023
@odrotbohm
Register per-repository pattern for observability purposes.
aa1685d 
The standard Spring MVC observability integration registers the plain request pattern for observations. For our repository controllers that would result in one pattern registered for all individual repository resources (e.g. /{repository}/{id} etc.). However, the insights users would like to gain rather follows the individual repositories exposed. That's why we have so far exposed repository specific path pattern (/myrepo/{id}) via a custom request attribute. To adhere to the new observability integration of Spring Framework 6, we need to expose that particular pattern on the ServerRequestObservationContext, too.

Fixes #2212.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@odrotbohm odrotbohm

Labels
type: enhancement A general enhancement
Projects
None yet
Milestone
4.0.1 (2022.0.1)
Development

No branches or pull requests
4 participants
@bclozel @odrotbohm @mp911de @spring-projects-issues