Actuator, Micrometer und OpenTelemetry Observability

• Actuator Endpoints wie health, info, metrics, env.
• Micrometer als Metrics Facade.
• Observation API für Metriken und Traces.
• Tracing mit TraceId/SpanId.
• Readiness und Liveness getrennt prüfen.

• Du betreibst Services auf Kubernetes/OpenShift.
• Du brauchst SLOs, Dashboards und Alerts.
• Du willst Fehler in verteilten Aufrufen nachvollziehen.

• Alle Actuator Endpoints öffentlich machen.
• Metriken ohne Tags-Disziplin und Kardinalitätskontrolle.
• Health Check prüft Downstream-Systeme zu hart und verursacht Kaskadenfehler.

Alte Logfile- und JMX-Sicht wird durch Health, Metrics, Traces und strukturierte Logs ergänzt.

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

@Component
class PaymentObservationService {
    private final ObservationRegistry registry;

    PaymentObservationService(ObservationRegistry registry) { this.registry = registry; }

    PaymentResult observePayment(Supplier<PaymentResult> paymentCall) {
        return Observation.createNotStarted("payment.authorization", registry)
            .lowCardinalityKeyValue("provider", "internal-payments")
            .observe(paymentCall);
    }
}

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus
  endpoint:
    health:
      probes:
        enabled: true

• Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
• Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
• Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
• Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?