Observability & Actuator

GET /actuator returns a JSON document with a _links section. Each entry maps an endpoint id (like health, metrics, beans) to its URL. It's the menu of endpoints currently exposed over the web.

/actuator/health reports whether the app and its dependencies are healthy, returning a status like UP or DOWN. /actuator/info returns arbitrary descriptive info (build version, git commit) contributed by the app; it is empty unless you configure contributors.

Make a Spring bean annotated with @Endpoint(id="...") and give it a method annotated @ReadOperation. Then expose it via management.endpoints.web.exposure.include so it appears under /actuator/<id>.

By default only the health endpoint is exposed over the web. To expose more, list their IDs (or * for all) in management.endpoints.web.exposure.include, e.g. include=health,info,metrics.

GET /actuator/info returns arbitrary application info as JSON. Spring Boot builds the response by collecting every InfoContributor bean; each one adds details like build version, git commit, or Java/OS info.

Built-in health indicators are checks Actuator adds automatically to the /actuator/health endpoint. Common ones: PingHealthIndicator (always up), DiskSpaceHealthIndicator (free disk), DataSourceHealthIndicator (database), and RedisHealthIndicator when those libraries are present.

A health group bundles a chosen subset of health indicators under a named sub-endpoint. You configure it with management.endpoint.health.group.<name>.include=<indicators>, then read it at /actuator/health/<name>.

A HealthIndicator is a bean that reports the health of one dependency. You implement the health() method to return Health.up() when things work or Health.down() when they don't, and Spring exposes it at /actuator/health.

Liveness says the app is running and healthy; if it fails, Kubernetes restarts the pod. Readiness says the app can accept traffic right now; if it fails, Kubernetes stops routing requests to it but does not restart.

It controls how much detail /actuator/health shows. Values: never (default, only overall status), when-authorized (details shown to logged-in/authorized users), and always (details shown to everyone).

With Actuator + Micrometer on the classpath, Boot auto-registers meters for JVM memory/GC/threads, CPU, process, HTTP requests, datasource, and logback events. A MeterBinder is a small class that binds one such set of metrics to the MeterRegistry.

A Counter records a value that only ever goes up (a total, like requests served). Use a Counter for cumulative counts you increment; use a Gauge for a value that can go up and down, like current queue size.

Add the micrometer-registry-prometheus dependency and expose the endpoint with management.endpoints.web.exposure.include=prometheus. Spring Boot then serves metrics as plain text at /actuator/prometheus, which the Prometheus server reads (scrapes).

MeterRegistry is Micrometer's central object that creates and holds meters (counters, gauges, timers). Spring Boot auto-configures one and injects it, so your code records metrics through it without knowing which monitoring backend receives them.

Tags are key/value labels (like method=GET, status=200) attached to a meter. They let you slice one metric by dimensions and filter or group in your monitoring system instead of creating many separate metrics.

Micrometer Tracing is a vendor-neutral facade for distributed tracing. A bridge plugs a real tracer (OpenTelemetry or Brave/Zipkin) behind that facade, so your code uses one API while the bridge does the actual span work.

@Observed marks a method so Micrometer creates an Observation around each call (producing metrics and/or a trace span). For it to work you must register an ObservedAspect bean, which uses Spring AOP to wrap the annotated method.

The Observation API lets you wrap a piece of code once so Spring can produce monitoring signals from it. You create an Observation on an ObservationRegistry with a name and call observe(...) around your code.

Context propagation passes the current trace's IDs to the next service so their spans join one trace. With Micrometer Tracing, Spring auto-adds a W3C traceparent header carrying the trace ID, the caller's span ID, and a sampled flag.

It sets the fraction of traces that get recorded and exported, from 0.0 (none) to 1.0 (all). The default in Spring Boot is 0.1, meaning about 10% of traces are sampled.

Spring Boot uses Logback as the default logging backend, pulled in via spring-boot-starter-logging. Your code logs through SLF4J, a facade/API, and SLF4J routes those calls to Logback at runtime.

Levels from least to most severe: TRACE, DEBUG, INFO, WARN, ERROR. Setting a logger to a level shows that level and everything more severe. Configure with logging.level.<logger>, e.g. logging.level.org.springframework.web=DEBUG. Default root level is INFO.

Set logging.structured.format.console=ecs (or logstash/gelf) in application.properties. Boot then prints each log line as one JSON object instead of plain text, so log aggregators like Elasticsearch or Loki can parse fields automatically.

logback-spring.xml is loaded by Spring Boot (not raw Logback), so it supports Spring's extensions: <springProfile> includes config only for certain active profiles, and <springProperty> pulls values from Spring's Environment (application.yml) into the Logback config.

Add Micrometer Tracing to the classpath. When a span is active it copies traceId and spanId into SLF4J's MDC (a thread-local map). Spring Boot's default log pattern includes a correlation part that prints those MDC values as [app,traceId,spanId].