Wenn etwas hakt, wollen Sie drei Dinge sehen: was die Anwendung gerade schreibt, wie sie ausgelastet war und ob sie von außen erreichbar ist. Clusterward zeigt alles an jedem Service – Logs aller Instanzen, CPU und Speicher über 30 Tage und Uptime-Checks mit Alarm. Ohne Agent im Cluster und ohne Grafana-Setup.
Kubernetes Monitoring in Clusterward besteht aus drei Teilen am Service: einem Log-Viewer, der die Ausgaben aller Instanzen nach Zeit zusammenführt, einem Auslastungsverlauf für CPU, Speicher und Instanzen, den Clusterward jede Minute selbst aufzeichnet, und Uptime-Checks, die Ihre Domains von außen prüfen. Fällt etwas aus, melden sich Benachrichtigungen – und der Link führt direkt zu den Logs.
Ein Uptime-Check schlägt zweimal fehl oder ein Deployment scheitert – die Nachricht geht an Ihre Kanäle.
Ein Klick in der Aktivitätsanzeige öffnet die Logs, bei einem Absturz direkt den vorherigen Lauf.
Suchen, nur Fehler zeigen, Zeitraum wählen, die Auslastung daneben ansehen.
Speicher erhöhen, neu starten oder eine frühere Version wiederherstellen.
Das, was Sie bei einer Störung zuerst brauchen, an dem Service, um den es geht.
Die Ausgaben aller Instanzen eines Services, nach Zeit zusammengeführt, mit Markierung, von welcher Instanz jede Zeile stammt. Oder eine Instanz allein.
Die letzten 500 Zeilen, 15 Minuten, eine Stunde, 6 oder 24 Stunden – bis 10.000 Zeilen, flüssig scrollbar. Oder live mitlesen.
Treffer werden markiert, Sie springen von einem zum nächsten. „Errors only“ blendet alles andere aus.
Ist ein Container abgestürzt und neu gestartet, zeigt Clusterward die Logs des abgestürzten Laufs – dort steht meist die Ursache.
CPU und Speicher in Prozent des Limits, dazu die Instanzen, jede Minute aufgezeichnet, von 15 Minuten bis 30 Tage. Reservierung als Linie, Neustarts als Markierung, ein Klick öffnet das Diagramm groß mit aktuellem, mittlerem und Spitzenwert – auch für Helm-Services.
Prüft eine Domain des Services per HTTPS, mit Pfad und erwartetem Status. Verfügbarkeit über 24 Stunden und 7 Tage, dazu die mittlere Antwortzeit.
Zwei Fehlschläge in Folge melden die Seite als nicht erreichbar, der erste Erfolg danach als wieder da. Einmal pro Ereignis, nicht als Flut.
Der gewählte Zeitraum als .log-Datei, zum Weitergeben an Entwickler oder Support.
Ein ausgefallener Check steht in der Aktivitätsanzeige des Cockpits, bis er wieder antwortet.
Logs kommen direkt von den Pods über die Kubernetes-API – nichts wird im Cluster installiert.
CPU und Speicher liefert der metrics-server des Clusters; ohne ihn zeichnet Clusterward die Instanzen auf.
Checks senden einen GET über HTTPS, folgen keinen Weiterleitungen und werten Zertifikatsfehler als Ausfall.
Alarme laufen über die Benachrichtigungen: Slack, Teams, Webhook oder E-Mail.
Clusterward speichert Auslastung und Check-Ergebnisse selbst; Logs liest es live aus dem Cluster.
| Daten | Auflösung | Wie lange |
|---|---|---|
| Logs | Jede Zeile | So lange der Pod lebt (letzter und vorheriger Lauf) |
| Auslastung, 24 Stunden | Pro Minute | 24 Stunden |
| Auslastung, 7 Tage | Pro 10 Minuten | 7 Tage |
| Auslastung, 30 Tage | Pro Stunde | 30 Tage |
| Uptime-Ergebnisse | Jede Prüfung | 7 Tage |
| Benachrichtigungen | Jede Nachricht | 30 Tage im Zustellprotokoll |
Wohin Alarme gehen und welche Ereignisse sich melden, stellen Sie unter Benachrichtigungen ein. Wie ein gescheitertes Rollout erkannt wird und wie Sie zu einer früheren Version zurückkehren, steht unter Deployments.
Was die Übersicht für die technische Leitung bedeutet, beschreibt Für CTOs; welche Nachweise die Protokolle für ein Audit liefern, Audit & NIS2.
Was kubectl kann, wo es aufhört und wann sich ein eigener Stack lohnt, beschreibt Logs, Auslastung und Uptime ohne eigenen Monitoring-Stack; wie Sie nach einem fehlerhaften Release zurückkommen, Rollback auf Kubernetes: Warum ein Tag keine Version ist.
Webhook, Slack, Teams oder E-Mail – einmal pro Ereignis.
Zu BenachrichtigungenGit, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsPlanbare Kosten, kein Kopfmonopol, kein Lock-in.
Zu Für CTOsIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir lassen einen Service abstürzen, finden die Ursache im vorherigen Lauf und richten einen Uptime-Check mit Alarm in Ihrem Slack ein.
