````
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-gateway-mvc</artifactId>
</dependency>
````
This application implements a reverse proxy to an origin server.
````java
@RestController
@SpringBootApplication
public class BugApplication {
@GetMapping("/uaa/**")
public ResponseEntity> proxy(ProxyExchange> proxy) {
return proxy.uri("http://unknown.host.invalid" + proxy.path()).get();
}
public static void main(String[] args) {
SpringApplication.run(BugApplication.class, args);
}
}
````
Memory usage becomes very high because metrics creates a URI tag for every different URL path.
We worked around this by:
````java
@Configuration
@EnableAspectJAutoProxy
public class FixMetricsRestTemplateConfiguration {
@Aspect
@RequiredArgsConstructor
public static class FixMetricsRestTemplateAspect {
private final boolean enabled;
@Around("execution(void org.springframework.boot.actuate.metrics.web.client.MetricsRestTemplateCustomizer.customize(org.springframework.web.client.RestTemplate))")
public Object interceptRestTemplateCustomizer(ProceedingJoinPoint joinPoint) throws Throwable {
return enabled ? joinPoint.proceed() : null;
}
}
@Bean
public FixMetricsRestTemplateAspect fixMetricsRestTemplateAspect(
@Value("${management.metrics.binders.rest-template.enabled:false}") boolean enabled) {
return new FixMetricsRestTemplateAspect(enabled);
}
}
````
FYI @spencergibb. Haven't checked this out myself yesterday, but can we expose a templated form of these URIs as well with sc-gateway?
Got a similar problem with HATEOAS-uris, which are unknown beforehand. Thus uri-templates are awkward to use as the template would consist of just one parameter for the complete uri.
Additionally, at least TestRestTemplate seems to expand templated parameters before metrics. The following unittest using TestRestTemplate shows the full expanded uri at prometheus-endpoint.
template.postForEntity(
"/resource/?theme={THEME}&language={LANG}", request, MyEntity.class,
ImmutableMap.of("THEME", "blue", "LANG", "en"));
I too would prefer a configuration property to disable RestTemplate metrics.
I'm closing this issue because I found MeterFilter can simply disable RestTemplate metrics.
java
@Bean
@ConditionalOnProperty(name = "management.metrics.binders.rest-template.enabled", havingValue = "false")
public MeterRegistryConfigurer denyRestTemplateMeterRegistryConfigurer() {
return registry -> registry.config()
.meterFilter(MeterFilter.denyNameStartsWith("http.client.requests"));
}
Thanks, I was going to suggest the same. In Spring Boot you can also do this in a property-driven way:
management.metrics.enable.http.client.requests=false
Is this still the correct metric to use to disable the RestTemplate metrics? We're seeing metrics being generated even if this configuration is set to 'false'. Also, looking at Spring Boot code I couldn't really see where this configuration would be used.
Is this still the correct metric to use to disable the RestTemplate metrics? We're seeing metrics being generated even if this configuration is set to 'false'.
@RoyJacobs I just created a sample project showing that management.metrics.enable.http.client.requests=false works: https://github.com/izeye/sample-micrometer-spring-boot
Please see the sample and its tests.
Also, looking at Spring Boot code I couldn't really see where this configuration would be used.
You can find the related code here: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/metrics/PropertiesMeterFilter.java#L71
Great, thanks! Turns out there was a BeanPostProcessor in our codebase that caused the MeterRegistry to be instantiated too early, causing it to not have any filters applied.
Most helpful comment
Thanks, I was going to suggest the same. In Spring Boot you can also do this in a property-driven way: