Logs, Auslastung und Uptime ohne eigenen Monitoring-Stack
Bei einer Störung zählen drei Fragen: Was schreibt die Anwendung, wie war sie ausgelastet, ist sie von außen erreichbar? Dafür braucht nicht jedes Team einen eigenen Monitoring-Stack.
Bei einer Störung stellen sich immer dieselben drei Fragen. Was schreibt die Anwendung gerade? Wie war sie in den letzten Stunden ausgelastet? Und ist sie von außen überhaupt erreichbar? Die übliche Antwort auf alle drei ist ein Monitoring-Stack: Prometheus, Grafana, Loki, Alertmanager. Für große Plattform-Teams ist das richtig. Für ein Team mit einer Handvoll Services ist es oft ein zweites Projekt, das gepflegt werden will, bevor es die erste Frage beantwortet.
Frage 1: Was schreibt die Anwendung?
kubectl logs liest die Ausgabe eines Containers. Das reicht bei einer Instanz. Bei drei Instanzen wird es mühsam, und die nützlichsten Optionen kennen die wenigsten:
kubectl logs -l app=web --prefix --timestampsliest alle Pods mit dem Label und markiert, woher jede Zeile kommt. Standardmäßig höchstens fünf Pods gleichzeitig, mehr mit--max-log-requests.--since=1hbegrenzt auf die letzte Stunde,--tail=500auf die letzten Zeilen.--previousliest den vorherigen Lauf eines Containers. Das ist die wichtigste Option überhaupt: Stürzt ein Container ab und startet neu, beginnt er ein frisches Log. Die Fehlermeldung, die zum Absturz führte, steht nur im vorherigen Lauf.
Die Grenzen: Die Zeilen mehrerer Pods kommen nicht nach Zeit sortiert, Suchen heißt grep, und wer kein kubectl mit Clusterzugang hat, sieht gar nichts. Und Logs leben so lange wie der Pod. Ist er weg, sind sie es auch.
Frage 2: Wie war die Auslastung?
kubectl top pods zeigt CPU und Speicher, geliefert vom metrics-server. Aber nur jetzt. Die Frage bei einer Störung lautet fast immer: Wie sah es vor einer Stunde aus, als es anfing? Dafür braucht es einen Verlauf, und den speichert der metrics-server nicht.
Was ein Verlauf zeigen sollte, damit er bei der Ursachensuche hilft:
- CPU und Speicher pro Service, nicht nur pro Pod
- die Reservierung und das Limit als Linie, denn ein Speicher am Limit ist der häufigste Grund für Neustarts
- Neustarts als Markierung auf der Zeitachse
- mindestens eine Woche zurück, besser einen Monat, um Muster zu sehen
Das Muster, das man am häufigsten findet: Speicher steigt langsam, erreicht das Limit, der Container wird beendet, startet neu, Speicher fällt, steigt wieder. Im Verlauf sieht das aus wie ein Sägezahn mit roten Markierungen. Ohne Verlauf sieht es aus wie gelegentliche, unerklärliche Neustarts.
Frage 3: Ist die Anwendung erreichbar?
Pods, die laufen, heißen nicht, dass die Anwendung antwortet. Ein falsches Zertifikat, ein Ingress ohne Regel, ein DNS-Record, der ins Leere zeigt: Alles läuft, und niemand kommt an. Das sieht nur, wer von außen prüft, über dieselbe Adresse wie die Nutzer.
Ein guter Uptime-Check:
- prüft per HTTPS die echte Domain, nicht eine interne Adresse
- wertet Zertifikatsfehler und Zeitüberschreitungen als Ausfall
- schlägt erst nach zwei Fehlschlägen in Folge Alarm, nicht bei einem einzelnen Aussetzer
- meldet auch, wenn es wieder geht, damit niemand weiter sucht
Wann sich ein eigener Stack lohnt
Prometheus, Grafana und Loki sind hervorragend. Sie lohnen sich, wenn Sie eigene Anwendungsmetriken auswerten wollen (Bestellungen pro Minute, Warteschlangenlänge), Dashboards über viele Services brauchen, Logs über Monate durchsuchen müssen oder Tracing über mehrere Dienste. Der Preis: Speicher und CPU im Cluster, Aufbewahrung, Upgrades, und jemand, der das alles pflegt. Wer ehrlich ist, merkt oft, dass die drei Fragen oben neunzig Prozent der Fälle abdecken.
Ein typischer Fall
Montagmorgen, eine Kundin meldet, dass der Export seit dem Wochenende manchmal abbricht. Kein Alarm, alle Pods laufen. Der Ablauf mit den drei Antworten:
- Auslastung ansehen. Der Speicherverlauf der letzten sieben Tage zeigt einen Sägezahn: Speicher steigt über Stunden bis an das Limit, fällt schlagartig, steigt wieder. Darunter rote Markierungen, jeweils ein Neustart.
- Vorherigen Lauf lesen. Die aktuellen Logs zeigen nichts Auffälliges, der Container ist ja frisch. Der vorherige Lauf endet mitten in einem Export, der Pod-Status nennt als Grund
OOMKilled, Exit-Code 137. - Ursache. Der Export lädt alle Datensätze eines Kunden auf einmal in den Speicher. Bei kleinen Kunden egal, beim größten Kunden sprengt er das Limit.
Kurzfristig mehr Speicher, langfristig ein Export in Stapeln. Ohne Verlauf und ohne vorherigen Lauf wäre das ein Rätsel über Tage geblieben.
Log-Zeilen, die bei der Suche helfen
Die beste Oberfläche hilft wenig, wenn die Logs nichts sagen. Vier Regeln:
- Eine Zeile pro Ereignis. Mehrzeilige Ausgaben nur für Stacktraces, und die gehören direkt unter die Fehlerzeile.
- Level am Anfang.
ERROR,WARN,INFOmachen einen Fehlerfilter erst möglich. - Eine Request-ID. Wer sie in jede Zeile schreibt, findet alle Zeilen einer Anfrage über alle Instanzen hinweg.
- Keine Geheimnisse. Keine Passwörter, Tokens oder vollständigen Connection-Strings, auch nicht beim Debuggen. Logs landen in Downloads, Tickets und Chats.
Alarme, die niemand ignoriert
Ein Alarm, der zehnmal am Tag grundlos auslöst, wird nach einer Woche ignoriert, auch am Tag, an dem er stimmt. Deshalb: erst nach zwei Fehlschlägen in Folge alarmieren, eine Nachricht pro Ausfall statt pro Prüfung, eine Entwarnung, wenn es wieder geht, und ein Team-Kanal statt einer persönlichen Adresse.
Wie Clusterward die drei Fragen beantwortet
Am Service im Cockpit: Die Logs aller Instanzen nach Zeit zusammengeführt, mit Zeiträumen bis 24 Stunden, bis zu 10.000 Zeilen, Suche mit Sprung zum nächsten Treffer, „Errors only“, dem vorherigen Lauf eines abgestürzten Containers und Download als Datei. Die Auslastung für CPU, Speicher und Instanzen zeichnet Clusterward jede Minute selbst auf und zeigt sie über 24 Stunden, 7 oder 30 Tage, mit Reservierung, Limit und Neustarts. Uptime-Checks prüfen die Domains des Services per HTTPS und melden Ausfälle an Slack, Teams, Webhook oder E-Mail. Kein Agent im Cluster, nichts zu installieren. Die Übersicht steht unter Logs & Monitoring, die Alarmkanäle unter Benachrichtigungen. Und wenn die Logs zeigen, dass das letzte Release schuld ist: Rollback auf Kubernetes: Warum ein Tag keine Version ist.
Was es bewusst nicht ist: ein Log-Archiv über Monate oder ein Werkzeug für eigene Anwendungsmetriken. Wer das braucht, ergänzt einen Stack und behält die drei Antworten trotzdem am Service.
Fazit
Bei einer Störung zählen drei Antworten: die Logs aller Instanzen samt vorherigem Lauf, der Verlauf der Auslastung und ein Check von außen. Sorgen Sie dafür, dass Ihr Team diese drei in einer Minute hat. Ob dahinter ein eigener Monitoring-Stack steht oder nicht, ist die zweite Frage.
Monitoring für Ihre Services? Beschreiben Sie uns Ihre Anwendungen und was Sie heute bei einer Störung zuerst tun. Wir zeigen, was davon ohne eigenen Stack geht. Frage stellen →
Quellen und weiterführende Links
Häufige Fragen
- Mit kubectl logs --previous lesen Sie den vorherigen Lauf eines Containers. Das ist entscheidend, weil ein abgestürzter Container nach dem Neustart ein frisches Log beginnt. Die Fehlermeldung, die zum Absturz führte, steht nur im vorherigen Lauf, nicht in den aktuellen Logs.