Workloads & Logs überwachen

Zustand, Events und Anwendungslogs prüfen; sinnvolle Alarme und Metrikgrenzen festlegen.

AnleitungTechnische Referenz · nicht für Cloud-UI erforderlichLesezeit · ca.8 MinutenAktualisiert22. Oktober 2026

Gültigkeit dieser AnleitungEnterprise-Referenz

Für Enterprise Self-Hosted oder eine eigens vereinbarte technische Evaluation. Keine Cloud-Kundenanleitung.

Bevor Sie starten

Sie haben einen bereitgestellten Pilotcluster, eine vertrauenswürdige kubeconfig, kubectl und Zugriff auf einen vereinbarten Namespace. Setzen Sie KUBECONFIG, CP_CONTEXT und CP_NAMESPACE über die Zugangsanleitung, bevor Sie Befehle ausführen. Die Beispiele verwenden eine POSIX-Shell und eine einzelne Zugangsdatei. Gruppierte Blöcke stoppen bei fehlenden Einstellungen, ohne Ihr Terminal zu schließen; sie stellen keine Infrastruktur bereit und vergeben keine Rechte. Mit dem Cluster verbinden →

Bestätigen Sie Leserechte für Events und Anwendungslogs. Dashboards, Metrikaufbewahrung, Log-Aggregation und Betreiberalarme sind nur bei Qualifizierung und Vereinbarung enthalten.

Mit Anwendungszustand beginnen

Kleine Workload-Zustandsprüfung

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get deployment/cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get pods -l app=cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get events --field-selector type=Warning --sort-by=.metadata.creationTimestamp
)

Vergleichen Sie gewünschte/verfügbare Replikate, Readiness und Neustartanzahl. Ein laufender Container kann trotzdem unready sein oder Fehler ausliefern. Prüfen Sie Anwendungsantwort und einen repräsentativen Nutzerablauf als separates Signal. Events sind Diagnosebeobachtungen mit begrenzter Aufbewahrung, kein Störungsarchiv.

Begrenzte Logs lesen

Aktuelle Anwendungslogs · lokal prüfen

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" logs -l app=cloud-demo --all-containers=true --prefix=true --since=15m --tail=100 --limit-bytes=32768
)

Wählen Sie relevanten Container und Zeitraum. Bei einem neu gestarteten Container nutzen Sie, falls noch verfügbar, die vorherige Instanz:

Vorherige Instanz · Podnamen ersetzen

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
export CP_POD="YOUR_POD_NAME"
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" logs "$CP_POD" -c app --previous --tail=100 --limit-bytes=32768
)

Metriken bei verfügbarer API nutzen

Optionale Ressourcenmetriken

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" top pods --containers
)

Dies benötigt eine funktionierende Metrics API und Leserechte. „Metrics API not available“ belegt weder Nullverbrauch noch einen Workload-Ausfall. Klären Sie, ob Metriken enthalten und qualifiziert sind. Eine kurze top-Stichprobe ist keine historische Sizing-Analyse; verbinden Sie vereinbarte Zeitreihen mit Lasttests und Anwendungs-Latenz-/Fehlermessungen.

Compute & Speicher planen →

Alarme mit Zuständigkeit definieren

Signal	Zu vereinbarende Reaktion
Anfragefehler / Latenz	Anwendungsverantwortlicher prüft Abhängigkeit, Release und Fehlerrate anhand vereinbarter Grenze.
Replikatverlust / wiederholte Neustarts	Workload-Zustand prüfen und Infrastrukturhinweise über den Pilotkanal eskalieren.
Storage-Wachstum / Backup-Alter	Grenze, verbleibende Kapazitätszeit und tatsächlichen Umfang des Schutzdienstes bestätigen.
Zertifikatsablauf	Verantwortlichen für Erneuerung benennen und Ersatz vor Ablauf prüfen.

Vereinbaren Sie Empfänger, Abdeckungszeiten, Eskalationsweg und Reaktionserwartung je Alarm. Ein eingerichtetes Dashboard bedeutet keinen personell besetzten 24/7-Störungsdienst.

Support gezielt anfragen →

Technische Referenzen (Englisch)

Kubernetes beschreibt hier das technische Verhalten. Der für Ihren Cluster bestätigte Funktionsumfang steht in Ihrer Pilotvereinbarung.

Diese Anleitung gilt für Ihren vereinbarten Pilotumfang. Technische Kubernetes-Beispiele sind kein Nachweis einer allgemein verfügbaren Cloud-Funktion.