Kubernetes Monitoring ohne eigenen Monitoring-Stack

• Muss ich im Cluster etwas installieren?

  Nein. Logs liest Clusterward über die Kubernetes-API, die Auslastung über den metrics-server des Clusters, und die Uptime-Checks laufen von Clusterward aus. Ohne metrics-server zeichnet Clusterward nur die Zahl der Instanzen auf.

• Wie lange bleiben Logs erhalten?

  So lange der Pod existiert: den aktuellen Lauf und nach einem Absturz den vorherigen. Clusterward speichert Logs nicht dauerhaft. Wer Logs über Wochen braucht, lädt einen Zeitraum als Datei herunter oder nutzt zusätzlich ein zentrales Log-System.

• Warum sehe ich die Ursache eines Absturzes nicht im aktuellen Log?

  Weil der neu gestartete Container ein frisches Log beginnt. Setzen Sie im Log-Viewer den Haken „Previous run“ – dann zeigt Clusterward die Ausgabe des abgestürzten Containers, meist mit der Fehlermeldung am Ende.

• Sehe ich die Auslastung aller Cluster auf einen Blick?

  Ja, unter Infrastructure → Monitoring: eine Karte pro Scaleway-Projekt mit seinen Clustern (CPU und Speicher, genutzt und reserviert), jedem Node, den verwalteten Datenbank-Instanzen mit CPU, Speicher, Verbindungen und Plattenplatz sowie den Load Balancern mit ihrer öffentlichen Adresse. Die Karten werden alle 15 Sekunden neu gelesen; ein Hinweis oben auf jeder Karte nennt das Dringendste darin, etwa einen Node, der nicht bereit ist. Die Seite braucht nur das Leserecht für Operations.

• Wo sehe ich alle Services und Uptime-Checks auf einmal?

  Unter Infrastructure → Monitoring. „Services“ listet jeden deployten Service mit CPU, Speicher und Neustarts der letzten 24 Stunden, die nächsten am Limit zuerst, mit seinen Instanzen einen Klick entfernt. „Uptime“ zeigt jeden Check mit seinem 24-Stunden-Balken, Verfügbarkeit und Antwortzeit, ausgefallene und langsame zuerst – dazu die Services, die noch niemand überwacht.

• Kann ein KI-Assistent Logs und Auslastung auswerten?

  Ja, wenn Sie es erlauben. Ein verbundener Assistent liest Auslastung, Uptime-Checks und die letzten 24 Stunden, Logs nur mit dem eigenen Schalter „Also service logs“. Fertige Prompts wie Uptime-Bericht oder Kapazitäts-Check fassen das in einer Antwort zusammen.

• Was prüft ein Uptime-Check genau?

  Einen GET über HTTPS auf eine Domain des Services, mit dem Pfad Ihrer Wahl, zum Beispiel / oder /up. Als erreichbar gilt eine Antwort unter 400 oder genau der Status, den Sie erwarten. Eine Zeitüberschreitung nach 10 Sekunden oder ein Zertifikatsfehler zählt als Ausfall.

• Wann bekomme ich einen Alarm?

  Nach zwei Fehlschlägen in Folge meldet Clusterward die Seite an Ihre Kanäle als nicht erreichbar, nach dem ersten Erfolg als wieder erreichbar. Welche Kanäle das sind, legen Sie unter Benachrichtigungen fest.

• Prüfen die Checks aus mehreren Regionen?

  Nein, aus einer Region: von dort, wo Clusterward läuft. Ein Check sagt Ihnen, dass die Seite für alle nicht antwortet, die sie auf demselben Weg erreichen – nicht, ob sie in jeder Region der Welt ausfällt.

• Was bedeuten die gestrichelten Linien in der Auslastung?

  Die graue Linie ist die Reservierung des Services, die rote sein Limit, jeweils mal der laufenden Instanzen. Läuft der Speicher am Limit entlang und häufen sich Neustarts, fehlt dem Service Speicher.

• Ersetzt das Prometheus und Grafana?

  Für die Frage „läuft mein Service, und wie war er ausgelastet“ meist ja. Eigene Anwendungsmetriken, Dashboards über viele Services und Logs über Monate bleiben die Stärke eines eigenen Monitoring-Stacks.

• Bekommen meine Kunden eine Status-Seite?

  Die Uptime-Checks am Service melden Ausfälle an Ihr Team. Eine öffentliche Status-Seite für Ihre Kunden bringt Uptime Kuma aus dem App-Katalog: ein eigener Monitor in Ihrem Cluster, angelegt mit Name, Domain und Cluster, der auch Dienste außerhalb von Clusterward prüft.

Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.