Spring Boot / Advanced: observability and resilient releases / Lesson 13
Actuator, health, and observability
Expose deliberate operational evidence while separating endpoint exposure, authorization, health meaning, metrics dimensions, and sensitive diagnostics.
On this page
Lesson goals
- Distinguish enabled/exposed endpoints from permitted access.
- Define readiness and liveness for the application.
- Use bounded metric labels and protected diagnostic evidence.
A running process is not a working business path
Actuator contributes operational endpoints and integrations, but health must mean something specific to the service. Process liveness, ability to accept traffic, dependency availability, and successful order behavior are different signals. A green management endpoint does not establish that the main HTTP path, credentials, or persistence workflow works. Define actionable checks with owners and failure consequences.
Endpoint availability, HTTP/JMX exposure, and security authorization are separate decisions. Exposing a diagnostic surface is not the same as protecting it. Environment, configuration, heap, mappings, and similar diagnostics can reveal sensitive data or internal structure; choose a narrow exposure policy rather than publishing every endpoint for convenience. No management endpoint is contacted or opened here.
Declare a narrow health and exposure policy
The YAML explicitly selects health exposure and hides details, while enabling probe groups and additional main-port paths in a matching Boot3.5 integration. It is syntax-checked configuration only; there is no observed UP response or orchestrator deployment. The security chain and infrastructure routing must separately permit only the intended information.
A separate management port can remain reachable even when the main application connector is unhealthy. Additional liveness/readiness paths on the main port can help test the relevant serving path, but still need appropriate routing and policy. Liveness should not depend on a shared external outage that restarting the process cannot repair. Readiness dependency choices need business-specific reasoning rather than copying every health indicator.
management:
endpoints:
web:
exposure:
include: health
endpoint:
health:
show-details: never
probes:
enabled: true
add-additional-paths: true
The document expresses intended exposure/probe settings. It does not configure every authorization rule or demonstrate a live endpoint.
Keep metric dimensions bounded and meaningful
Counters record occurrences, timers describe duration distributions, and gauges observe current values under their own measurement semantics. The Java fragment registers one bounded outcome label for a lookup counter. It requires a managed Micrometer registry and is not executed. A metric increment is not a transaction receipt or proof that a remote action durably succeeded.
Avoid user identifiers, tokens, full URLs with ids, or arbitrary exception messages as metric tags. High cardinality can consume substantial storage and memory and expose data. Use approved bounded categories and route templates, and keep per-request correlation in appropriately controlled traces/logs. A mean latency alone cannot establish a tail percentile, and exporting a registry requires its own selected backend and lifecycle.
package training.catalog;
import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.stereotype.Component;
@Component
class LookupMetrics {
private final Counter successes;
LookupMetrics(MeterRegistry registry) {
successes = Counter.builder("catalog.lookup.calls")
.tag("outcome", "success")
.description("Completed successful catalog lookups")
.register(registry);
}
void successfulLookup() { successes.increment(); }
}
The label vocabulary is fixed. The fragment neither exports metrics nor measures an application, and call placement must match the intended completed outcome.
Correlate causes without turning diagnostics into a leak
Logs, metrics, and traces answer related but different questions. Trace sampling and propagation determine what can be observed; absence of a sampled span does not prove no work occurred. Preserve an operation identity and restricted causes while avoiding secret headers and unnecessary personal payloads. Redaction must cover failure paths and exporter configuration, not only ordinary success logging.
Correlate latency with database calls, executor queues, downstream timeouts, GC, and error rates under a comparable workload. Instrumentation can add overhead and change data exposure, so review it like other application code. Do not enable verbose request-body logging across a real environment merely to explain one synthetic error. The course creates no telemetry backend or external export.
Verify both useful signals and denied details
Test public status and restricted details, authorized diagnostics, missing authority, startup refusal, readiness changes, and shutdown behavior under a controlled context. Verify sensitive values remain absent and that a public health path does not accidentally authorize env or other endpoints. A custom security chain can change Boot's management-security behavior; test the actual combined configuration.
Record which signal would trigger routing, restart, or an operator action and why that action can help. Avoid alerts with no owner or diagnostic next step. Operational readiness is evidence about the intended service and recovery contract, not a screenshot of one green JSON response. The examples remain illustrative until an authorized framework and deployment environment verifies those conditions.
Common errors and fixes
A management health check passed while the main connector failed
- Why it happens
- The probe did not observe the relevant serving path.
- How to fix it
- Review main-port probe routing and actual readiness semantics.
- Prevent it next time
- Test connector and dependency failure cases.
Metrics created unbounded series
- Why it happens
- Tags contained request-specific or arbitrary values.
- How to fix it
- Use a bounded approved label vocabulary.
- Prevent it next time
- Review cardinality and sensitive data before export.
Exposed endpoints were assumed authenticated
- Why it happens
- Exposure and authorization were conflated.
- How to fix it
- Verify the exact security policy for each surface.
- Prevent it next time
- Test denied access and redaction.
Check your understanding
1. Why should liveness usually avoid a shared database-outage dependency?
Show worked solution
Restarting every application instance cannot repair the shared outage and can amplify failure. Define liveness around process viability and choose readiness dependencies deliberately according to whether routing away can improve the service outcome.
2. Can an average request duration establish p99 latency?
Show worked solution
No. A mean does not describe the tail distribution. Use an appropriate timer/histogram or backend calculation with defined sampling and aggregation, and compare the same workload and outcome classes without unbounded or private labels.
Key takeaways
- Health needs an action-oriented meaning.
- Exposure, authorization, and redaction are separate checks.
- Observability evidence needs bounded dimensions and explicit sampling limits.