Spring Boot observability

For trace propagation across multiple services (a gateway, a message broker, or an @Async boundary silently breaking a trace mid-request), see spring-boot-microservices's observability section — this skill covers the single-service mechanics that section builds on.

The three pillars, and what Spring Boot provides for each

• Metrics — Micrometer (a vendor-neutral facade, analogous to how SLF4J works for logging) auto-configured by spring-boot-starter-actuator; exports to Prometheus, Datadog, etc. via a micrometer-registry-{system} dependency.
• Logs — structured (JSON) logs with correlation/trace IDs, so a single request can be followed across log lines.
• Traces — distributed tracing via Micrometer Tracing + OpenTelemetry, showing a request's path across service boundaries.

Start with Actuator + Prometheus for basic metrics (no code changes needed), add custom business metrics with Micrometer, then layer in OpenTelemetry tracing once metrics are flowing — don't try to stand up all three at once on a project with none of them.

Health checks — separate liveness from readiness

Don't expose one undifferentiated /actuator/health and point every check at it. Kubernetes (and most orchestrators) distinguish:

• Liveness — "is the process alive enough to keep running, or should it be restarted?" Should NOT depend on external systems (DB, downstream services) — a slow database shouldn't cause Kubernetes to kill and restart an otherwise-healthy pod in a crash loop.
• Readiness — "should traffic be routed to this instance right now?" SHOULD check external dependencies — a pod that can't reach its database should stop receiving traffic without being restarted.