Actuator: produktionsreife Endpunkte
Health-, Info- und Metrik-Endpunkte von Haus aus - und wie man sie sicher freigibt.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
A running app in production raises constant questions: Is it healthy? How much memory is it using? What's its request rate? What version is deployed? Spring Boot Actuator answers all of these out of the box, exposing operational endpoints without you writing any monitoring code.
Add it
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>That single starter adds a set of /actuator/* HTTP endpoints.
The endpoints you'll use most
| Endpoint | Tells you |
|---|---|
/actuator/health | Is the app (and its DB, disk, etc.) up? UP or DOWN |
/actuator/info | Arbitrary app info - build version, git commit |
/actuator/metrics | Metrics like JVM memory, CPU, HTTP request timings |
/actuator/loggers | View and change log levels at runtime |
curl http://localhost:8080/actuator/health{"status":"UP","components":{"db":{"status":"UP"},"diskSpace":{"status":"UP"}}}You don't pop the hood every few minutes to check the oil and temperature - the
dashboard surfaces the vital signs at a glance, and warning lights fire when
something needs attention. Actuator is your app's dashboard: /health is the
warning-light system your load balancer watches, and /metrics is the gauges your
monitoring tools read.
Health is the one operators wire up
/actuator/health is the most important endpoint because orchestrators use it. A
Kubernetes liveness probe restarts a container that stops reporting UP; a
readiness probe keeps traffic away until the app is ready. Boot aggregates
contributors (database, disk space, custom checks) into one overall status - and you
can add your own:
@Component
class CatalogHealthIndicator implements HealthIndicator {
@Override
public Health health() {
return catalogReachable()
? Health.up().withDetail("books", 1284).build()
: Health.down().withDetail("reason", "catalog unreachable").build();
}
}Expose endpoints deliberately
By default Boot exposes only /health over HTTP - the rest are hidden, because some
(like /loggers or /env) reveal sensitive detail. You opt in explicitly:
management:
endpoints:
web:
exposure:
include: health, info, metrics # expose exactly what you want
endpoint:
health:
show-details: when-authorized # hide component details from anonymous usersActuator endpoints can leak - secure them
Endpoints like /env, /beans, /heapdump, and /loggers expose configuration and
internals. Only expose what you need, and put the actuator endpoints behind
authentication (you'll wire this up in the Security module) or on a separate,
non-public management port.
Your BookVault container is orchestrated by Kubernetes. Which Actuator endpoint should
the liveness probe hit, what does the app need to return to be considered alive, and
why is exposing that endpoint safe when exposing /actuator/env would not be?
Why does Spring Boot expose only the health endpoint over HTTP by default?
Key takeaways
- spring-boot-starter-actuator adds production-ready /actuator/* endpoints with no code.
- Key endpoints: /health (up/down), /info (build/version), /metrics (JVM, HTTP), /loggers (runtime log levels).
- /actuator/health is what orchestrators watch - Kubernetes liveness/readiness probes rely on it; you can add custom HealthIndicators.
- By default only health is exposed over HTTP; opt in to others via management.endpoints.web.exposure.include.
- Actuator endpoints can leak sensitive data - expose the minimum and secure them behind auth or a separate port.