In Spring Boot 3, http.client.requests metrics no longer contain the client.name meter tag. We rely on this in our dashboards to graph requests to other services. This value is being included in the client observation as a high cardinality tag which only gets contributed to traces.

We use domain names when calling other services, so the cardinality of this tag isn't large. I can appreciate the decision to make it a high cardinality tag especially if one was using client side load balancing where the host is an IP address.

If this is the new default, it would be great if an application could opt-in to the previous behavior of having client.name included in metrics.

As it is now in Spring Boot 3.0.2, in order to maintain the behavior present in Spring Boot 2, we have tried registering our own ObservationFilter and publish client.name as a low cardinality value. I'm not completely confident this is the right approach or whether having the client.name key value in both low and high cardinality categories will cause a problem. I also have to duplicate inaccessible code in DefaultClientRequestObservationConvention.

  static final KeyValue CLIENT_NAME_NONE =
    KeyValue.of(ClientHttpObservationDocumentation.HighCardinalityKeyNames.CLIENT_NAME, KeyValue.NONE_VALUE);

  @Bean
  public ObservationFilter lowCardinalityClientNameObservationFilter() {
    return context -> {
      if (context instanceof ClientRequestObservationContext clientContext) {
        KeyValue keyValue = null;
        if (clientContext.getCarrier() != null && clientContext.getCarrier().getURI().getHost() != null) {
          keyValue = KeyValue.of(ClientHttpObservationDocumentation.HighCardinalityKeyNames.CLIENT_NAME, 
                                 clientContext.getCarrier().getURI().getHost());
        }

        // adding client name as a low cardinality value since we use a small finite set of domain names
        clientContext.addLowCardinalityKeyValue(requireNonNullElse(keyValue, CLIENT_NAME_NONE));

      }
      return context;
    };
  }

Another alternative would be to extend the DefaultClientRequestObservationConvention, but this is not ideal as we would want to provide this across our organization in our shared application stack code. Previously, the TagContributor extension worked well since the stack could contribute the tag and still allow application developers using the stack to contribute additional tags without extending a new class not native to Spring Boot. The ObservationFilter seems like a better fit for this.

Comment From: bclozel

Closing as a duplicate of https://github.com/spring-projects/spring-framework/issues/29839

Comment From: edwardsre

@bclozel Apologies for the duplicate issue. Thanks for making the change!