Collect metrics during application context startup

Debugging issues about slow application startup times or even figuring out the sequence of events during the application context startup can be challenging.

This issue is about providing a low-cost, safe and metadata-rich strategy to collect metrics during the application context startup. This should be opt-in only and have little to no cost when disabled.

Collected data and metrics should help to:

• have a better understanding of the application context startup process
• identify problematic infrastructure components (like beans taking a lot of time or resources during @PostConstruct processing, creating beans that should have been guarded with conditions, etc).

[bclozel]

I’ve been working on this a bit and I’ll try to summarize the current state of affairs here.

Feature description

This feature is about adding a metrics-like abstraction to the Spring application context and instrumenting various infrastructure components in Spring Framework.

We’d like to achieve the following:

• give a better picture of what happens with a Spring application context (which beans are created, lifecycle phases)
• provide tooling to the Spring team; with all the work going on about GraalVM native image, startup time improvement, this should help defining priorities
• help the Spring community with pathological applications (unusually long startup times) or unexpected behavior

Non-goals:

• this feature is not about replacing other metrics systems like micrometer
• this should be limited to the application context lifecycle and should not be used for runtime behavior metrics, like web requests. Once the context is started, other systems should take the lead.

ContextEvent API

By default, the Spring application context will use a “no-op” implementation that won’t record metrics events.

Applications can configure a ContextEventFactory on the context directly with org.springframework.context.ConfigurableApplicationContext#setContextEventFactory.

This ContextEventFactory can then be used to create events, add metadata to these events and record them. Here’s an example of instrumentation for the Spring application context (here, scanning base packages):

@Override
public void scan(String... basePackages) {
  Assert.notEmpty(basePackages, "At least one base package must be specified");
  // create a metrics event using the configured factory
  // implementations can start recording time duration for this event
  ContextEvent scanPackagesEvent = this.getContextEventFactory().create("spring.context.base-packages.scan");
  // add metadata as Tag instances (key/value String pairs)
  scanPackagesEvent.getTags().add("packages", () -> Arrays.toString(basePackages));
  this.scanner.scan(basePackages);
  // once recorded, the event should be immutable and its execution time recorded
  scanPackagesEvent.record();
}

The current state of this change does not ship any implementation (besides the “no-op” version) in Spring Framework directly.

Spring Boot integration

I’ve tested this infrastructure with a couple of implementations in Spring Boot - also taking the opportunity to instrument the lifecycle of Spring Boot applications (specific events, startup phase before the context creation, web server setup, etc).

A first draft implementation is measuring execution time and buffering the events, then exposing them as a startup timeline. Once exported, we can use this data to represent the startup sequence with something like this (here, a quick proof of concept with a JavaScript library):

Another implementation delegates events directly to Java Flight Recorder:

Next steps

1. Check that the Spring community would be interested in this, and whether we should expand/change the scope of this feature
2. Collect feedback from the Spring team and community about the infrastructure itself (interfaces, concept names)
3. Prepare a complete vision of this feature in Spring Boot: from configuration, to event collection and exporting data

If we make good progress on these 3 points, we can consider moving this issue to a 5.3 milestone.

[bclozel]

@mdeinum this is the right issue. Right now we’re thinking about providing an extension point for registering an implementation that would receive those events and could delegate to JFR, a library (like Micrometer) or anything custom.

This would be a good start in Framework and we could provide such implementations in Spring Boot. What do you think?