Plattformzustand erkennen und erklären
Vom technischen Signal zur belastbaren Reaktion
- Metriken
- Logs
- Policy-Ergebnisse
- Backup-Status
Workloads & Cluster
Komponenten, Kubernetes, Datenbanken und Gateways erzeugen Signale.
Prometheus & Alloy
Metriken werden abgefragt, Logs gesammelt und mit Kontext angereichert.
Prometheus & Loki
Zeitreihen und Protokolle bleiben für Analyse und Korrelation verfügbar.
Grafana & Alertmanager
Dashboards erklären den Zustand; Regeln melden relevante Abweichungen.
Gemeinsames Lagebild: Zustand, Ursache und Auswirkung werden über mehrere Signale hinweg nachvollziehbar.
Zielbild
Das Monitoring betrachtet nicht nur einzelne Pods. Es verbindet den Zustand des Kubernetes-Clusters mit den Signalen der Plattformkomponenten und ihrer Persistenz. Daraus entsteht eine durchgängige Kette:
- Komponenten und Infrastruktur erzeugen technische Signale.
- Sammler erfassen und strukturieren diese Signale.
- spezialisierte Systeme speichern und korrelieren Metriken und Logs.
- Dashboards und Regeln bewerten den Zustand.
- Meldungen werden an einen verantwortlichen Reaktionsweg übergeben.
Signalarten der Plattform
Metriken
Prometheus erfasst Zeitreihen aus Kubernetes und den angebundenen Diensten. Service- und Pod-Monitore binden Komponenten an; zusätzliche Exporter stellen unter anderem Informationen aus PostgreSQL und Patroni bereit. Die Metriken zeigen beispielsweise Verfügbarkeit, Ressourcenverbrauch, Neustarts, Fehlerraten und Speicherentwicklung.
Logs
Grafana Alloy sammelt Container-Logs im Cluster, ergänzt Kubernetes-Kontext und übergibt die Datensätze an Loki. Auch APISIX kann Zugriffsereignisse an Loki weiterreichen. So lassen sich auffällige Metriken mit den Protokollen des betroffenen Gateways, Dienstes oder Pods in Beziehung setzen.
Richtlinien- und Sicherheitsereignisse
Kyverno bewertet Kubernetes-Ressourcen gegen Plattformrichtlinien. Policy Reporter bündelt die Ergebnisse und kann sie in das gemeinsame Monitoring überführen. Diese Signale ergänzen die technische Laufzeitbeobachtung um den Zustand der Plattformregeln.
Backup- und Wiederherstellungsstatus
Für aktivierte Velero-Backups stellt die Plattform Prometheus-Regeln bereit. Zusammen mit Metriken aus Datenbanken und Storage entsteht ein Überblick darüber, ob Sicherungsläufe stattfinden und ob persistente Dienste erwartungsgemäß arbeiten.
Darstellung, Regeln und Benachrichtigung
Grafana Monitoring ist die zentrale Oberfläche für technische Dashboards und explorative Betriebsanalysen. Vorkonfigurierte Dashboards stellen Cluster-, Loki-, MinIO- und APISIX-Signale dar. Weitere Dashboards können abhängig vom Komponentenprofil ergänzt werden.
Prometheus-Regeln bewerten bekannte technische Zustände, etwa nicht bereite Workloads, häufige Pod-Neustarts oder fehlgeschlagene Backup-Läufe. Der Alertmanager gruppiert und routet daraus entstehende Meldungen an die für die Umgebung konfigurierten Empfänger.
Eine Meldung ist dabei nicht das Ende des Monitoringwegs. Sie sollte einen eindeutigen Dienst, eine technische Auswirkung und einen zuständigen Reaktionsweg erkennen lassen. Runbooks, Bereitschaft und Eskalation gehören zum Betrieb; diese Seite beschreibt die dafür benötigte Plattformarchitektur.
Aufbewahrung und Skalierung
Prometheus und Loki besitzen voneinander unabhängige Speicher- und Aufbewahrungsparameter. Replikate, Retention und persistenter Speicher werden passend zu Datenvolumen, Diagnosezeitraum und Verfügbarkeitsziel dimensioniert. Für eine längerfristige Metrikaufbewahrung kann Prometheus um ein externes Thanos-Backend ergänzt werden.
Monitoring muss selbst in die Kapazitäts- und Verfügbarkeitsplanung einbezogen werden: Eine längere Aufbewahrung, mehr Mandanten und zusätzliche Komponenten erhöhen sowohl das Signalvolumen als auch den Speicherbedarf.
Abgrenzung der Monitoringebenen
| Ebene | Leitfrage | Schwerpunkt |
|---|---|---|
| Plattformmonitoring | Laufen Cluster, Komponenten und technische Abhängigkeiten erwartungsgemäß? | Metriken, Logs, Regeln und Laufzeitereignisse |
| Sicherheitsbeobachtung | Werden Zugriffs- und Plattformrichtlinien eingehalten? | Gateway-Protokolle, Policy-Ergebnisse und Identitätsbezug |
| Datenmonitoring | Liefern Quellen und Datenprodukte vollständig und aktuell? | Aktualität, Qualität und fachliche Verfügbarkeit |
| Betriebsreaktion | Wer bewertet und behebt eine erkannte Abweichung? | Alarmwege, Runbooks, Eskalation und Nachbereitung |
Das Datenmonitoring ergänzt die technische Sicht um Datenaktualität und Sensorik. Die Sicherheitsarchitektur ordnet die sicherheitsbezogenen Signale in das plattformweite Schutzmodell ein.
Verantwortung und Konfiguration
Die UDSP-Automatisierung stellt den Observability-Stack, ausgewählte Exporter, Dashboards und Regeln reproduzierbar bereit. Im Inventory wird festgelegt, welche Bausteine aktiv sind, wie viel Speicher sie erhalten und wie lange Signale aufbewahrt werden. Die Betriebsorganisation definiert darauf aufbauend Empfänger, Reaktionszeiten und den Umgang mit Meldungen.
Die konkreten Parameter für Prometheus, Grafana, Alertmanager, Loki, Alloy und Velero sind unter Plattformbasis konfigurieren dokumentiert.