Abschlusslektion — Actuator, Observability, Production Diagnostics und Spring-Professional-Finale

Ziel

Das ist die letzte Lektion des Spring-Professional-Vorbereitungsbuchs.

Heute willst du verstehen:

Was ist Spring Boot Actuator?
Was ist Observability?
Was sind Health Checks?
Was ist der info-Endpoint?
Was sind Metrics?
Was ist Micrometer?
Was ist Prometheus?
Was ist Tracing?
Was ist Logging-Korrelation?
Welche Actuator-Endpoints sind wichtig?
Was solltest du in Production exponieren?
Was sind typische Sicherheitsfallen?
Was reicht für die Spring-Professional-Prüfung?
Was sind die finalen Merksätze für das ganze Buch?

1. Überblick

Wenn eine Anwendung in Production läuft, reicht Code schreiben nicht aus.

Du musst auch Antworten finden auf:

Läuft die App?
Ist die Datenbank erreichbar?
Ist die App langsam?
Welcher Endpoint schlägt fehl?
Wie viele Requests kommen rein?
Wie viel Speicher wird genutzt?
Laufen geplante Jobs?
Welche Beans existieren?
Welche Mappings existieren?
Warum hat Auto-Konfiguration gegriffen?
Welche Logs solltest du prüfen?
Welcher Request hat diesen Fehler verursacht?

Spring Boot Actuator und Observability helfen dir, diese Fragen zu beantworten.

Merksatz:

Production-Code muss beobachtbar sein.

2. Was ist Spring Boot Actuator?

Spring Boot Actuator ergänzt production-ready Monitoring- und Management-Features.

Er stellt Endpoints bereit wie:

/actuator/health
/actuator/info
/actuator/metrics
/actuator/prometheus
/actuator/loggers
/actuator/mappings
/actuator/beans
/actuator/conditions
/actuator/caches
/actuator/scheduledtasks

Diese Endpoints helfen dir, die laufende Anwendung zu inspizieren und zu überwachen.

Merksatz:

Actuator exponiert Production-Informationen über die laufende Spring-Boot-App.

3. Actuator-Dependency hinzufügen

Gradle:

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

Maven:

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

Nach dem Hinzufügen von Actuator kann Spring Boot Management-Endpoints exponieren.

Merksatz:

spring-boot-starter-actuator fügt production-ready Endpoints hinzu.

4. Actuator-Basis-Pfad

Standardmäßig liegen Actuator-Web-Endpoints meist unter:


/actuator

Beispiele:

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

Die Endpoint-ID wird Teil der URL.

Beispiel:

health endpoint -> /actuator/health
metrics endpoint -> /actuator/metrics

Merksatz:

Actuator-Endpoints liegen meist unter /actuator.

5. Endpoint-Exposition

Nicht jeder Endpoint sollte über HTTP exponiert werden.

Beispiel-Konfiguration:

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

Das exponiert nur:

health
info
metrics
prometheus

Gefährliches Beispiel:

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

Das exponiert alles.

In Production kann das gefährlich sein.

Merksatz:

Exponiere nur die Actuator-Endpoints, die du wirklich brauchst.

6. Wichtige Production-Regel

Actuator-Endpoints können sensible Informationen preisgeben.

Beispiele:

environment properties
beans
configuration properties
request mappings
logger configuration
database status
cache names
scheduled tasks

Production-Endpoints sollten deshalb:

begrenzt
abgesichert
überwacht
nicht öffentlich offen

sein.

Merksatz:

Actuator ist mächtig — Actuator muss abgesichert werden.

7. Health-Endpoint

Der wichtigste Endpoint ist:


/actuator/health

Er beantwortet:


Ist die Anwendung gesund?

Beispiel-Antwort:

{
  "status": "UP"
}

Eine detailliertere Antwort kann Komponenten enthalten:

{
  "status": "UP",
  "components": {
    "db": {
      "status": "UP"
    },
    "diskSpace": {
      "status": "UP"
    }
  }
}

Merksatz:

/actuator/health zeigt, ob die Anwendung gesund ist.

8. Health-Status

Gängige Health-Status:

UP
DOWN
OUT_OF_SERVICE
UNKNOWN

Bedeutung:

Status	Bedeutung
`UP`	Komponente funktioniert
`DOWN`	Komponente schlägt fehl
`OUT_OF_SERVICE`	Komponente ist absichtlich nicht verfügbar
`UNKNOWN`	Status kann nicht bestimmt werden

Merksatz:

Health-Status fasst zusammen, ob App oder Abhängigkeit nutzbar ist.

9. Health-Details

Standardmäßig können Health-Details verborgen sein.

Konfigurationsbeispiel:

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

Weitere mögliche Varianten:

management:
  endpoint:
    health:
      show-details: always

Vorsicht bei:


show-details: always

weil das Infrastruktur-Details preisgeben kann.

Merksatz:

Health-Details sind nützlich, können aber sensible Informationen preisgeben.

10. Health Indicators

Spring Boot kann Health Indicators für gängige Abhängigkeiten auto-konfigurieren.

Beispiele:

database
disk space
Redis
MongoDB
RabbitMQ
Kafka
Elasticsearch
mail server

Wenn die Datenbank down ist, kann Health werden:

{
  "status": "DOWN"
}

Merksatz:

Health Indicators prüfen wichtige Anwendungsabhängigkeiten.

11. Custom Health Indicator

Manchmal brauchst du eigene Health-Logik.

Beispiel:

@Component
public class ExternalApiHealthIndicator implements HealthIndicator {

    private final ExternalApiClient externalApiClient;

    public ExternalApiHealthIndicator(ExternalApiClient externalApiClient) {
        this.externalApiClient = externalApiClient;
    }

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

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

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

Merksatz:

Custom Health Indicators ergänzen anwendungsspezifische Health Checks.

12. Liveness und Readiness

In Container-Plattformen wie Kubernetes sind zwei Health-Konzepte üblich:

liveness
readiness

Liveness

Frage:


Soll der Container neu gestartet werden?

Beispiel:


Die App hängt und kann sich nicht erholen.

Readiness

Frage:


Soll Traffic an diese Instanz geschickt werden?

Beispiel:

Die App startet, eine Datenbank-Migration läuft oder eine Abhängigkeit ist noch nicht bereit.

Merksatz:

Liveness geht um Neustart; Readiness geht um Traffic-Empfang.

13. Info-Endpoint

Endpoint:


/actuator/info

Er kann allgemeine Anwendungsinformationen exponieren.

Beispiel-Konfiguration:

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

Beispiel-Antwort:

{
  "app": {
    "name": "klarsync",
    "description": "Tax workflow platform",
    "version": "1.0.0"
  }
}

Merksatz:

/actuator/info exponiert Anwendungs-Metadaten.

14. Metrics-Endpoint

Endpoint:


/actuator/metrics

Er zeigt verfügbare Metric-Namen.

Beispiel-Metric-Namen:

http.server.requests
jvm.memory.used
jvm.threads.live
process.cpu.usage
system.cpu.usage
hikaricp.connections.active
logback.events

Um eine Metric zu inspizieren:


/actuator/metrics/http.server.requests

Merksatz:

/actuator/metrics zeigt numerische Messwerte über die laufende App.

15. Was sind Metrics?

Metrics sind numerische Messwerte über die Zeit.

Beispiele:

request count
request duration
error count
memory usage
CPU usage
active database connections
cache hits
cache misses
queue size
scheduled job duration

Metrics beantworten:

Wie viel?
Wie oft?
Wie langsam?
Wie viele Fehler?

Merksatz:

Metrics machen aus Anwendungsverhalten Zahlen.

16. Micrometer

Micrometer ist die Metrics-Fassade, die Spring Boot nutzt.

Einfache Idee:

Anwendungscode zeichnet Metrics mit Micrometer auf.
Micrometer sendet Metrics an Monitoring-Systeme.

Monitoring-Systeme können sein:

Prometheus
Datadog
New Relic
Graphite
OTLP/OpenTelemetry

Merksatz:

Micrometer ist eine vendor-neutrale Fassade für Anwendungs-Metrics.

17. Prometheus

Prometheus ist ein Monitoring-System, das Metrics scraped.

Spring Boot kann exponieren:


/actuator/prometheus

Prometheus liest diesen Endpoint regelmäßig aus.

Beispiel-Dependency:

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

Beispiel-Exposition:

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

Merksatz:

Prometheus scraped /actuator/prometheus.

18. Prometheus-Flow

Spring Boot app
  ↓ exponiert
/actuator/prometheus
  ↓ scraped von
Prometheus
  ↓ visualisiert von
Grafana

Gängiges Setup:


Spring Boot + Actuator + Micrometer + Prometheus + Grafana

Merksatz:

Prometheus sammelt Metrics; Grafana visualisiert sie.

19. Custom Metrics

Manchmal reichen eingebaute Metrics nicht.

Beispiel:

@Service
public class InvoiceService {

    private final Counter invoiceCreatedCounter;

    public InvoiceService(MeterRegistry meterRegistry) {
        this.invoiceCreatedCounter = Counter.builder("invoices.created")
                .description("Number of created invoices")
                .register(meterRegistry);
    }

    public void createInvoice() {
        // business logic
        invoiceCreatedCounter.increment();
    }
}

Das erzeugt eine Custom Metric:


invoices.created

Merksatz:

Custom Metrics messen geschäftsspezifisches Verhalten.

20. Timer Metric

Nutze einen Timer für Dauer.

Beispiel:

@Service
public class ReportService {

    private final Timer reportTimer;

    public ReportService(MeterRegistry meterRegistry) {
        this.reportTimer = Timer.builder("reports.generation.duration")
                .description("Time to generate reports")
                .register(meterRegistry);
    }

    public Report generateReport() {
        return reportTimer.record(() -> {
            // generate report
            return new Report();
        });
    }
}

Merksatz:

Timer messen, wie lange Operationen dauern.

21. Metric Tags

Tags fügen Dimensionen hinzu.

Beispiel:

Counter.builder("tasks.created")
        .tag("tenant", tenantId.toString())
        .tag("status", "success")
        .register(meterRegistry)
        .increment();

Aber Vorsicht.

Schlechte Tags:

userId
email
requestId
full URL with IDs
random UUID

Warum?

zu viele eindeutige Tag-Werte
hohe Kardinalität
Überlastung des Monitoring-Systems
hoher Speicherverbrauch
teure Queries

Merksatz:

Metric-Tags sollten niedrige Kardinalität haben.

22. Prüfungsfalle: hohe Kardinalität

Schlechte Metric:

http.request.user.email=user123@example.com
http.request.user.email=user456@example.com
http.request.user.email=user789@example.com

Problem:

zu viele eindeutige Time Series
hoher Speicherverbrauch
langsame Monitoring-Queries
teures Monitoring

Besser:

status=success/failure
method=GET/POST
endpoint=/api/tasks/{id}
tenant_type=small/large

Merksatz:

Packe niemals User-IDs, E-Mails oder zufällige IDs in Metric-Tags.

23. Logging

Logs beantworten:


Was ist passiert?

Beispiel-Log:


2026-07-07 10:15:30 INFO TaskService - Created task id=123 tenant=5

Gute Logs helfen beim Debuggen von:

errors
business events
slow operations
external API failures
security events
background job failures

Merksatz:

Logs erklären, was passiert ist.

24. Gutes Logging

Gutes Log:

log.info("Created task id={} tenantId={}", taskId, tenantId);

Schlechtes Log:

log.info("Created task " + task);

Warum schlecht?

kann zu viel loggen
kann sensible Daten preisgeben
schwerer zu durchsuchen
kann Lazy Loading auslösen

Merksatz:

Logge wichtige Fakten, keine riesigen Objekte.

25. Keine Secrets loggen

Niemals loggen:

passwords
JWT tokens
refresh tokens
API keys
credit card data
private personal data
session cookies
reset tokens
authorization headers

Schlecht:

log.info("Login request: {}", request);

Wenn der Request ein Passwort enthält, ist das gefährlich.

Merksatz:

Logs sind Production-Daten — logge niemals Secrets.

26. Log-Levels

Gängige Log-Levels:

Level	Bedeutung
`TRACE`	sehr detaillierte Diagnose-Informationen
`DEBUG`	Entwicklungs-/Debug-Informationen
`INFO`	normale wichtige Ereignisse
`WARN`	unerwartetes, aber behebbares Problem
`ERROR`	Fehler, der Aufmerksamkeit braucht

Merksatz:

Nutze Log-Levels, um den Schweregrad zu zeigen.

27. Loggers-Endpoint

Actuator-Endpoint:


/actuator/loggers

Er kann Logger-Levels anzeigen und manchmal zur Laufzeit ändern.

Beispiel:


/actuator/loggers/com.example.TaskService

Das ist nützlich beim Debuggen von Production-Problemen.

Aber er muss abgesichert werden.

Merksatz:

/actuator/loggers hilft beim Production-Debug — ist aber sensibel.

28. Tracing

Metrics beantworten:


Wie viele? Wie langsam?

Logs beantworten:


Was ist passiert?

Traces beantworten:


Wo ist dieser Request hingegangen?

In Microservices kann ein Request durch viele Services laufen:

frontend
  ↓
backend API
  ↓
user service
  ↓
task service
  ↓
database
  ↓
external API

Tracing verbindet diese Schritte.

Merksatz:

Tracing folgt einem Request über Komponenten hinweg.

29. Span und Trace

Ein Trace repräsentiert eine End-to-End-Operation.

Ein Span repräsentiert einen Schritt innerhalb dieses Traces.

Beispiel:

Trace: Create task request
  Span 1: HTTP POST /api/tasks
  Span 2: validate request
  Span 3: save task to database
  Span 4: publish event
  Span 5: send notification

Merksatz:

Ein Trace enthält Spans.

30. Correlation-ID

Eine Correlation-ID ist eine ID, die Logs für denselben Request verbindet.

Beispiel:

traceId=abc123 POST /api/tasks started
traceId=abc123 validating request
traceId=abc123 saved task id=55
traceId=abc123 POST /api/tasks finished

Das hilft, alle Logs für einen Request zu finden.

Merksatz:

Correlation-IDs verbinden Logs, die zum selben Request gehören.

31. Micrometer Tracing

Spring Boot unterstützt Micrometer Tracing.

Es kann mit Tracing-Systemen integrieren wie:

OpenTelemetry
Zipkin

Tracing hilft zu beantworten:

Welcher Service ist langsam?
Wo ist der Request fehlgeschlagen?
Welcher Datenbankaufruf war teuer?
Welcher Downstream-Call hat Latenz verursacht?

Merksatz:

Micrometer Tracing verbindet den Request-Flow über Komponenten hinweg.

32. Observability: Logs, Metrics, Traces

Die drei gängigen Observability-Säulen:

logs
metrics
traces

Tool	Beantwortet
Logs	Was ist passiert?
Metrics	Wie viele, wie langsam, wie oft?
Traces	Wo ist der Request hingegangen?

Merksatz:

Logs erzählen Geschichten, Metrics zeigen Zahlen, Traces zeigen Pfade.

33. Actuator Mappings-Endpoint

Endpoint:


/actuator/mappings

Er zeigt Request-Mappings.

Nützlich zum Debuggen:

Welche Endpoints existieren?
Welcher Controller behandelt diesen Pfad?
Warum ist mein Endpoint nicht erreichbar?
Welche HTTP-Methode ist gemappt?

Merksatz:

/actuator/mappings zeigt Controller-Route-Mappings.

34. Actuator Beans-Endpoint

Endpoint:


/actuator/beans

Er zeigt Spring Beans im Application Context.

Nützlich zum Debuggen:

Wurde meine Bean erstellt?
Welcher Bean-Name existiert?
Welche Abhängigkeiten sind verdrahtet?
Warum erzeugt Auto-Konfiguration diese Bean?

Aber er kann interne Struktur preisgeben.

Merksatz:

/actuator/beans zeigt die Struktur des Spring Application Context.

35. Actuator Conditions-Endpoint

Endpoint:


/actuator/conditions

Er zeigt die Auswertung von Auto-Konfigurations-Bedingungen.

Nützlich zum Debuggen:

Warum wurde diese Auto-Konfiguration angewendet?
Warum wurde diese Auto-Konfiguration nicht angewendet?
Welche Bedingung hat gegriffen?
Welche Bedingung hat nicht gegriffen?

Merksatz:

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

36. Actuator Caches-Endpoint

Endpoint:


/actuator/caches

Er zeigt Cache Manager und Caches.

Nützlich für:

Cache-Namen prüfen
Cache-Konfiguration debuggen
Caches leeren, falls aktiviert

Merksatz:

/actuator/caches hilft, die Cache-Infrastruktur zu inspizieren.

37. Actuator Scheduled Tasks-Endpoint

Endpoint:


/actuator/scheduledtasks

Er zeigt geplante Tasks.

Nützlich für:

Cron-Jobs prüfen
Fixed-Delay-Jobs prüfen
Fixed-Rate-Jobs prüfen
fehlende Scheduled Methods debuggen

Merksatz:

/actuator/scheduledtasks hilft, geplante Jobs zu inspizieren.

38. Actuator Metrics-Endpoint

Endpoint:


/actuator/metrics

Nützliche Beispiele:

/actuator/metrics/http.server.requests
/actuator/metrics/jvm.memory.used
/actuator/metrics/hikaricp.connections.active
/actuator/metrics/cache.gets

Er hilft zu beantworten:

Ist die App langsam?
Schlagen Requests fehl?
Wächst der Speicher?
Sind Datenbankverbindungen erschöpft?
Funktioniert der Cache?

Merksatz:

Metrics helfen, Performance- und Ressourcenprobleme zu diagnostizieren.

39. HTTP-Request-Metrics

Wichtige Metric:


http.server.requests

Sie kann zeigen:

request count
response status
HTTP method
URI pattern
duration
exceptions

Nützliche Fragen:

Welcher Endpoint ist langsam?
Welcher Endpoint liefert viele 500-Fehler?
Wie viele Requests treffen diese API?

Merksatz:

HTTP-Metrics zeigen Request-Volumen, Latenz und Fehler.

40. Database-Pool-Metrics

Bei HikariCP können nützliche Metrics sein:

hikaricp.connections.active
hikaricp.connections.idle
hikaricp.connections.pending
hikaricp.connections.max

Sie helfen zu beantworten:

Sind Datenbankverbindungen erschöpft?
Warten Requests auf eine Verbindung?
Ist der Pool zu klein?
Gibt es ein Connection Leak?

Merksatz:

Database-Pool-Metrics helfen, Datenbankdruck zu diagnostizieren.

41. JVM-Metrics

Gängige JVM-Metrics:

jvm.memory.used
jvm.memory.max
jvm.threads.live
jvm.gc.pause
process.cpu.usage
system.cpu.usage

Sie helfen zu beantworten:

Ist der Speicher zu hoch?
Ist Garbage Collection teuer?
Laufen zu viele Threads?
Ist die CPU überlastet?

Merksatz:

JVM-Metrics zeigen die Runtime-Gesundheit der Anwendung.

42. Production-Diagnostic-Flow

Wenn ein Production-Problem auftritt, frag:

Ist die App UP?
Sind Abhängigkeiten gesund?
Steigen Fehler?
Welcher Endpoint ist langsam?
Ist der Database Pool erschöpft?
Ist der Speicher hoch?
Zeigen Logs Exceptions?
Finde ich den Trace?
Hat sich kürzlich ein Deployment geändert?

Eine gute Untersuchungsreihenfolge:

health
logs
metrics
traces
kürzliche Deployment-/Config-Änderungen
Datenbank-/externe-Abhängigkeits-Checks

Merksatz:

Diagnostiziere Production mit Health, Logs, Metrics und Traces zusammen.

43. Beispiel: API ist langsam

Symptome:


Nutzer sagen, /api/tasks ist langsam.

Prüfen:

/actuator/health
/actuator/metrics/http.server.requests
/actuator/metrics/hikaricp.connections.active
application logs
traces for /api/tasks
database query logs

Mögliche Ursachen:

langsame Datenbank-Query
N+1-Problem
Database Connection Pool erschöpft
externe API langsam
zu hohe CPU-Auslastung
großes Response-Payload
Cache funktioniert nicht

Merksatz:

Langsame APIs brauchen Metrics plus Traces plus Logs.

44. Beispiel: App ist DOWN

Prüfen:


/actuator/health

Mögliche Komponente:

db DOWN
redis DOWN
diskSpace DOWN
externe Abhängigkeit DOWN

Dann Logs prüfen.

Merksatz:

Health sagt, was kaputt ist; Logs erklären warum.

45. Beispiel: Endpoint fehlt

Problem:


GET /api/tasks liefert 404.

Prüfen:


/actuator/mappings

Mögliche Ursachen:

falscher Pfad
falsche HTTP-Methode
Controller Bean nicht geladen
falsches Profil
Security blockiert Request
Context-Path-Mismatch

Merksatz:

/actuator/mappings hilft beim Debuggen fehlender Endpoints.

46. Beispiel: Bean fehlt

Problem:


Die Anwendung erstellt die MyService Bean nicht.

Prüfen:

/actuator/beans
/actuator/conditions
logs at startup

Mögliche Ursachen:

Package nicht gescannt
Profil-Mismatch
bedingte Bean hat nicht gegriffen
fehlende Abhängigkeit
fehlende Configuration Property

Merksatz:

Beans- und Conditions-Endpoints helfen beim Debuggen von Spring-Context-Problemen.

47. Actuator-Sicherheit

Production-Empfehlung:

Nur sichere Endpoints exponieren.
Sensible Endpoints absichern.
env/beans/conditions nicht öffentlich exponieren.
Authentifizierung und Autorisierung nutzen.
Netzwerk-Einschränkungen nutzen, wenn möglich.
Keine Secrets preisgeben.

Beispiel:

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

Für internes Debuggen mehr exponieren — nur in geschützten Umgebungen.

Merksatz:

Lass sensible Actuator-Endpoints niemals offen im öffentlichen Internet.

48. Separater Management-Port

Manchmal nutzen Management-Endpoints einen separaten Port.

Beispiel:

management:
  server:
    port: 8081

Dann laufen App-Endpoints vielleicht auf:

und Management-Endpoints auf:

Nützlich für:

Netzwerk-Einschränkungen
internes Monitoring
separate Firewall-Regeln

Merksatz:

Ein separater Management-Port kann helfen, Actuator-Endpoints zu isolieren.

49. Kubernetes Health Checks

In Kubernetes-ähnlichen Systemen werden Health-Endpoints häufig für Probes genutzt.

Readiness Probe:


Soll dieser Pod Traffic empfangen?

Liveness Probe:


Soll dieser Pod neu gestartet werden?

Schlechte Readiness kann Traffic an kaputte Instanzen schicken.

Schlechte Liveness kann Restart-Loops verursachen.

Merksatz:

Health Checks beeinflussen direkt das Deployment-Verhalten.

50. Häufige Prüfungsfallen bei Observability

Beispiele für Fehler:

kein Actuator in Production
zu viele Actuator-Endpoints exponiert
kein Metrics-Dashboard
keine Alerts
Logs enthalten Secrets
Logs enthalten keine nützlichen IDs
hohe Kardinalität bei Metric-Tags
keine Correlation-ID
kein Tracing in verteilten Systemen
Health Checks hängen von zu vielen externen Systemen ab
Liveness und Readiness verwechselt
Debug-Endpoints öffentlich exponiert

Merksatz:

Observability muss nützlich und sicher sein.

51. Was reicht für die Spring-Professional-Prüfung?

Für die Prüfung solltest du verstehen:

Actuator purpose
starter-actuator dependency
/actuator base path
health endpoint
info endpoint
metrics endpoint
prometheus endpoint
loggers endpoint
mappings endpoint
beans endpoint
conditions endpoint
caches endpoint
scheduledtasks endpoint
endpoint exposure
endpoint security
health indicators
custom health indicators
Micrometer
metrics
Prometheus
logs
traces
correlation IDs
liveness vs readiness
production diagnostics

Merksatz:

Für die Prüfung: Wisse, was Actuator exponiert und warum das wichtig ist.

52. Actuator-Endpoint-Prüfungstabelle

Endpoint	Zweck
`health`	Anwendungsgesundheit
`info`	Anwendungsinformationen
`metrics`	Anwendungs-Metrics
`prometheus`	Prometheus-Scrape-Format
`loggers`	Log-Levels inspizieren/ändern
`mappings`	Request-Mappings
`beans`	Spring Beans
`conditions`	Auto-Konfigurations-Bedingungsbericht
`caches`	Cache-Informationen
`scheduledtasks`	Informationen zu geplanten Jobs
`env`	Environment Properties
`configprops`	Configuration Properties
`threaddump`	Thread Dump
`heapdump`	Heap Dump

Merksatz:

Kenn die wichtigsten Actuator-Endpoints und wobei jeder beim Debuggen hilft.

53. Echte Prüfungsfrage: Actuator

Frage:

Was ist Spring Boot Actuator?

Antwort:

Spring Boot Actuator liefert production-ready Features zum Monitoring und Management einer laufenden Spring-Boot-Anwendung — meist über Endpoints wie health, info, metrics, loggers, mappings und mehr.

54. Echte Prüfungsfrage: Health

Frage:

Was zeigt /actuator/health?

Antwort:

Es zeigt den Health-Status der Anwendung und — je nach Konfiguration — die Gesundheit von Komponenten wie Datenbank, Disk Space oder anderen Abhängigkeiten.

55. Echte Prüfungsfrage: Info

Frage:

Was zeigt /actuator/info?

Antwort:

Es zeigt beliebige Anwendungsinformationen wie Anwendungsname, Version, Beschreibung, Build-Daten oder Git-Informationen — falls konfiguriert.

56. Echte Prüfungsfrage: Metrics

Frage:

Was zeigt /actuator/metrics?

Antwort:

Es zeigt verfügbare Anwendungs-Metrics und lässt dich spezifische Metric-Werte inspizieren — z. B. HTTP-Requests, JVM-Speicher, CPU-Auslastung, Database-Connection-Pool-Metrics und Cache-Metrics.

57. Echte Prüfungsfrage: Prometheus

Frage:

Wofür wird /actuator/prometheus genutzt?

Antwort:

Es exponiert Anwendungs-Metrics in einem Format, das Prometheus scrapen kann.

58. Echte Prüfungsfrage: Micrometer

Frage:

Was ist Micrometer?

Antwort:

Micrometer ist eine Metrics-Fassade, die Spring Boot nutzt, um Metrics aufzuzeichnen und an Monitoring-Systeme wie Prometheus, Datadog, New Relic oder OTLP-kompatible Systeme zu exportieren.

59. Echte Prüfungsfrage: Observability

Frage:

Was sind die drei gängigen Säulen von Observability?

Antwort:

Logs, Metrics und Traces.

60. Echte Prüfungsfrage: Tracing

Frage:

Wobei hilft Tracing?

Antwort:

Tracing hilft, einen Request über Komponenten oder Services hinweg zu verfolgen — und zeigt, wo Zeit verbraucht wurde und wo Fehler aufgetreten sind.

61. Echte Prüfungsfrage: Actuator absichern

Frage:

Warum sollten Actuator-Endpoints abgesichert werden?

Antwort:

Weil sie sensible operative Informationen preisgeben können — z. B. Beans, Environment Properties, Mappings, Cache-Namen, Logger-Konfiguration und Systemdetails.

62. Interview-Antwort

Frage:

Wie überwachst du eine Spring-Boot-Anwendung?

Gute Antwort:

Ich füge meist Spring Boot Actuator hinzu und exponiere sichere Endpoints wie health, info, metrics und Prometheus. Ich nutze /actuator/health für Health Checks, /actuator/metrics für Runtime-Metrics und /actuator/prometheus für Prometheus-Scraping. Außerdem sammle ich Logs und nutze in verteilten Systemen Tracing mit Correlation-IDs, damit ich Requests über Services hinweg verbinden kann.

63. Interview-Antwort

Frage:

Was ist der Unterschied zwischen Logs, Metrics und Traces?

Gute Antwort:

Logs beschreiben, was als Ereignisse oder Meldungen passiert ist. Metrics liefern numerische Messwerte über die Zeit — z. B. Request-Anzahl, Latenz, Speicher und Fehlerraten. Traces zeigen den Pfad eines einzelnen Requests über Komponenten oder Services hinweg. In Production nutze ich alle drei zusammen, weil jede eine andere diagnostische Frage beantwortet.

64. Interview-Antwort

Frage:

Welche Actuator-Endpoints sind sicher zu exponieren?

Gute Antwort:

Das hängt von der Umgebung ab, aber in Production exponiere ich meist nur begrenzte Endpoints wie health, info und Prometheus — und sichere sie ordentlich ab. Sensible Endpoints wie env, beans, conditions, mappings, loggers, heapdump und threaddump sollten nicht öffentlich exponiert werden, weil sie interne Details oder sensible Informationen preisgeben können.

65. Interview-Antwort

Frage:

Wie würdest du einen langsamen Endpoint in Spring Boot debuggen?

Gute Antwort:

Zuerst prüfe ich Health, ob Abhängigkeiten verfügbar sind. Dann schaue ich auf HTTP-Request-Metrics — besonders Latenz und Fehlerrate für den Endpoint. Ich prüfe Database-Pool-Metrics, JVM-Metrics und Anwendungs-Logs. Wenn Tracing verfügbar ist, inspiziere ich den Trace für einen langsamen Request — um zu sehen, ob die Zeit im Controller, Service, in der Datenbank oder bei einer externen API verbraucht wird.

66. Kleine Code-Übung 1

Actuator hinzufügen.

Gradle:

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

Sichere Endpoints exponieren:

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

Frage:

Warum nicht alle Endpoints exponieren?

Antwort:


Weil manche Endpoints sensible interne Anwendungsinformationen preisgeben.

67. Kleine Code-Übung 2

App-Info hinzufügen.

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

Endpoint:


/actuator/info

Merksatz:

Der Info-Endpoint kann Anwendungs-Metadaten exponieren.

68. Kleine Code-Übung 3

Einen Custom Health Indicator erstellen.

@Component
public class SearchServiceHealthIndicator implements HealthIndicator {

    private final SearchClient searchClient;

    public SearchServiceHealthIndicator(SearchClient searchClient) {
        this.searchClient = searchClient;
    }

    @Override
    public Health health() {
        if (searchClient.isAvailable()) {
            return Health.up()
                    .withDetail("search", "available")
                    .build();
        }

        return Health.down()
                .withDetail("search", "unavailable")
                .build();
    }
}

Frage:

Wann ist das nützlich?

Antwort:

Wenn deine Anwendung von einer wichtigen Komponente abhängt, die Spring Boot nicht automatisch prüft.

69. Kleine Code-Übung 4

Einen Custom Counter erstellen.

@Service
public class TaskMetricsService {

    private final Counter createdTasksCounter;

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

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

Merksatz:

Custom Metrics messen Business-Events.

70. Kleine Bug-Übung 1

Problem:

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

Frage:

Was ist gefährlich?

Antwort:

Das exponiert alle Actuator-Endpoints über HTTP. Sensible Endpoints können interne Informationen preisgeben. Exponiere nur benötigte Endpoints und sichere sie ab.

71. Kleine Bug-Übung 2

Problem:

Counter.builder("login.attempts")
        .tag("email", email)
        .register(meterRegistry)
        .increment();

Frage:

Was ist falsch?

Antwort:

E-Mail hat hohe Kardinalität und ist sensibel. Das kann zu viele Metric-Series erzeugen und private Daten preisgeben. Nutze Tags mit niedriger Kardinalität wie status=success/failure.

72. Kleine Bug-Übung 3

Problem:

log.info("Authorization header: {}", authorizationHeader);

Frage:

Was ist falsch?

Antwort:

Authorization-Header können Bearer Tokens oder Credentials enthalten. Logge niemals Secrets.

73. Kleine Bug-Übung 4

Problem:

Liveness Probe prüft die Datenbank.
Datenbank hat kurzen Ausfall.
Kubernetes startet alle App-Pods neu.

Frage:

Was ist falsch?

Antwort:

Datenbank-Verfügbarkeit ist meist ein Readiness-Thema, nicht unbedingt Liveness. Schlechte Liveness-Checks können unnötige Restart-Loops verursachen.

Übungsfragen

Frage 1

Was ist Spring Boot Actuator?

Antwort:

Spring Boot Actuator liefert production-ready Monitoring- und Management-Endpoints für eine laufende Spring-Boot-Anwendung.

Frage 2

Was zeigt /actuator/health?

Antwort:

Es zeigt den Health-Status der Anwendung und ihrer Komponenten.

Frage 3

Was zeigt /actuator/info?

Antwort:

Es zeigt Anwendungs-Metadaten wie Name, Version, Beschreibung, Build-Info oder Git-Info — falls konfiguriert.

Frage 4

Was zeigt /actuator/metrics?

Antwort:

Es zeigt Runtime-Metrics wie HTTP-Requests, JVM-Speicher, CPU-Auslastung, Database-Connection-Pool-Metrics und Cache-Metrics.

Frage 5

Wofür wird /actuator/prometheus genutzt?

Antwort:

Es exponiert Metrics im Prometheus-Scrape-Format.

Frage 6

Was ist Micrometer?

Antwort:

Micrometer ist eine Metrics-Fassade, die Spring Boot nutzt, um Metrics aufzuzeichnen und an Monitoring-Systeme zu exportieren.

Frage 7

Was sind Logs?

Antwort:

Logs sind Ereignismeldungen, die erklären, was in der Anwendung passiert ist.

Frage 8

Was sind Metrics?

Antwort:

Metrics sind numerische Messwerte über die Zeit.

Frage 9

Was sind Traces?

Antwort:

Traces zeigen den Pfad eines Requests über Komponenten oder Services hinweg.

Frage 10

Was ist eine Correlation-ID?

Antwort:

Eine Correlation-ID verbindet Logs und Traces, die zum selben Request gehören.

Frage 11

Was ist der Unterschied zwischen Liveness und Readiness?

Antwort:

Liveness fragt, ob die App neu gestartet werden soll. Readiness fragt, ob die App Traffic empfangen soll.

Frage 12

Warum sollten Actuator-Endpoints abgesichert werden?

Antwort:

Weil sie sensible interne Informationen über Anwendung und Infrastruktur preisgeben können.

Frage 13

Warum sind Metric-Tags mit hoher Kardinalität gefährlich?

Antwort:

Sie erzeugen zu viele eindeutige Time Series, erhöhen den Speicherverbrauch, verlangsamen Monitoring-Queries und können sensible Daten preisgeben.

Frage 14

Welche Endpoints helfen beim Debuggen fehlender Routes?

Antwort:

/actuator/mappings.

Frage 15

Welche Endpoints helfen beim Debuggen von Auto-Konfiguration?

Antwort:

/actuator/conditions.

Frage 16

Welcher Endpoint hilft, geplante Jobs zu inspizieren?

Antwort:

/actuator/scheduledtasks.

Frage 17

Welcher Endpoint hilft, die Cache-Infrastruktur zu inspizieren?

Antwort:

/actuator/caches.

Frage 18

Was solltest du niemals loggen?

Antwort:

Passwörter, Tokens, API-Keys, Session-Cookies, Authorization-Header, Reset-Tokens, Kreditkartendaten und sensible personenbezogene Daten.

Frage 19

Wie würdest du eine langsame API debuggen?

Antwort:

Health prüfen, HTTP-Metrics, Database-Pool-Metrics, JVM-Metrics, Logs, Traces und kürzliche Deployment-/Config-Änderungen prüfen.

Frage 20

Was sind die drei Säulen von Observability?

Antwort:

Logs, Metrics und Traces.

76. Spring-Professional-Abschluss-Review

Dieses Buch hat die wichtigsten Spring-Professional-Themen abgedeckt.

Spring Core

IoC container
ApplicationContext
BeanFactory
beans
dependency injection
component scanning
@Configuration
@Bean
profiles
external configuration
bean scopes
bean lifecycle

Merksatz:

Spring erstellt und verdrahtet Objekte, damit die Anwendung lose gekoppelt ist.

Spring Boot

@SpringBootApplication
auto-configuration
starters
dependency management
externalized configuration
Actuator
application startup
runners
events
production features

Merksatz:

Spring Boot macht Spring-Anwendungen schneller konfigurierbar und production-ready.

Spring MVC

DispatcherServlet
controllers
@RequestMapping
@GetMapping
@PostMapping
@RequestBody
@ResponseBody
ResponseEntity
validation
exception handling
@ControllerAdvice
REST APIs

Merksatz:

Spring MVC mappt HTTP-Requests auf Controller-Methoden.

Spring Data JPA

JPA
Hibernate
entities
repositories
EntityManager
transactions
persistence context
dirty checking
relationships
lazy loading
fetch joins
projections
N+1 problem
@DataJpaTest

Merksatz:

Spring Data JPA vereinfacht Datenbankzugriff — aber du musst JPA-Verhalten trotzdem verstehen.

Transactions

@Transactional
rollback rules
runtime exceptions
checked exceptions
readOnly
propagation
isolation
persistence context
dirty checking
self-invocation
proxy-based behavior

Merksatz:

Transaktionen werden meist über Spring-Proxies angewendet.

Spring Security

SecurityFilterChain
authentication
authorization
UserDetailsService
PasswordEncoder
AuthenticationManager
roles
authorities
method security
@PreAuthorize
CSRF
CORS
sessions
stateless APIs
JWT
security testing

Merksatz:

Authentifizierung beweist Identität; Autorisierung prüft Berechtigung.

Testing

unit tests
JUnit
AssertJ
Mockito
@WebMvcTest
MockMvc
@DataJpaTest
TestEntityManager
@SpringBootTest
Testcontainers
spring-security-test
@WithMockUser
csrf()
jwt()

Merksatz:

Wähle den kleinsten Test, der das Verhalten beweist.

AOP

aspects
advice
pointcuts
join points
proxies
JDK dynamic proxy
CGLIB proxy
self-invocation
@Transactional
@Async
@Cacheable
method security

Merksatz:

Spring AOP funktioniert, wenn Aufrufe über den Proxy laufen.

Events

ApplicationEventPublisher
@EventListener
@TransactionalEventListener
AFTER_COMMIT
async event listeners
in-process events
event design
domain events

Merksatz:

Events sagen, dass etwas passiert ist.

Scheduling und Async

@Scheduled
@EnableScheduling
fixedRate
fixedDelay
cron
@Async
@EnableAsync
executors
thread pools
multi-instance scheduled jobs
idempotency

Merksatz:

Scheduling geht um Zeit; Async geht um Threads.

Caching

@EnableCaching
@Cacheable
@CachePut
@CacheEvict
cache names
cache keys
condition
unless
TTL
CacheManager
local cache
distributed cache
self-invocation

Merksatz:

Cache-Keys müssen alles enthalten, was das Ergebnis beeinflusst.

Observability und Actuator

Actuator
health
info
metrics
Prometheus
Micrometer
logs
traces
correlation IDs
mappings
beans
conditions
scheduledtasks
caches
endpoint security

Merksatz:

Production-Anwendungen brauchen Health, Logs, Metrics und Traces.

77. Prüfungs-Mindset

Für die Spring-Professional-Prüfung: Merke nicht nur Annotationen auswendig.

Verstehe:

Welches Problem löst dieses Feature?
Welche Spring-Komponente ermöglicht es?
Ist es proxy-basiert?
Spielt Self-Invocation eine Rolle?
Braucht es eine Spring Bean?
Passiert es vor oder nach dem Controller?
Passiert es innerhalb oder außerhalb einer Transaktion?
Ist es synchron oder asynchron?
Ist es lokal oder verteilt?
Was ist die Production-Falle?

Merksatz:

Spring-Prüfungsfragen testen oft Verhalten — nicht nur Annotation-Namen.

78. Zentrale Merksätze für die Prüfung

Merke dir diese:

Spring verwaltet Beans im ApplicationContext.

Dependency Injection reduziert Kopplung.

@Configuration und @Bean definieren Beans manuell.

Component Scanning entdeckt Beans automatisch.

Profiles wählen umgebungsspezifische Beans und Konfiguration.

Externe Konfiguration sollte nicht hardcodiert sein.

Spring Boot Auto-Konfiguration konfiguriert Beans basierend auf Classpath und Properties.

DispatcherServlet ist der Front Controller in Spring MVC.

@ControllerAdvice zentralisiert Exception Handling.

Bean Validation schützt Request-Grenzen.

JPA ist die Spezifikation; Hibernate ist die Implementierung.

Spring Data JPA erstellt Repository-Implementierungen.

@Transactional ist im Standard-Spring-Modus proxy-basiert.

Runtime Exceptions rollen standardmäßig zurück.

Persistence Context trackt verwaltete Entities.

Dirty Checking aktualisiert geänderte verwaltete Entities.

Lazy Loading braucht einen offenen Persistence Context.

N+1 passiert, wenn viele lazy Associations einzeln geladen werden.

Spring Security läuft vor Controllern.

Authentication bedeutet: Wer bist du?

Authorization bedeutet: Was darfst du?

401 bedeutet: nicht authentifiziert.

403 bedeutet: authentifiziert, aber verboten.

PasswordEncoder hasht und verifiziert Passwörter.

hasRole("ADMIN") prüft ROLE_ADMIN.

CSRF schützt browser-basierte, zustandsändernde Requests mit Cookies.

CORS steuert browser-seitigen Cross-Origin-Zugriff.

JWT ist signiert, nicht unbedingt verschlüsselt.

Unit Tests starten Spring nicht.

@WebMvcTest testet Controller.

@DataJpaTest testet Repositories.

@SpringBootTest lädt den vollen Application Context.

Spring AOP ist proxy-basiert.

Self-Invocation umgeht Proxy-Advice.

Events entkoppeln Reaktionen von Hauptaktionen.

@Scheduled führt Jobs nach Zeit aus.

@Async führt Arbeit in einem anderen Thread aus.

@Cacheable kann Methodenausführung überspringen.

Actuator exponiert Production-Diagnostik.

Logs sagen, was passiert ist.

Metrics zeigen Zahlen über die Zeit.

Traces zeigen Request-Pfade.

79. Abschluss

Wenn du dieses Buch verstehst, kannst du die Kern-Themen von Spring Professional erklären:

Spring Core
Spring Boot
Spring MVC
Spring Data JPA
Transactions
Spring Security
Testing
AOP
Events
Scheduling
Async
Caching
Actuator
Observability

Das ist eine starke Grundlage für die Spring-Professional-Prüfung und für echte Spring-Boot-Backend-Arbeit.

Abschlusssatz:

Du kennst nicht nur Spring-Annotationen.
Du verstehst, wie Spring dahinter funktioniert.

Ziel​

1. Überblick​

2. Was ist Spring Boot Actuator?​

3. Actuator-Dependency hinzufügen​

4. Actuator-Basis-Pfad​

5. Endpoint-Exposition​

6. Wichtige Production-Regel​

7. Health-Endpoint​

8. Health-Status​

9. Health-Details​

10. Health Indicators​

11. Custom Health Indicator​

12. Liveness und Readiness​

Liveness​

Readiness​

13. Info-Endpoint​

14. Metrics-Endpoint​

15. Was sind Metrics?​

16. Micrometer​

17. Prometheus​

18. Prometheus-Flow​

19. Custom Metrics​

20. Timer Metric​

21. Metric Tags​

22. Prüfungsfalle: hohe Kardinalität​

23. Logging​

24. Gutes Logging​

25. Keine Secrets loggen​

26. Log-Levels​

27. Loggers-Endpoint​

28. Tracing​

29. Span und Trace​

30. Correlation-ID​

31. Micrometer Tracing​

32. Observability: Logs, Metrics, Traces​

33. Actuator Mappings-Endpoint​

34. Actuator Beans-Endpoint​

35. Actuator Conditions-Endpoint​

36. Actuator Caches-Endpoint​

37. Actuator Scheduled Tasks-Endpoint​

38. Actuator Metrics-Endpoint​

39. HTTP-Request-Metrics​

40. Database-Pool-Metrics​

41. JVM-Metrics​

42. Production-Diagnostic-Flow​

43. Beispiel: API ist langsam​

44. Beispiel: App ist DOWN​

45. Beispiel: Endpoint fehlt​

46. Beispiel: Bean fehlt​

47. Actuator-Sicherheit​

48. Separater Management-Port​

49. Kubernetes Health Checks​

50. Häufige Prüfungsfallen bei Observability​

51. Was reicht für die Spring-Professional-Prüfung?​

52. Actuator-Endpoint-Prüfungstabelle​

53. Echte Prüfungsfrage: Actuator​

54. Echte Prüfungsfrage: Health​

55. Echte Prüfungsfrage: Info​

56. Echte Prüfungsfrage: Metrics​

57. Echte Prüfungsfrage: Prometheus​

58. Echte Prüfungsfrage: Micrometer​

59. Echte Prüfungsfrage: Observability​

60. Echte Prüfungsfrage: Tracing​

61. Echte Prüfungsfrage: Actuator absichern​

62. Interview-Antwort​

63. Interview-Antwort​

64. Interview-Antwort​

65. Interview-Antwort​

66. Kleine Code-Übung 1​

67. Kleine Code-Übung 2​

68. Kleine Code-Übung 3​

69. Kleine Code-Übung 4​

70. Kleine Bug-Übung 1​

71. Kleine Bug-Übung 2​

72. Kleine Bug-Übung 3​

73. Kleine Bug-Übung 4​

Übungsfragen​

Frage 1​

Frage 2​

Frage 3​

Ziel

1. Überblick

2. Was ist Spring Boot Actuator?

3. Actuator-Dependency hinzufügen

4. Actuator-Basis-Pfad

5. Endpoint-Exposition

6. Wichtige Production-Regel

7. Health-Endpoint

8. Health-Status

9. Health-Details

10. Health Indicators

11. Custom Health Indicator

12. Liveness und Readiness

Liveness

Readiness

13. Info-Endpoint

14. Metrics-Endpoint

15. Was sind Metrics?

16. Micrometer

17. Prometheus

18. Prometheus-Flow

19. Custom Metrics

20. Timer Metric

21. Metric Tags

22. Prüfungsfalle: hohe Kardinalität

23. Logging

24. Gutes Logging

25. Keine Secrets loggen

26. Log-Levels

27. Loggers-Endpoint

28. Tracing

29. Span und Trace

30. Correlation-ID

31. Micrometer Tracing

32. Observability: Logs, Metrics, Traces

33. Actuator Mappings-Endpoint

34. Actuator Beans-Endpoint

35. Actuator Conditions-Endpoint

36. Actuator Caches-Endpoint

37. Actuator Scheduled Tasks-Endpoint

38. Actuator Metrics-Endpoint

39. HTTP-Request-Metrics

40. Database-Pool-Metrics

41. JVM-Metrics

42. Production-Diagnostic-Flow

43. Beispiel: API ist langsam

44. Beispiel: App ist DOWN

45. Beispiel: Endpoint fehlt

46. Beispiel: Bean fehlt

47. Actuator-Sicherheit

48. Separater Management-Port

49. Kubernetes Health Checks

50. Häufige Prüfungsfallen bei Observability

51. Was reicht für die Spring-Professional-Prüfung?

52. Actuator-Endpoint-Prüfungstabelle

53. Echte Prüfungsfrage: Actuator

54. Echte Prüfungsfrage: Health

55. Echte Prüfungsfrage: Info

56. Echte Prüfungsfrage: Metrics

57. Echte Prüfungsfrage: Prometheus

58. Echte Prüfungsfrage: Micrometer

59. Echte Prüfungsfrage: Observability

60. Echte Prüfungsfrage: Tracing

61. Echte Prüfungsfrage: Actuator absichern

62. Interview-Antwort

63. Interview-Antwort

64. Interview-Antwort

65. Interview-Antwort

66. Kleine Code-Übung 1

67. Kleine Code-Übung 2

68. Kleine Code-Übung 3

69. Kleine Code-Übung 4

70. Kleine Bug-Übung 1

71. Kleine Bug-Übung 2

72. Kleine Bug-Übung 3

73. Kleine Bug-Übung 4

Übungsfragen

Frage 1

Frage 2

Frage 3