Zum Inhalt springen

Monitoring & Health-Checks

Admin

Den Zustand der Anwendung im Web-/Server-Betrieb überwachen: über HTTP-Health-Endpunkte, OpenTelemetry-Telemetrie und die in der App sichtbaren Audit-Protokolle.

EndpunktZweckInhalt
/healthGesamtstatusalle Prüfungen müssen grün sein
/aliveLivenessnur als „live” markierte Prüfungen (App reagiert?)
/readyReadinessnur als „ready” markierte Prüfungen (Traffic annehmbar?)

Registriert in den ServiceDefaults (MapDefaultEndpoints). Der Docker-HEALTHCHECK prüft /alive alle 30 s (15 s Startkarenz). In Kubernetes eignen sich /alive als Liveness- und /ready als Readiness-Probe.

Zusätzliche Prüfungen je nach Konfiguration: SMTP (Start-Probe), Qdrant, Presidio.

Health-Endpunkte und Telemetrie-Export im Überblick. Health-Endpunkte und Telemetrie-Export im Überblick.

Exportiert Metriken (ASP.NET-Core-, HTTP-Client- und Runtime-Instrumentierung), Traces (Requests/HTTP-Aufrufe; Health-Pfade ausgenommen) und Logs. Der Export ist aktiv, sobald OTEL_EXPORTER_OTLP_ENDPOINT gesetzt ist (OTLP, z. B. auf einen Collector/das Aspire-Dashboard). Optional ist eine Sentry-Anbindung (DSN-gesteuert).

Desktop: keine Health-Endpunkte; Beobachtung über die App-Tabs (Nutzung, Audit, Dienst-Status) und lokale Logs.

  • curl http://<host>:8080/alive → HTTP 200; /ready → 200, sobald Abhängigkeiten bereit sind.
  • Telemetrie erscheint im Collector/Dashboard (wenn OTLP-Endpoint gesetzt).
  • /ready bleibt 503 – eine „ready”-Prüfung (z. B. Datenbank) schlägt fehl; Logs prüfen.
  • Keine Telemetrie – OTEL_EXPORTER_OTLP_ENDPOINT fehlt/falsch oder Collector nicht erreichbar.
  • Presidio „nicht erreichbar” – PII-Pseudonymisierung degradiert; siehe Presidio einrichten.