Zum Hauptinhalt springen

Woche 3, Tag 4 — Spring Boot Actuator: Health, Metrics, Info, Beans, Conditions und Production Monitoring

Ziel

Heute verstehst du Spring Boot Actuator.

Die Kernfragen:

  1. Was ist Spring Boot Actuator?
  2. Warum brauchst du Actuator?
  3. Wie fügst du Actuator hinzu?
  4. Was sind Actuator Endpoints?
  5. Was ist /actuator/health?
  6. Was ist /actuator/info?
  7. Was ist /actuator/metrics?
  8. Was ist /actuator/beans?
  9. Was ist /actuator/conditions?
  10. Was ist /actuator/configprops?
  11. Wie exponierst du Endpoints?
  12. Warum solltest du Actuator Endpoints absichern?
  13. Welche typischen Prüfungsfallen gibt es?

1. Kurz-Wiederholung aus Woche 3, Tag 3

An Tag 3 hast du gelernt:

  • Auto-Konfiguration ist bedingte Bean-Konfiguration.
  • Spring Boot prüft Classpath, Properties, vorhandene Beans, Profiles und Application Type.
  • Starters bringen Dependencies.
  • Auto-Konfiguration konfiguriert Beans.
  • @ConditionalOnMissingBean lässt Boot back off.
  • /actuator/conditions kann beim Debuggen von Auto-Konfiguration helfen.

Merksatz:


Starters bring libraries.
Auto-configuration configures them.
Conditions decide if configuration applies.

Heute lernst du Actuator — damit kannst du eine laufende Spring Boot App beobachten und verwalten.


2. Was ist Spring Boot Actuator?

Spring Boot Actuator liefert production-ready Features zum Monitoring und Management einer Spring Boot Anwendung.

Einfache Definition:

Actuator exponiert operative Informationen über eine laufende Spring Boot Anwendung.

Actuator kann Informationen zeigen über:


health
metrics
application info
beans
configuration properties
auto-configuration conditions
environment properties
loggers
HTTP mappings
thread dumps
caches
scheduled tasks
database migrations

Merksatz:

Actuator hilft dir zu verstehen, was in einer laufenden Spring Boot App passiert.


3. Warum brauchst du Actuator?

In Production musst du Fragen beantworten wie:


Is the application alive?
Is the database reachable?
How much memory is used?
How many HTTP requests are coming in?
Which beans exist?
Which auto-configurations matched?
Which configuration properties are bound?
Which endpoints are mapped?
Are there slow or failing dependencies?

Ohne Actuator müsstest du viele dieser Checks manuell bauen.

Mit Actuator liefert Spring Boot viele davon out of the box.


4. Wie fügst du Actuator hinzu

Gradle:


implementation("org.springframework.boot:spring-boot-starter-actuator")

Maven:


<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Dieser Starter bringt Actuator-Support.

Dann erzeugt Spring Boot Auto-Konfiguration die Actuator Endpoints.

Merksatz:

Actuator Starter bringt die Dependency. Actuator Auto-Konfiguration erzeugt die Endpoints.


5. Was ist ein Actuator Endpoint?

Ein Actuator Endpoint ist ein operativer Endpoint, der Informationen oder Management-Aktionen exponiert.

Beispiel-URLs:


/actuator/health
/actuator/info
/actuator/metrics
/actuator/beans
/actuator/conditions
/actuator/configprops

Default Base Path:


/actuator

Beispiel:


health endpoint ID = health
HTTP URL = /actuator/health

6. Gängige Actuator Endpoints

EndpointZweck
healthzeigt Application Health
infozeigt Application Info
metricszeigt Metrics
beanszeigt Spring Beans
conditionszeigt Auto-Konfigurations-Condition-Report
configpropszeigt @ConfigurationProperties-Werte
envzeigt Environment Properties
loggerszeigt und ändert Logging Levels
mappingszeigt Request Mappings
threaddumpzeigt Thread Dump
scheduledtaskszeigt Scheduled Tasks
cacheszeigt Cache-Informationen

Für die Zertifizierung fokussiere dich vor allem auf:


health
info
metrics
beans
conditions
configprops
env
loggers
mappings

7. Endpoint Availability vs. Exposure

Das ist ein wichtiges Konzept.

Es gibt zwei verschiedene Ideen:


enabled
exposed

Enabled

Der Endpoint ist innerhalb der Anwendung verfügbar.

Exposed

Der Endpoint kann remote aufgerufen werden — zum Beispiel über HTTP.

Merksatz:

Enabled bedeutet: Der Endpoint existiert. Exposed bedeutet: Du kannst ihn remote aufrufen.


8. Default HTTP Exposure

Standardmäßig exponiert Spring Boot nur begrenzte Actuator Endpoints über HTTP.

Die aktuelle offizielle Doku sagt:


Only health is exposed over HTTP by default.

Das ist aus Sicherheitsgründen so.

Warum?

Weil Endpoints wie diese sensible Informationen preisgeben können:


env
beans
configprops
conditions
mappings

Merksatz:

Exponiere sensible Actuator Endpoints nicht öffentlich.


9. Bestimmte Endpoints exponieren

Beispiel:


management:
endpoints:
web:
exposure:
include: health,info,metrics

Das exponiert:


/actuator/health
/actuator/info
/actuator/metrics

Properties-Format:


management.endpoints.web.exposure.include=health,info,metrics

10. Alle Endpoints exponieren

Du kannst alle Endpoints exponieren:


management:
endpoints:
web:
exposure:
include: "*"

Wichtiges YAML-Detail:


Use quotes around "*".

Warum?

Weil * in YAML eine Sonderbedeutung hat.

Properties-Format:


management.endpoints.web.exposure.include=*

Aber Vorsicht.

Das ist in Production gefährlich, wenn du es nicht richtig absicherst.


11. Endpoints ausschließen

Du kannst viele Endpoints exponieren, aber einige ausschließen.

Beispiel:


management:
endpoints:
web:
exposure:
include: "*"
exclude: env,beans

Bedeutung:


Expose all endpoints except env and beans.

Wichtig:

Exclude hat Vorrang vor include.


12. Actuator Base Path ändern

Default:


/actuator

Custom:


management:
endpoints:
web:
base-path: /manage

Dann wird:


/actuator/health

zu:


/manage/health

Nutze das nur, wenn du es brauchst.

Die meisten Anwendungen behalten:


/actuator

13. Actuator auf einem anderen Port laufen lassen

Manchmal sollen Management Endpoints auf einem separaten Port laufen.

Beispiel:


management:
server:
port: 9090

Anwendung:


http://localhost:8080

Actuator:


http://localhost:9090/actuator/health

Das kann helfen, öffentlichen Traffic von Management-Traffic zu trennen.

In Production beschränkt die Infrastruktur oft den Zugriff auf den Management-Port.


14. /actuator/health

Der Health Endpoint zeigt Application Health.

Beispiel:


{
"status": "UP"
}

Gängige Status:


UP
DOWN
OUT_OF_SERVICE
UNKNOWN

Einfache Bedeutung:


UP = application is healthy
DOWN = application has a problem
OUT_OF_SERVICE = application is not available for service
UNKNOWN = health status cannot be determined

Merksatz:

/actuator/health sagt Monitoring-Systemen, ob die App healthy ist.


15. Health und HTTP Status Codes

Typisches Verhalten:


UP -> HTTP 200
DOWN -> HTTP 503
OUT_OF_SERVICE -> HTTP 503

Warum wichtig?

Load Balancer, Kubernetes und Monitoring-Systeme können diesen Endpoint nutzen, um zu entscheiden, ob die App Traffic bekommen soll.


16. Health Details

Standardmäßig können Health Details versteckt sein.

Beispiel für eine einfache Response:


{
"status": "UP"
}

Um mehr Details zu zeigen:


management:
endpoint:
health:
show-details: always

Mögliche Werte:


never
when-authorized
always

Sicherheitswarnung:

Zeige sensible Health Details in Production nicht öffentlich.


17. Health Contributors und Health Indicators

Spring Boot kann Health von verschiedenen Komponenten sammeln.

Beispiele:


database
disk space
mail server
Redis
MongoDB
RabbitMQ
custom external API

Ein Health Indicator prüft einen Teil des Systems.

Beispiel-Idee:


DataSourceHealthIndicator checks database connectivity.
DiskSpaceHealthIndicator checks disk space.

Der Gesamt-Health-Status wird aus diesen Contributors aufgebaut.


18. Custom HealthIndicator

Du kannst deinen eigenen Health Indicator erstellen.

Beispiel:


@Component
public class TaxApiHealthIndicator implements HealthIndicator {

private final TaxApiClient taxApiClient;

public TaxApiHealthIndicator(TaxApiClient taxApiClient) {
this.taxApiClient = taxApiClient;
}

@Override
public Health health() {
boolean reachable = taxApiClient.isReachable();

if (reachable) {
return Health.up()
.withDetail("taxApi", "reachable")
.build();
}

return Health.down()
.withDetail("taxApi", "not reachable")
.build();
}
}

Wenn der Bean-Name lautet:


taxApiHealthIndicator

wird die Health-Komponente normalerweise angezeigt als:


taxApi

weil Spring das Suffix HealthIndicator entfernt.


19. Vorsicht bei Custom Health Checks

Health Checks sollten sein:


fast
safe
reliable
not too expensive
not dependent on slow external calls unless necessary

Schlechter Health Check:


calls 10 external services
runs a heavy database query
waits 30 seconds
modifies data

Guter Health Check:


quick database ping
simple dependency status
cached external service status

Merksatz:

Health Checks sollten schnell und sicher sein.


20. Readiness und Liveness

In Cloud-Umgebungen werden Health Checks oft getrennt in:


liveness
readiness

Liveness

Ist der App-Prozess am Leben?


If liveness fails, restart the app.

Readiness

Ist die App bereit, Traffic zu empfangen?


If readiness fails, stop sending traffic to the app.

Beispiel:


App is alive but database is temporarily unavailable.
Liveness may be UP.
Readiness may be DOWN.

Diese Unterscheidung ist wichtig bei Kubernetes-Deployments.


21. /actuator/info

Der Info Endpoint exponiert Application-Informationen.

Beispiel:


{
"app": {
"name": "klarsync",
"version": "1.0.0"
}
}

Config-Beispiel:


info:
app:
name: klarsync
description: Tax workflow platform
version: 1.0.0

Dann kann:


/actuator/info

diese Daten zeigen — wenn der Endpoint exponiert ist und Info Contributors konfiguriert sind.


22. InfoContributor

Du kannst Custom Info erstellen.


@Component
public class BuildInfoContributor implements InfoContributor {

@Override
public void contribute(Info.Builder builder) {
builder.withDetail("app", Map.of(
"name", "klarsync",
"module", "backend"
));
}
}

Nutze InfoContributor, wenn Application Info aus Code oder Runtime-Daten kommen soll.


23. Was gehört in /info?

Gut:


application name
version
build time
git commit
environment name
module name

Schlecht:


passwords
API keys
tokens
internal private URLs
sensitive customer data

Merksatz:

/info ist für sichere Application Metadata — nicht für Secrets.


24. /actuator/metrics

Der Metrics Endpoint exponiert Application Metrics.

Beispiele für Metrics:


HTTP request count
HTTP request duration
JVM memory usage
CPU usage
thread count
garbage collection metrics
database connection pool metrics
Tomcat metrics
custom business metrics

Beispiel:


/actuator/metrics

zeigt verfügbare Metric-Namen.

Beispiel:


/actuator/metrics/jvm.memory.used

zeigt eine bestimmte Metric.


25. Metrics und Micrometer

Spring Boot nutzt Micrometer als Metrics Facade.

Einfache Definition:

Micrometer ist eine Metrics-Instrumentation Library, die Spring Boot zum Sammeln und Exportieren von Metrics nutzt.

Micrometer kann mit Monitoring-Systemen arbeiten wie:


Prometheus
Grafana
Datadog
New Relic
CloudWatch

Wichtig für die Zertifizierung:

Wisse, dass Actuator Metrics exponiert und Spring Boot Micrometer für Metrics nutzt.


26. Prometheus Endpoint

Für Prometheus fügst du eine Registry Dependency hinzu.

Beispiel Gradle:


runtimeOnly("io.micrometer:micrometer-registry-prometheus")

Dann exponiere den Prometheus Endpoint:


management:
endpoints:
web:
exposure:
include: health,info,prometheus

Endpoint:


/actuator/prometheus

Prometheus kann diesen Endpoint scrapen.


27. Custom Metrics

Beispiel mit MeterRegistry:


@Service
public class TaskService {

private final Counter createdTasksCounter;

public TaskService(MeterRegistry meterRegistry) {
this.createdTasksCounter = Counter.builder("tasks.created")
.description("Number of created tasks")
.register(meterRegistry);
}

public void createTask() {
createdTasksCounter.increment();
}
}

Metric-Name:


tasks.created

Das ist nützlich für Business Metrics.


28. Vorsicht bei Metric Cardinality

Schlechter Metric Tag:


userId
email
requestId
documentId

Warum schlecht?

Weil diese Werte zu viele Time Series erzeugen können.

Gute Metric Tags:


status
method
endpoint pattern
tenant type
operation type

Merksatz:

Metrics Tags sollten niedrige Cardinality haben.


29. /actuator/beans

Der Beans Endpoint zeigt Spring Beans im Application Context.

Er kann diese Fragen beantworten:


Is my bean registered?
What is the bean name?
What is the bean type?
What dependencies does it have?
Which configuration created it?

Beispiel-Nutzung:


I created JwtProperties but injection fails.
Check /actuator/beans to see whether JwtProperties exists.

Dieser Endpoint ist mächtig zum Debuggen.

Aber er kann die interne Struktur preisgeben — exponiere ihn nicht öffentlich.


30. /actuator/conditions

Der Conditions Endpoint zeigt Auto-Konfigurationsentscheidungen.

Er kann beantworten:


Which auto-configurations matched?
Which did not match?
Why did they match?
Why did they not match?

Beispiel-Nutzung:


DataSourceAutoConfiguration matched because JDBC classes are present.
SecurityAutoConfiguration matched because Spring Security is on the classpath.
WebMvcAutoConfiguration did not match because this is not a servlet web app.

Merksatz:

/actuator/conditions ist eines der besten Tools zum Debuggen von Auto-Konfiguration.


31. /actuator/configprops

Der Configprops Endpoint zeigt @ConfigurationProperties Beans.

Er kann beantworten:


Did my properties class bind correctly?
Which values are currently bound?
Which configuration properties beans exist?

Beispiel:


@ConfigurationProperties(prefix = "jwt")
public record JwtProperties(
String issuer,
long expirationMinutes
) {
}

/actuator/configprops kann die gebundenen jwt Properties zeigen.

Sensible Werte können sanitized werden.

Trotzdem: Vorsicht beim Exponieren dieses Endpoints.


32. /actuator/env

Der Env Endpoint zeigt Environment Properties.

Er kann Werte enthalten aus:


application.yml
application-prod.yml
environment variables
system properties
command-line arguments

Er hilft beim Debuggen:


Which property value is active?
Where did this property come from?
Did environment variable override YAML?

Sicherheitswarnung:

/env kann sensible Konfiguration preisgeben — exponiere ihn nicht öffentlich.


33. /actuator/loggers

Der Loggers Endpoint zeigt und kann Logging Levels ändern.

Beispiel-Nutzung:


Change de.klarsync logging from INFO to DEBUG temporarily.

Das kann helfen, Production-Probleme zu debuggen, ohne die App neu zu starten.

Beispiel für einen konzeptionellen Request:


POST /actuator/loggers/de.klarsync
Content-Type: application/json

{
"configuredLevel": "DEBUG"
}

Vorsicht.

Logging Levels in Production zu ändern kann große Logs erzeugen oder sensible Daten preisgeben.


34. /actuator/mappings

Der Mappings Endpoint zeigt Request Mappings.

Er kann beantworten:


Which controller endpoints exist?
Which HTTP method maps to this path?
Why is my endpoint returning 404?
Which handler method receives the request?

Beispiel:


GET /api/tasks -> TaskController.listTasks()
POST /api/tasks -> TaskController.createTask()

Nützlich zum Debuggen von Spring MVC Routing.


35. /actuator/threaddump

Der Threaddump Endpoint zeigt aktuelle JVM Threads.

Nützlich zum Debuggen von:


deadlocks
blocked threads
slow requests
thread pool problems
high CPU issues

Fortgeschritten, aber nützlich in Production Diagnostics.

Nicht öffentlich exponieren.


36. /actuator/heapdump

Der Heapdump Endpoint kann einen Heap Dump erzeugen.

Nützlich zum Debuggen von:


memory leaks
large object retention
high memory usage

Aber sehr sensibel — Heap Dumps können enthalten:


tokens
passwords
personal data
request data
business data

Merksatz:

Exponiere heapdump niemals öffentlich.


37. /actuator/caches

Der Caches Endpoint zeigt Cache-Informationen.

Nützlich bei Spring Cache.

Er kann beantworten:


Which caches exist?
Which cache manager is used?
Are cache names correct?

Beispiel:


/actuator/caches

38. /actuator/scheduledtasks

Der Scheduledtasks Endpoint zeigt Scheduled Tasks.

Nützlich bei:


@Scheduled

Er hilft zu beantworten:


Which scheduled jobs exist?
What cron expressions are configured?
Is my scheduled task registered?

39. Actuator und Security

Actuator Endpoints können sensible Daten preisgeben.

Potenziell sensible Endpoints:


env
beans
configprops
conditions
mappings
heapdump
threaddump
loggers

In Production:


Expose only what you need.
Secure management endpoints.
Do not expose sensitive endpoints publicly.
Use firewall, private network, or Spring Security.

Merksatz:

Actuator ist mächtig — also sichere ihn ab.


40. Actuator mit Spring Security

Wenn Spring Security auf dem Classpath ist, können Actuator Endpoints geschützt werden.

Beispiel-Idee:


@Configuration
public class ActuatorSecurityConfig {

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
return http
.authorizeHttpRequests(auth -> auth
.requestMatchers(EndpointRequest.to("health")).permitAll()
.requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ACTUATOR")
.anyRequest().authenticated()
)
.build();
}
}

Konzept:


health can be public
other actuator endpoints require ACTUATOR role
normal app endpoints require normal app security rules

41. Gängige Production Exposure

Ein sichereres Production-Setup:


management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus
endpoint:
health:
show-details: when-authorized

Das exponiert nützliche Monitoring Endpoints, ohne alles zu exponieren.

Das genaue Setup hängt vom Unternehmen und der Infrastruktur ab.


42. Actuator zum Debuggen von Auto-Konfiguration

Wenn etwas mit Auto-Konfiguration nicht stimmt:

Nutze:


/actuator/conditions

Wenn eine Bean fehlt oder unerwartet ist:

Nutze:


/actuator/beans

Wenn Properties nicht binden:

Nutze:


/actuator/configprops

Wenn Environment-Werte verwirrend sind:

Nutze:


/actuator/env

Merksatz:

Conditions, beans, configprops und env sind Debugging Endpoints.


43. Actuator für deine Klarsync-ähnliche App

Nützliche Endpoints:


/actuator/health

Für Load Balancer und Deployment Health Checks.


/actuator/metrics

Für HTTP Request Duration, JVM Memory und System Metrics.


/actuator/prometheus

Wenn Prometheus/Grafana genutzt wird.


/actuator/info

Für App Version und Build Info.


/actuator/conditions

Zum Debuggen von Auto-Konfiguration.


/actuator/beans

Zum Debuggen der Bean-Registrierung.

Nicht öffentlich exponieren:


/actuator/env
/actuator/heapdump
/actuator/configprops
/actuator/beans

außer stark abgesichert.


44. Praxisbeispiel: minimales Actuator Setup

Gradle:


implementation("org.springframework.boot:spring-boot-starter-actuator")

YAML:


management:
endpoints:
web:
exposure:
include: health,info,metrics

Test:


curl http://localhost:8080/actuator/health

Erwartet:


{
"status": "UP"
}

45. Praxisbeispiel: Debug Setup für lokale Entwicklung

Für lokales Debuggen:


management:
endpoints:
web:
exposure:
include: health,info,metrics,beans,conditions,configprops,env,mappings
endpoint:
health:
show-details: always

Nur lokal oder in einer geschützten Umgebung nutzen.

Nicht öffentlich exponieren.


46. Praxisbeispiel: Production Setup

Für Production:


management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus
endpoint:
health:
show-details: when-authorized

Mögliche zusätzliche Absicherung:


management port on private network
Spring Security role for actuator
firewall rules
VPN-only access
Kubernetes internal service

47. Actuator vs. Logs

Logs beantworten:


What happened?
What error occurred?
What did the app do?

Actuator beantwortet:


What is the current state of the app?
Is it healthy?
What beans exist?
What config is active?
What metrics are recorded?

Beides ist wichtig.

Merksatz:

Logs erzählen die Geschichte. Actuator zeigt den aktuellen Zustand.


48. Actuator vs. APM

Actuator liefert eingebaute operative Endpoints.

APM Tools liefern tieferes Monitoring.

Beispiele:


Datadog
New Relic
Grafana
Prometheus
Elastic APM
OpenTelemetry-based tools

Actuator speist oft Daten in diese Tools ein.

Beispiel:


Actuator metrics -> Prometheus -> Grafana dashboard

49. Typische Prüfungsfallen

Falle 1

Actuator ist nicht für Business REST APIs.

Er ist für Monitoring und Management.


Falle 2

Die Actuator Dependency hinzuzufügen bedeutet nicht, dass jeder Endpoint öffentlich exponiert ist.

Endpoints müssen exponiert werden.


Falle 3

Die aktuelle offizielle Doku exponiert standardmäßig nur health über HTTP.

Nimm nicht an, dass alle Endpoints exponiert sind.


Falle 4

management.endpoints.web.exposure.include=* exponiert alle Endpoints — aber das kann gefährlich sein.


Falle 5

In YAML "*" in Anführungszeichen setzen.

Richtig:


include: "*"

Falle 6

/actuator/conditions hilft beim Debuggen von Auto-Konfiguration.


Falle 7

/actuator/beans zeigt registrierte Spring Beans.


Falle 8

/actuator/configprops zeigt Configuration Properties.


Falle 9

/actuator/env, /actuator/beans, /actuator/configprops und /actuator/heapdump können sensible Daten preisgeben.


Falle 10

Health Checks sollten schnell und sicher sein.


50. Prüfungsfrage: Actuator

Frage:

Was ist Spring Boot Actuator?

Antwort:

Spring Boot Actuator liefert production-ready Monitoring- und Management-Features für Spring Boot Anwendungen. Er exponiert operative Endpoints wie health, info, metrics, beans, conditions und configprops.


51. Prüfungsfrage: Actuator hinzufügen

Frage:

Welche Dependency fügt Actuator hinzu?

Antwort:


implementation("org.springframework.boot:spring-boot-starter-actuator")

oder Maven-Äquivalent:


<artifactId>spring-boot-starter-actuator</artifactId>

52. Prüfungsfrage: Health

Frage:

Was zeigt /actuator/health?

Antwort:

Er zeigt Application Health Information — normalerweise inklusive eines Status wie UP, DOWN, OUT_OF_SERVICE oder UNKNOWN.


53. Prüfungsfrage: Metrics

Frage:

Was zeigt /actuator/metrics?

Antwort:

Er zeigt von der Anwendung gesammelte Metrics — zum Beispiel JVM Memory, HTTP Request Metrics, CPU Usage, Thread Counts und Custom Metrics.


54. Prüfungsfrage: Beans

Frage:

Was zeigt /actuator/beans?

Antwort:

Er zeigt die im Application Context registrierten Spring Beans — inklusive Bean-Namen, Typen, Dependencies und Quellen.


55. Prüfungsfrage: Conditions

Frage:

Was zeigt /actuator/conditions?

Antwort:

Er zeigt die Evaluation von Auto-Konfigurations-Conditions — inklusive welche Konfigurationen gegriffen haben oder nicht und warum.


56. Prüfungsfrage: ConfigProps

Frage:

Was zeigt /actuator/configprops?

Antwort:

Er zeigt @ConfigurationProperties Beans und ihre gebundenen Properties — vorbehaltlich Sanitization.


57. Prüfungsfrage: Endpoints exponieren

Frage:

Wie kannst du health, info und metrics über HTTP exponieren?

Antwort:


management:
endpoints:
web:
exposure:
include: health,info,metrics

58. Prüfungsfrage: Alle exponieren

Frage:

Wie kannst du alle Actuator Endpoints über HTTP exponieren?

Antwort:


management:
endpoints:
web:
exposure:
include: "*"

Aber das solltest du in öffentlichen Production-Umgebungen vermeiden — außer die Endpoints sind richtig abgesichert.


59. Prüfungsfrage: Health Details

Frage:

Wie kannst du Health Details anzeigen?

Antwort:


management:
endpoint:
health:
show-details: always

Sicherere Production-Option:


management:
endpoint:
health:
show-details: when-authorized

60. Prüfungsfrage: Security

Frage:

Warum sollten Actuator Endpoints abgesichert werden?

Antwort:

Einige Actuator Endpoints können sensible Informationen preisgeben — zum Beispiel Environment Properties, Bean-Namen, Configuration Properties, Request Mappings, Thread Dumps oder Heap Dumps. Sie sollten nicht öffentlich exponiert werden ohne Absicherung.


61. Interview-Antwort

Frage:

What is Spring Boot Actuator?

Gute Antwort:

Spring Boot Actuator liefert production-ready Monitoring- und Management-Features für Spring Boot Anwendungen. Er exponiert operative Endpoints wie health, info, metrics, beans, conditions und configprops. Diese Endpoints helfen Entwicklern und Operations-Teams, den Zustand einer laufenden Anwendung zu verstehen, Konfigurationsprobleme zu debuggen und mit Monitoring Tools zu integrieren.


62. Interview-Antwort

Frage:

Which Actuator endpoints do you commonly use?

Gute Antwort:

Ich nutze häufig /actuator/health für Health Checks, /actuator/info für Application Metadata, /actuator/metrics für Runtime Metrics, /actuator/conditions zum Debuggen von Auto-Konfiguration, /actuator/beans zum Prüfen registrierter Beans und /actuator/configprops zum Prüfen gebundener Configuration Properties. In Production exponiere ich nur die Endpoints, die ich brauche, und sichere sensible Endpoints ab.


63. Interview-Antwort

Frage:

How do you debug auto-configuration with Actuator?

Gute Antwort:

Ich nutze /actuator/conditions, um zu sehen, welche Auto-Konfigurationen gegriffen haben oder nicht und warum. Ich nutze /actuator/beans, um zu prüfen, welche Beans tatsächlich registriert sind. Ich nutze /actuator/configprops, um gebundene Configuration Properties zu inspizieren, und /actuator/env, um aktive Property-Werte zu verstehen. Diese Endpoints helfen mir beim Debuggen ohne Raten.


64. Interview-Antwort

Frage:

How do you secure Actuator in production?

Gute Antwort:

Ich exponiere nur die Endpoints, die ich brauche — zum Beispiel health, info, metrics oder prometheus. Ich vermeide es, sensible Endpoints wie env, beans, heapdump und configprops öffentlich zu exponieren. Ich kann Actuator auf einem separaten Management-Port laufen lassen, den Zugriff mit Firewall oder Private-Network-Regeln einschränken und Endpoints mit Spring Security Roles schützen.


65. Interview-Antwort

Frage:

What is the difference between health and metrics?

Gute Antwort:

Der Health Endpoint gibt einen High-Level-Status, ob die Anwendung und ihre Dependencies healthy sind — zum Beispiel UP oder DOWN. Metrics liefern numerische Messwerte über die Zeit — zum Beispiel Request Count, Request Duration, Memory Usage, CPU Usage und Custom Business Counters. Health nutzt man meist für Availability Checks, Metrics für Monitoring von Trends und Performance.


66. Kleine Code-Übung

Actuator hinzufügen:


implementation("org.springframework.boot:spring-boot-starter-actuator")

Endpoints lokal exponieren:


management:
endpoints:
web:
exposure:
include: health,info,metrics,conditions,beans,configprops

Ausführen:


curl http://localhost:8080/actuator/health
curl http://localhost:8080/actuator/conditions
curl http://localhost:8080/actuator/beans

Fragen:

  1. Welcher Endpoint prüft Health?
  2. Welcher Endpoint hilft beim Debuggen von Auto-Konfiguration?
  3. Welcher Endpoint zeigt Beans?
  4. Sollte diese volle Exposure öffentlich in Production genutzt werden?

Antworten:

  1. /actuator/health
  2. /actuator/conditions
  3. /actuator/beans
  4. Nein. Nur lokal oder in einer abgesicherten Umgebung.

67. Kleine Bug-Übung 1

Problem:

Du hast Actuator hinzugefügt, aber /actuator/beans liefert 404.

Frage:

Was ist die wahrscheinliche Ursache?

Antwort:

Der Endpoint ist wahrscheinlich nicht über HTTP exponiert.

Fix:


management:
endpoints:
web:
exposure:
include: beans

Oder mehrere Endpoints exponieren:


management:
endpoints:
web:
exposure:
include: health,info,beans

68. Kleine Bug-Übung 2

Problem:

Du exponierst:


management:
endpoints:
web:
exposure:
include: *

YAML schlägt fehl oder verhält sich unerwartet.

Frage:

Was ist falsch?

Antwort:

In YAML hat * eine Sonderbedeutung. Setze es in Anführungszeichen:


management:
endpoints:
web:
exposure:
include: "*"

69. Kleine Bug-Übung 3

Problem:

/actuator/health ist langsam.

Frage:

Was solltest du prüfen?

Antwort:

Prüfe Custom Health Indicators und externe Dependency Checks. Health Indicators sollten schnell und sicher sein. Vermeide langsame externe Aufrufe, schwere Datenbankabfragen oder Operationen, die hängen können.


Übungsfragen

Frage 1

Was ist Spring Boot Actuator?

Antwort:

Spring Boot Actuator liefert production-ready Monitoring- und Management-Features für Spring Boot Anwendungen.


Frage 2

Warum brauchst du Actuator?

Antwort:

Actuator hilft, eine laufende Anwendung zu überwachen und zu verstehen. Er kann Health, Metrics, Beans, Configuration Properties, Auto-Konfigurations-Conditions, Environment Properties, Mappings und mehr zeigen.


Frage 3

Welche Dependency fügt Actuator hinzu?

Antwort:

Nutze:


implementation("org.springframework.boot:spring-boot-starter-actuator")

Frage 4

Was ist ein Actuator Endpoint?

Antwort:

Ein Actuator Endpoint ist ein operativer Endpoint, der Monitoring- oder Management-Informationen über die Anwendung exponiert.


Frage 5

Was ist der Default Actuator Base Path?

Antwort:

Der Default Actuator Base Path ist:


/actuator

Frage 6

Was zeigt /actuator/health?

Antwort:

/actuator/health zeigt Application Health Information wie UP, DOWN, OUT_OF_SERVICE oder UNKNOWN.


Frage 7

Was zeigt /actuator/info?

Antwort:

/actuator/info zeigt Application Metadata wie Name, Version, Build Information oder Custom Info.


Frage 8

Was zeigt /actuator/metrics?

Antwort:

/actuator/metrics zeigt Runtime Metrics wie JVM Memory, HTTP Request Metrics, CPU Usage, Thread Counts und Custom Metrics.


Frage 9

Was zeigt /actuator/beans?

Antwort:

/actuator/beans zeigt im Application Context registrierte Spring Beans.


Frage 10

Was zeigt /actuator/conditions?

Antwort:

/actuator/conditions zeigt, welche Auto-Konfigurationen gegriffen haben oder nicht — und warum.


Frage 11

Was zeigt /actuator/configprops?

Antwort:

/actuator/configprops zeigt @ConfigurationProperties Beans und ihre gebundenen Werte — vorbehaltlich Sanitization.


Frage 12

Was ist der Unterschied zwischen enabled und exposed?

Antwort:

Enabled bedeutet: Ein Endpoint existiert in der Anwendung. Exposed bedeutet: Er kann remote aufgerufen werden — zum Beispiel über HTTP.


Frage 13

Wie kannst du health, info und metrics exponieren?

Antwort:

Nutze:


management:
endpoints:
web:
exposure:
include: health,info,metrics

Frage 14

Wie kannst du alle Endpoints in YAML exponieren?

Antwort:

Nutze:


management:
endpoints:
web:
exposure:
include: "*"

Frage 15

Warum sollte "*" in YAML in Anführungszeichen stehen?

Antwort:

* hat in YAML eine Sonderbedeutung — setze es in Anführungszeichen, wenn du es als Literal-Wert nutzt.


Frage 16

Warum sollten Actuator Endpoints abgesichert werden?

Antwort:

Actuator Endpoints sollten abgesichert werden, weil einige sensible Informationen preisgeben können — zum Beispiel Environment Properties, Bean-Namen, Config Properties, Mappings, Thread Dumps oder Heap Dumps.


Frage 17

Was ist ein HealthIndicator?

Antwort:

Ein HealthIndicator ist eine Komponente, die Health-Informationen für einen Teil des Systems liefert — zum Beispiel eine Datenbank, Disk Space oder eine externe API.


Frage 18

Was ist Micrometer?

Antwort:

Micrometer ist die Metrics-Instrumentation Library, die Spring Boot zum Sammeln und Exportieren von Metrics nutzt.


Frage 19

Was ist der Unterschied zwischen Health und Metrics?

Antwort:

Health gibt einen High-Level-Status wie UP oder DOWN. Metrics liefern numerische Messwerte wie Memory Usage, Request Count, Request Duration und Custom Counters.


Frage 20

Welche Endpoints sind nützlich zum Debuggen von Auto-Konfiguration und Bean-Registrierung?

Antwort:

Nützliche Endpoints sind:


/actuator/conditions
/actuator/beans
/actuator/configprops
/actuator/env

Merksätze zum Mitnehmen

  • Actuator liefert production-ready Monitoring- und Management-Features.
  • Actuator Endpoints exponieren operative Informationen.
  • Der Default Base Path ist /actuator.
  • /actuator/health zeigt Application Health.
  • /actuator/info zeigt Application Metadata.
  • /actuator/metrics zeigt Runtime Metrics.
  • /actuator/beans zeigt Spring Beans.
  • /actuator/conditions zeigt Auto-Konfigurationsentscheidungen.
  • /actuator/configprops zeigt Configuration Properties.
  • Enabled bedeutet: Der Endpoint existiert.
  • Exposed bedeutet: Der Endpoint kann remote aufgerufen werden.
  • Nutze management.endpoints.web.exposure.include, um Endpoints zu exponieren.
  • Setze "*" in YAML in Anführungszeichen.
  • Exponiere sensible Endpoints nicht öffentlich.
  • Health Checks sollten schnell und sicher sein.
  • Micrometer wird für Metrics genutzt.
  • Actuator ist nützlich für Debugging und Production Monitoring.