Stage 9 - Observability, Actuator, and Production Diagnostics
An application is not production-ready just because it starts on a developer machine. Production means somebody will have to answer practical questions under pressure: is the service alive, is it ready to receive traffic, why did requests become slow, did the database connection pool fill up, and which release introduced the problem? Observability is the set of tools and habits that helps answer those questions without guessing.
Why Actuator exists
Spring Boot Actuator exposes operational information through special endpoints under /actuator. These endpoints are not business API endpoints. A customer does not call them to create an order. Infrastructure, monitoring tools, and developers use them to understand the state of the service. The most common endpoint is /actuator/health, which reports whether the application is alive and, if configured, whether important dependencies such as the database are available.
Without Actuator, teams often invent weak health checks like GET /api/orders and assume that a successful response means the service is fine. That is not precise enough. A service can start but fail to connect to the database. It can be alive but not ready for traffic during startup. It can answer one endpoint while a background dependency is broken. Actuator gives a standard place for these signals.
| Signal | Example endpoint or source | What it answers |
|---|---|---|
| Health | /actuator/health | Is the service alive and are required dependencies available? |
| Readiness | /actuator/health/readiness | Can traffic be sent to this instance now? |
| Metrics | /actuator/metrics, /actuator/prometheus | How many requests, errors, memory pressure, and DB pool usage? |
| Logs | Application logs with request id | What happened inside one request? |
| Traces | Distributed tracing system | Which services participated in a slow request? |
Minimal configuration
management.endpoints.web.exposure.include=health,info,metrics,prometheus
management.endpoint.health.probes.enabled=true
management.endpoint.health.show-details=when_authorized
Do not expose every actuator endpoint to the public internet. Some endpoints can reveal environment details, configuration, or operational internals. In production, actuator endpoints are usually restricted by network rules, Spring Security, or both. Public load balancers may need health and readiness, but they do not need full metric details or environment dumps.
A real diagnostic flow
Imagine users report that checkout is slow. A useful investigation has a sequence. First, check dashboards: did p95 latency increase, or is it only one user? Second, check error rate: are 5xx responses rising? Third, inspect database pool metrics: are connections exhausted? Fourth, use logs with a correlation id to follow one slow request through controller, service, repository, and external calls. If tracing is available, check whether the time is spent in this service, the database, or another service.
The important idea is that logs, metrics, and traces are not separate hobbies. Metrics show that something changed. Logs explain what happened in a concrete request. Traces show where time was spent across boundaries. Actuator and Micrometer give the Spring Boot application a standard way to publish these signals.
Common mistakes
- Treating
/actuator/healthas a public debug page instead of an infrastructure signal. - Monitoring only CPU and memory while ignoring latency, error rate, and database pool usage.
- Logging messages without request ids, which makes incident investigation slow.
- Adding dashboards but no alerts, so nobody learns about the problem until users complain.
Understanding checklist
- I can explain the difference between business endpoints and actuator endpoints.
- I know why health, readiness, metrics, logs, and traces answer different questions.
- I can describe a basic diagnostic sequence for a slow or failing request.