Spring Update #3 – We Shall See: Micrometer-based Observability
At the end of 2022, the Spring teams unveiled versions 6 & 3 of the Spring Framework and Spring Boot, respectively. Along with this significant development came Micrometer-based Observability – a feature that enables better monitoring capabilities for cloud-native applications.
In this edition of my 4 part blog series, which highlights the most important updates from the new releases, I will discuss Micrometer-based Observability in more detail.
Check out my two previous blog posts in this series: “New Baselines: Java 17 and Jakarta EE” & “AOT and Native Compilation” if you haven’t already
We Shall See: Micrometer-based Observability
Spring Boot has been providing support for producing metrics in its 2.x-series for quite some time already via Micrometer. The Actuator module instruments various Spring components, like the web frameworks, and Micrometer makes the resulting metrics available to observability tools like Prometheus or Datadog.
To support distributed tracing, Spring Cloud Sleuth is provided: a framework that uses OpenZipkin’s Brave.
Distributed tracing ensures that all services involved in handling a request share a common trace ID for logging, so that that can be correlated. Traces consist of one or more spans, which if so desired can also be exported to tools like OpenZipkin. That provides insight into the flow within a services architecture and especially into the bottlenecks within those flows.
Sleuth is discontinued. As a replacement, the latest version of Micrometer contains a new abstraction for both metrics and tracing.
Within Spring 6, this new micrometer-observation module is a direct dependency of components like spring-web and spring-rabbit. That means that there’s now one single abstraction that can be used directly in Spring’s codebase, rather than the Actuator- or Sleuth-code having to instrument that code from the outside. This provides a simpler, better and deeper integration than was possible in the old situation.
As part of this abstraction, there’s now the notion of low- and high-cardinality key-values. High-cardinality means that a key can have many different values.
Low cardinality keys will be used as both metrics and span tags, while high-cardinality keys are only used as span tags (used when exporting traces), to prevent your metric tags from getting out of hand.
The new Micrometer also supports OpenTelemetry next to OpenZipkin and by default uses W3C trace context propagation instead of OpenZipkin’s B3 headers.
In practice this means that requests and messages will now contain a “traceparent” header, and its value includes a 32-characters long trace ID; Brave would use a 16-character trace ID by default when using Spring Cloud Sleuth. Make sure to take this into account when you have clients and/or backends expecting the old b3 header!
All in all this is a huge step forward in supporting observability as a first class citizen in the Spring ecosystem: hopefully all other Spring projects will receive support for this new observability solution soon as well.
Final Remark
The new Micrometer-based observability solution in Spring 6 is a significant step forward in providing better support for metrics and distributed tracing. It offers deeper integration with existing framework components and supports OpenTelemetry and W3C trace context propagation, making it a powerful tool for gaining visibility into service architectures
