Skip to content

HTTP client observations miss uri keyvalue for "/" requests #29879

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.

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

Closed
angelasindic opened this issue Jan 24, 2023 · 2 comments
Closed

HTTP client observations miss uri keyvalue for "/" requests #29879

angelasindic opened this issue Jan 24, 2023 · 2 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) theme: observability An issue related to observability and tracing type: bug A general bug
Milestone

Comments

@angelasindic
Copy link

Affects: Spring Framework 6.0.4

Problem

After upgrading including webflux version 6.0.4, the URI tag from the http.client.requests metrics are always none when making web client calls.

After the web client is called several times, the output from the metrics/http.client.request endpoint looks like this

Screenshot 2023-01-24 at 11 42 00

Steps to reproduce

  1. Create a Srping Boot 3.0.2 application with reactive web.
  2. Add org.springframework.boot:spring-boot-starter-actuator and io.micrometer:micrometer-registry-prometheus dependencies.
  3. Create a simple get endpoint that calls a webclient and perform several get requests.
  4. Check the metrics/http.client.request endpoint, look at the uri tag that has value "none"

I created a simple demo project to reproduce the issue here.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 24, 2023
@bclozel
Copy link
Member

bclozel commented Jan 24, 2023

The behavior changed there to only record the uri key value if a uri template is being used to avoid cardinality explosion.

Let me check with your sample.

@bclozel bclozel added the status: waiting-for-feedback We need additional information before we can continue label Jan 24, 2023
@bclozel bclozel self-assigned this Jan 24, 2023
@bclozel bclozel added type: bug A general bug theme: observability An issue related to observability and tracing in: web Issues in web modules (web, webmvc, webflux, websocket) and removed status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 24, 2023
@bclozel bclozel added this to the 6.0.5 milestone Jan 26, 2023
@bclozel bclozel changed the title Spring http.client.requests metrics uri tag value is not set when making web client calls HTTP client observations miss uri keyvalue for "/" requests Jan 26, 2023
@bclozel
Copy link
Member

bclozel commented Jan 27, 2023

I think this can be summarized with the following call:

WebClient client = WebClient.builder()
    .observationRegistry(registry)
    .baseUrl("https://example.org/")
    .build();

String response = client.get().retrieve().bodyToMono(String.class).block();

In this case, the client call doesn't use the uri(String uri, Object... uriVariables) method, so no URI template is being used. This behavior is consistent with the client usage. Using the following code snippet instead should make the uri tag available:

WebClient client = WebClient.builder()
    .observationRegistry(registry)
    .baseUrl("https://example.org")
    .build();

String response = client.get().uri("/").retrieve().bodyToMono(String.class).block();

Requiring developers to switch to this variant for this case doesn't make sense, so we should add a special case for "/" templates and record them as KeyValue no matter how they were produced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) theme: observability An issue related to observability and tracing type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants