Kubernetes Monitoring: Logs und Metriken richtig einsetzen

Ein Kubernetes-Cluster läuft, die Deployments sind grün und trotzdem gibt es Probleme, die niemand früh genug erkennt. Der Grund ist meist kein fehlerhafter Code, sondern fehlendes oder schlecht konfiguriertes Kubernetes Monitoring. Wer nicht weiß, was in seinen Pods passiert, tappt im Dunkeln und reagiert auf Ausfälle, statt sie vorherzusehen. Dieser Artikel zeigt, wie Logs und Metriken zusammenspielen, wo die Unterschiede liegen und was ein solider Monitoring-Stack in der Praxis leisten muss.

Logs vs. Metriken. Zwei Werkzeuge, zwei Aufgaben

Logs und Metriken werden oft in einem Atemzug genannt, aber sie lösen unterschiedliche Probleme.

Metriken sind numerische Zeitreihendaten: CPU-Auslastung, Speicherverbrauch, Request-Rate, Fehlerquote. Sie eignen sich gut, um Trends zu erkennen, Schwellenwerte zu überwachen und Anomalien schnell zu sehen. Metriken sind kompakt und lassen sich effizient aggregieren.

Logs hingegen sind ereignisbasierte Textnachrichten. Sie enthalten den Kontext, den Metriken nicht haben: Welcher User hat welchen Request ausgelöst? Welcher Fehler ist in welcher Zeile aufgetreten? Was genau ist passiert, bevor die Anwendung abgestürzt ist?

Die einfache Faustregel: Metriken sagen dir, dass etwas nicht stimmt. Logs sagen dir, warum.

Wer nur Metriken hat, sieht den Alert, aber nicht die Ursache. Wer nur Logs hat, ertrinkt in Texten und findet keine Muster. Beides zusammen ergibt ein sinnvolles Bild.

Die drei Säulen der Observability

Observability ist mehr als nur Monitoring. Der Begriff beschreibt die Fähigkeit, den inneren Zustand eines Systems anhand seiner Ausgaben zu verstehen. In der Praxis basiert das auf drei Säulen:

1. Metriken – aggregierte Zahlen über Zeit
2. Logs – strukturierte oder unstrukturierte Ereignisprotokolle
3. Traces – verteilte Ablaufverfolgung über mehrere Services hinweg

Kubernetes Monitoring deckt vor allem die ersten beiden Säulen ab. Tracing kommt dazu, sobald mehrere Microservices miteinander kommunizieren und man nachvollziehen muss, welcher Service in einer Request-Chain wie lange gebraucht hat.

Für die meisten Teams ist der pragmatische Einstieg: Metriken und Logs zuerst in den Griff bekommen, Tracing später ergänzen, wenn Microservice-Komplexität wächst.

Kubernetes Monitoring mit Prometheus

Prometheus ist der De-facto-Standard für Metriken in Kubernetes-Umgebungen. Das Prinzip ist einfach: Prometheus scraped HTTP-Endpoints (/metrics) in definierten Intervallen und speichert die Daten als Zeitreihen in seiner eigenen Datenbank.

Zwei Komponenten liefern den Großteil der Kubernetes-Metriken:

• node_exporter – Hardware- und OS-Metriken vom Node: CPU, RAM, Disk I/O, Netzwerk
• kube-state-metrics – Kubernetes-spezifische Metriken: Pod-Status, Deployment-Replicas, Job-Erfolge, Ressourcenanfragen vs. -limits

Dazu kommen die Metriken der Anwendungen selbst. Wer eine Go- oder Java-Anwendung betreibt, kann mit einer Prometheus-Bibliothek eigene Metriken exposieren: Request-Latenzen, Queue-Größen, Business-Metriken.

Label Cardinality. Das unterschätzte Performance-Problem

Prometheus-Metriken werden durch Labels qualifiziert. Das ist mächtig, kann aber teuer werden. Wenn du beispielsweise eine User-ID oder eine Session-ID als Label verwendest, explodiert die Anzahl der Zeitreihen. Tausende oder Millionen verschiedene Labelwerte bedeuten tausende oder Millionen separate Zeitreihen – Speicherverbrauch und Query-Performance leiden erheblich.

Die Regel: Labels sollten eine überschaubare, begrenzte Menge an möglichen Werten haben. Statuscode (200, 404, 500), HTTP-Methode (GET, POST), Service-Name. Das sind sinnvolle Labels. User-IDs oder Request-IDs gehören in Logs, nicht in Metriken.

Log-Aggregation in Kubernetes

kubectl logs <pod> reicht für die Entwicklung. In der Produktion ist es eine Krücke.

Pods können jederzeit neu gestartet werden und mit ihnen sind die alten Logs weg. Wenn ein Pod crasht und sich neu startet, verlierst du genau die Logs, die du zur Fehleranalyse bräuchtest. Außerdem skalieren manuelle Log-Abfragen über viele Pods nicht.

Die Lösung ist Log-Aggregation: Alle Logs werden von einem Log-Collector (z. B. Fluent Bit oder Fluentd) eingesammelt, weitergeleitet und zentral gespeichert.

Für den zentralen Speicher gibt es zwei verbreitete Optionen:

• Loki (von Grafana Labs): schlanker, indexiert nur Metadaten (Labels), speichert Loginhalt komprimiert. Gut integriert mit Grafana, deutlich günstiger im Betrieb als Elasticsearch.
• Elasticsearch: mächtiger Volltext-Index, komplexere Abfragen möglich, aber ressourcenintensiver und operativ aufwendiger.

Für die meisten Kubernetes-Teams, die Grafana ohnehin nutzen, ist Loki die naheliegende Wahl. Elasticsearch lohnt sich, wenn komplexe Volltextsuche oder erweiterte Analysen benötigt werden.

Log-Level-Disziplin in der Produktion

Eine häufige Quelle von Problemen: Anwendungen, die in der Produktion mit Log-Level DEBUG laufen. Das Ergebnis sind Gigabytes an Logs pro Tag, die niemand liest, aber Speicher kosten und die Suche nach echten Fehlern erschweren.

Klare Konvention:

• DEBUG – nur in Entwicklung oder bei gezielter Fehlersuche
• INFO – wichtige Ereignisse, die den normalen Betrieb dokumentieren
• WARN – etwas Unerwartetes ist passiert, der Betrieb läuft noch
• ERROR – ein Fehler ist aufgetreten, der Aufmerksamkeit braucht

Und: Structured Logging ist unstrukturiertem Logging immer vorzuziehen. Wer Logs als JSON schreibt, kann sie in Loki oder Elasticsearch effizient filtern und abfragen. Freitext-Logs sind für Maschinen schwer zu verarbeiten.

Alerting: was wirklich alarmieren sollte

Ein Alert, dem niemand mehr Beachtung schenkt, ist schlechter als gar kein Alert. Alert Fatigue ist ein echtes Problem. Teams, die täglich Dutzende Benachrichtigungen bekommen, gewöhnen sich daran und übersehen irgendwann den kritischen.

Der Alertmanager in Prometheus ist das Standardwerkzeug, um Alerts zu empfangen, zu gruppieren, zu deduplizieren und weiterzuleiten (Slack, PagerDuty, E-Mail etc.).

Prinzipien für gutes Alerting:

Alertiere auf Symptome, nicht auf Ursachen. Ein Alert auf "hohe CPU" ist oft nutzlos. Hohe CPU ist kein Problem, solange die Anwendung antwortet. Besser: Alert auf Response-Zeit > 2 Sekunden oder Fehlerrate > 1%.

Nutze die vier goldenen Signale (aus dem Google SRE-Buch): Latenz, Traffic, Errors, Saturation. Das sind die Signale, die tatsächlich auf Nutzerprobleme hinweisen.

Definiere Alerting-Stufen. Nicht jeder Alert muss jemanden um 3 Uhr nachts wecken. Kritische Alerts gehen an PagerDuty, Warnungen gehen in einen Slack-Kanal.

Teste deine Alerts. Ein Alert, der noch nie ausgelöst hat, hat vielleicht auch noch nie die Chance gehabt – oder er ist kaputt.

Dashboards mit Grafana

Grafana ist das Standardtool für die Visualisierung von Prometheus-Metriken und Loki-Logs. Ein gutes Dashboard beantwortet auf einen Blick: Ist alles okay?

Was auf jedes Team-Dashboard gehört:

• Request-Rate – wie viele Requests bearbeitet der Service gerade?
• Error-Rate – wie viele davon schlagen fehl?
• Latenz – P50, P95, P99 Response Times (nicht nur Durchschnitt)
• Pod-Status – laufen alle Replicas, gibt es Restarts?
• Ressourcenauslastung – CPU und Memory vs. definierte Limits

Ein häufiger Fehler: Dashboards, die zu viel zeigen. Wenn 40 Graphen auf einem Screen sind, sieht niemand mehr etwas. Weniger ist mehr, ein fokussiertes Überblick-Dashboard, und Links zu Detail-Dashboards für spezifische Analysen.

Grafana bietet außerdem Annotations: Wann wurde ein neues Deployment ausgerollt? Diese Markierungen in Graphen helfen enorm, Performance-Änderungen mit Deployments zu korrelieren.

Kubernetes Monitoring auf einer DevOps-as-a-Service-Plattform

Einen eigenen Monitoring-Stack aufzubauen und zu betreiben ist möglich, aber aufwendig. Prometheus, Alertmanager, Loki, Fluent Bit, Grafana: Jede Komponente muss konfiguriert, gesichert, aktualisiert und skaliert werden. Das ist operativer Aufwand, der nicht direkt zum Produkt beiträgt.

Auf einer Kubernetes-DaaS-Plattform wie lowcloud ist Monitoring-Infrastruktur Teil der Plattform. Das bedeutet: Metriken für alle Workloads werden automatisch gesammelt, Logs werden aggregiert und durchsuchbar gemacht, grundlegende Alerts sind vorkonfiguriert. Teams können sich auf die Konfiguration ihrer eigenen Metriken und Alerts konzentrieren, statt den Stack selbst zu betreiben.

Das ist besonders relevant für kleinere Teams, die DevOps-Aufgaben nebenbei erledigen. Kubernetes Monitoring richtig hinzubekommen kostet Zeit – Zeit, die in Produktentwicklung investiert werden kann, wenn die Plattform die Grundlagen übernimmt.

Wer Kubernetes-Workloads auf lowcloud betreibt, bekommt Prometheus und Grafana als integrierte Services, konfigurierbar, aber ohne initialen Infrastrukturaufwand. Mehr dazu unter lowcloud.de.

Monitoring ist kein einmaliges Projekt, das man abhakt. Es ist ein laufender Prozess: Alerts schärfen, Dashboards anpassen, neue Services instrumentieren. Wer früh anfängt und strukturiert vorgeht, hat bei Vorfällen einen klaren Vorteil – und schläft nachts besser.