Expose Spring Data Repository metrics

[mp911de]

Spring Data repository invocations are not metered yet and it would make sense to expose invocation metrics to improve observability from a repository perspective.

Ideally, repository metrics measure the number of invocations and the timing for each repository method. The metering should use a Micrometer Timer with the following tags per method invocation:

• repository: Simple name of the repository interface class
• method: Method name of the invoked method
• invocation: Invocation type: SYNC (Person, List, …), ASYNC (CompletionStage, ListenableFuture), Stream (Java 8 Stream), REACTIVE (a supported Reactive type according to ReactiveAdapterRegistry)
• result: Whether the method invocation yielded a result (NULL, EMPTY (for Optional.empty() or an empty Collection), PRESENT (for Optional.of(…)))
• exception: Simple name of the exception if an exception was thrown

Specifics to consider:

• Asynchronous calls: Repository queries may offload calls to a worker thread and return CompletionStage or ListenableFuture
• Reactive repositories: Return a reactive type, metrics get collected on success or on error
• Stream queries: Metrics get collected when the Stream is fully consumed/Stream gets closed

Metrics can be collected through a MethodInterceptor as repositories are pure proxy objects that internally dispatch method calls, so from an outside an interceptor seems appropriate. The interceptor can be attached through a RepositoryProxyPostProcessor which needs to be configured on repository factory beans (RepositoryFactoryBeanSupport). That change needs to be done in Spring Data Commons (see DATACMNS-1688).

I have a PoC that uses BeanPostProcessor.postProcessBeforeInitialization(…) so we can turn that into a pull request.

Likely, this feature would require a bit of auto-configuration since metrics so we would need to find a good spot for configuration properties.

Limitations:
JPA runs some activity that happens outside of repository calls (e.g. lazy loading, defer activities until transaction cleanup). These activities would not be included in these metrics.

[wilkinsona]

Thanks for the suggestion, @mp911de.

On first impression it sounds to me like much of the code should go in Spring Data with Spring Boot then auto-configuring things when both Micrometer and Spring Data are on the classpath. I'm imagining Spring Data providing a MicrometerMetricsMethodInterceptor or the like that we can configure when appropriate.

This would be similar to the approach that's been taken in other projects such as Spring Kafka that provides MicrometerConsumerListener and MicrometerProducerListener that we then auto-configure:

spring-boot/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/metrics/KafkaMetricsAutoConfiguration.java

Lines 56 to 72 in ecbc8ea

	@Bean
	public DefaultKafkaProducerFactoryCustomizer kafkaProducerMetrics(MeterRegistry meterRegistry) {
	return (producerFactory) -> addListener(producerFactory, meterRegistry);
	}
	@Bean
	public DefaultKafkaConsumerFactoryCustomizer kafkaConsumerMetrics(MeterRegistry meterRegistry) {
	return (consumerFactory) -> addListener(consumerFactory, meterRegistry);
	}
	private <K, V> void addListener(DefaultKafkaConsumerFactory<K, V> factory, MeterRegistry meterRegistry) {
	factory.addListener(new MicrometerConsumerListener<>(meterRegistry));
	}
	private <K, V> void addListener(DefaultKafkaProducerFactory<K, V> factory, MeterRegistry meterRegistry) {
	factory.addListener(new MicrometerProducerListener<>(meterRegistry));
	}

[mp911de]

I’m quite reluctant to introduce Micrometer to Spring Data as we would introduce another dependency constraint on our release process. Metrics and statistics aren’t things that Spring Data had as domain and I’d like to keep it that way. We’d rather go for a similar arrangement as with WebMVC/WebFlux metrics.

[philwebb]

Whilst I think this would be a nice addition, I don't think that we should try to add too much custom code in Spring Boot to do this. We've already been trying to move some of our MVC metrics code into Spring Framework where it has a more natural home. The specific complexities around asynchronous calls make me quite wary that we'll be maintaining a lot of code without the real expertise required to support it. It's still worth looking at the prototype code that's already been developed, just to see if my concerns are ill-founded or not.

My initial feeling is that we should look at something similar to Hikari. They have a MetricsTrackerFactory interface that creates a IMetricsTracker instance. This provides some nice high-level metrics hook points but doesn't directly tie anything to Micrometer. In that example, there's a MicrometerMetricsTracker IMetricsTracker implementation that eventually bridges to Micrometer. Spring Boot simply configures the datasource to use it.

I like that model a lot because it makes keeps metrics in the domain of the code that understands it best, but doesn't create any hard dependency on any one library.

@mp911de can you share what you have so far (it doesn't need to be a pull-request). Does your prototype code deal with the specific concerns you mentioned in the top issue comment?

[mp911de]

Thanks, Phil. Your words frame exactly the issue. I'm also concerned about the amount of code if all of this functionality would be handled by Spring Boot. We should come up with an approach that doesn't require any outside library to make the same assumptions over execution details as Spring Data does. At the same time, we need something that is able to expose all required details so Spring Boot (or any other library) can collect metrics.

Let me investigate on that topic so I can come back with an API proposal. Here's my draft that uses a MethodInterceptor. The draft deals with all concerns except for Kotlin Coroutine methods.

[wilkinsona]

@mp911de How's this going on the Spring Data side?