Spring Boot 3 observability baked‑in — Design Review Checklist — Practical Guide (Nov 24, 2025)
Spring Boot 3 Observability Baked‑In — Design Review Checklist
Level: Experienced
As of November 24, 2025, Spring Boot 3 represents a significant step forward in integrating observability natively. This article provides a practical design review checklist for teams adopting its baked-in observability features. The guidance applies primarily to Spring Boot 3.x (3.0 and later), leveraging Micrometer version 1.10+ and native support for OpenTelemetry.
Prerequisites
Before diving into observability design, confirm the following baseline.
- Spring Boot 3.0+ is in use, preferably the latest 3.x stable release.
- Micrometer 1.10+</strong – This version is bundled and recommended for metrics collection.
- Java 17+</strong – Required since Spring Boot 3 targets Java 17 and above.
- OpenTelemetry integration is recommended for distributed tracing, supported natively.
- Instrumentation basics and usage of
@Observedand@Timedannotations.
Understanding your current monitoring backend capabilities (Prometheus, Grafana, Elastic Observability, Datadog, etc.) helps tailor configuration.
Hands-on Steps
1. Enable Core Observability Features
Spring Boot 3 comes with observability auto-configuration enabled by default. Verify in application.properties or application.yml that you have no conflicting settings.
management:
metrics:
enabled: true
tracing:
enabled: true
observability:
enabled: true
2. Configure Micrometer Registries
Configure your metrics registry explicitly if necessary (e.g., Prometheus). Add dependencies for the registry and expose the actuator endpoints.
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
And expose endpoints:
management:
endpoints:
web:
exposure:
include: health,info,prometheus,traces
3. Use Annotations for Custom Metrics and Tracing
Leverage @Timed for measuring execution times and @Observed (a stable feature from Spring Boot 3) for captured spans and enhanced traceability.
@Timed(value = "service.process.time", description = "Time spent processing service method")
public void process() {
// business logic here
}
@Observed(name = "repository.query", lowCardinalityKeyValues = {"type", "select"})
public List<Entity> query() {
// query logic here
}
This removes reliance on manual timer or span management and integrates seamlessly with OpenTelemetry exporters.
4. Integrate OpenTelemetry Collector Exporters
Configure exporting traces and metrics to OpenTelemetry Collector or backend-specific agents in application.yml:
management:
metrics:
export:
prometheus:
enabled: true
tracing:
exporter:
otlp:
enabled: true
endpoint: http://otel-collector:4317
When to choose OpenTelemetry vs Micrometer-native exporters?
- OpenTelemetry — preferred for holistic observability including traces, logs, and metrics, especially in polyglot/multi-service architectures.
- Micrometer-native — simpler, direct Micrometer to Prometheus/Grafana pipelines, good for metrics-only use cases or legacy systems.
Common Pitfalls
- Missing endpoint exposure: Metrics or tracing endpoints not exposed in production due to default security or configuration.
- High-cardinality labels: Using unbounded values in tags (e.g., user IDs, UUIDs) can degrade performance and overwhelm backend storage.
- Ignoring context propagation: Distributed tracing won’t work without configuring proper context propagation libraries and ensuring HTTP (or messaging) contexts propagate trace IDs.
- Over-instrumentation: Excessive or unnecessary timers and spans add noise and overhead rather than clarity.
- Using preview features: From Spring Boot 3 onwards, some features (e.g.,
@TimedLong) may remain preview; production use requires caution.
Validation
Validate implementation via these steps:
- Access actuator endpoints: Verify
/actuator/prometheusand/actuator/tracesrespond correctly. - Check metrics format: Prometheus scrape output should contain expected metric names and tags.
- Run distributed trace test: Using tools like Jaeger UI or vendor dashboard, confirm spans propagate end-to-end across your services.
- Load test to verify overhead: Observe CPU and memory to ensure observability instrumentation does not cause significant pressure.
Checklist / TL;DR
- ✔ Verify Spring Boot 3.0+ and Micrometer 1.10+ dependencies.
- ✔ Enable management observability and tracing in
application.yml. - ✔ Include proper Micrometer registry dependencies for your metrics backend.
- ✔ Apply
@Timedand@Observedannotations on critical methods. - ✔ Configure OpenTelemetry exporters if cross-service tracing or multiple signal types desired.
- ✔ Avoid high-cardinality tag values; prefer low-cardinality tag keys.
- ✔ Expose relevant actuator endpoints securely.
- ✔ Test scraping, tracing UI, and performance under load.