Kubernetes Monitoring mit Prometheus, Grafana & Loki

Warum reichen kubectl logs und kubectl top nicht aus, sobald ein Cluster mehr als eine Handvoll Services betreibt? Dieses Modul zeigt den Unterschied zwischen Monitoring (was passiert?) und Observability (warum passiert es?) und stellt den Stack vor, den Sie in den nächsten vier Tagen aufbauen: Prometheus für Metriken, Grafana für Visualisierung und Alerting, Loki mit Grafana Alloy für Logs. Am Ende haben Sie eine klare Vorstellung der Architektur und wissen, welche Komponente welche Aufgabe übernimmt.

Sie installieren den kube-prometheus-stack per Helm Chart, der Prometheus, Alertmanager, Grafana, Node Exporter und kube-state-metrics in einem Schritt bereitstellt. Im Zentrum steht der darin enthaltene Prometheus Operator, dessen Custom Resource Definitions (ServiceMonitor, PodMonitor, PrometheusRule) Sie anschließend im Detail kennenlernen. Am Ende konfigurieren Sie die automatische Service-Discovery, die neue Scrape-Targets erkennt, sobald ein Service deployt wird.

Der Grafana Operator verwaltet Dashboards und Datasources als Kubernetes-Ressourcen, ideal für GitOps-Workflows mit ArgoCD oder Flux. Die Installation per Helm Chart ist schneller aufgesetzt, erfordert aber manuelle Dashboard-Pflege. Sie installieren beide Varianten, importieren ein Dashboard jeweils per GrafanaDashboard-CR und per ConfigMap, und entscheiden anschließend, welcher Ansatz zu Ihrem Team passt.

Jetzt wird es praktisch: Sie prüfen die Scrape-Konfiguration des Prometheus Operators, importieren ein erstes Dashboard in Grafana und analysieren CPU, RAM und Netzwerk-Metriken Ihres Clusters. Dabei lernen Sie die vier Metriktypen (Counter, Gauge, Histogram, Summary) an realen Beispielen kennen und verstehen, wann welcher Typ die richtige Wahl ist.

Wie sammelt Loki Logs, ohne sie zu indexieren, und warum macht das den Stack so speichereffizient? Sie installieren Loki in Ihrem Kubernetes-Cluster, konfigurieren Grafana Alloy als Log-Collector und sehen, wie Log Streams strukturiert, gesammelt und in Grafana dargestellt werden. Der Fokus liegt auf der Architektur (Distributor, Ingester, Querier) und dem Zusammenspiel mit Prometheus-Metriken.

Promtail hat am 2. März 2026 sein End-of-Life erreicht. Grafana Alloy übernimmt als einheitlicher Telemetrie-Collector für Logs, Metriken und Traces. Sie migrieren eine bestehende Promtail-Konfiguration nach Alloy, nutzen den integrierten convert-Befehl und konfigurieren erste Pipeline-Stages für Log-Transformation. Dabei sehen Sie, wie Alloy durch sein modulares Dataflow-Modell und OpenTelemetry-Kompatibilität deutlich flexibler als sein Vorgänger ist.

Wie überwachen Sie eine Anwendung, die keine eigenen Metriken exportiert? Sie konfigurieren individuelle Scrape-Jobs über ServiceMonitor-Ressourcen, instrumentieren eine Beispiel-Anwendung mit dem Prometheus Client und erstellen Custom Metrics für anwendungsspezifische KPIs. Best Practices zu Namenskonventionen, Label-Kardinalität und effizientem Metrik-Design runden die Session ab.

Sie schreiben PromQL-Abfragen für reale Monitoring-Szenarien: Vektor-Selektoren mit Label-Matchern, Range Queries für Trend-Analysen und Aggregationen über mehrere Services hinweg. Dabei lernen Sie auch die Breaking Changes in Prometheus 3.0 kennen: der Regex-Operator .* matcht jetzt Newlines, und Metrik-Namen unterstützen UTF-8-Zeichen. Beides kann bestehende Abfragen und Alerting-Regeln unbemerkt verändern. Am Ende optimieren Sie langsame Abfragen durch Recording Rules und verstehen, wann Subqueries sinnvoll sind.

Ein Dashboard, das niemand nutzt, ist Zeitverschwendung. Deshalb bauen Sie hier ein Kubernetes-Namespace-Dashboard von Grund auf: mit Template-Variablen für Namespace- und Service-Filter, sodass ein Dashboard für alle Teams funktioniert, statt ein eigenes pro Service zu pflegen. Sie arbeiten mit Transformationen für berechnete Felder (z.B. Error-Rate aus zwei Metriken), setzen Annotations für Deployment-Marker und lernen, wann ein Stat Panel die bessere Wahl ist als ein Time Series Panel. Seit Grafana 12: Dashboard-as-Code ermöglicht Dashboard-Versionierung direkt über Git (Git Sync, zunächst experimentell).

Ein Alert, der um 3 Uhr nachts ausgelöst wird, muss sofort verständlich sein. Sie konfigurieren den Prometheus Alertmanager mit Routing-Regeln, Receiver-Integrationen (Slack, E-Mail, PagerDuty) und Alert-Templates. Parallel dazu richten Sie Grafana Alerts ein und vergleichen, wann welches System die bessere Wahl ist. Ihre ersten konkreten Alerts: CPU-Überlastung, Pod-Restarts und Disk-Pressure.

Wie skaliert Loki von einem kleinen Cluster auf Enterprise-Niveau? Sie analysieren die Architektur im Detail: Distributor für die Verteilung, Ingester für die Pufferung, Querier für Abfragen und Storage für die Persistenz. Die Session zeigt, wie Sie zwischen Single-Binary und Microservices-Modus wählen, welche Storage-Backends (S3, GCS, Filesystem) für welche Szenarios passen und wie der neue horizontale Compactor in Loki 3.6 große Delete-Requests beschleunigt.

Sie schreiben LogQL-Abfragen für typische Troubleshooting-Szenarien: Log Stream Selectors mit Label-Filtern, Parser (json, logfmt, pattern) für strukturierte Extraktion und Metric Queries (z.B. rate über Error-Logs), um aus Logs direkt Metriken zu generieren. Diese Queries kombinieren Sie anschließend mit Prometheus-Metriken in einem gemeinsamen Grafana-Dashboard.

Metriken zeigen, dass ein Service langsam ist. Logs zeigen, warum. Hier bauen Sie beides zusammen: ein korreliertes Dashboard in Grafana, das Prometheus-Metriken und Loki-Logs nebeneinander darstellt. Sie konfigurieren Data Links zwischen Metriken und Logs, sodass ein Klick auf einen Metriken-Ausreißer direkt die zugehörigen Log-Einträge anzeigt. Das Ergebnis ist ein Stack, der Ihnen den vollständigen Kontext eines Incidents liefert.

Wie definieren Sie ein Service Level Objective, das weder zu locker noch zu streng ist? Sie messen SLIs (Latenz, Fehlerrate, Verfügbarkeit) mit Prometheus-Abfragen und formulieren daraus SLOs mit Error Budgets. Für die Umsetzung setzen Sie Sloth oder das Grafana SLO Feature ein, um automatisch Recording Rules und Alerting Rules zu generieren. Abgerundet wird das Modul durch die Diskussion realer Beispiele: Welche SLOs machen für einen API-Gateway, einen Batch-Job und eine Datenbank jeweils Sinn?

Nicht die reine Clustergröße, sondern die Zahl aktiver Zeitreihen und ihre Label-Kombinationen bestimmt den Ressourcenbedarf von Prometheus. Sie identifizieren in vorbereiteten Metriken ein High-Cardinality-Label, passen eine Relabeling Rule an und vergleichen die resultierende Serienzahl. Aus der Beobachtung leiten Sie ab, wann ein einzelner Server genügt und wann Federation, Sharding, Thanos oder Mimir geprüft werden sollten.

Ihre PromQL-Abfrage braucht 30 Sekunden, Grafana zeigt Timeouts, Loki frisst Speicher: typische Symptome eines ungetunten Stacks. Bei Prometheus passen Sie Speicherlimits, Scrape-Intervalle und Sharding an. Bei Grafana setzen Sie Query Caching ein und optimieren Panel-Abfragen. Bei Loki steuern Sie Log Retention, Kompressionsstrategien und Chunk-Encoding. Am Ende kennen Sie die wichtigsten Stellschrauben für jede der drei Stack-Komponenten.

Ihr Cluster meldet hohe Latenzen, Prometheus zeigt Datenlücken, ein Loki-Ingester ist OOM. Drei reale Szenarien, die Sie Schritt für Schritt diagnostizieren: vom Alert über die Dashboard-Analyse bis zur Root Cause. Dabei entwickeln Sie ein systematisches Troubleshooting-Vorgehen und sammeln Do's & Don'ts, die im Produktivbetrieb den Unterschied machen.

Im Abschlussprojekt setzen Sie das gesamte Wissen der vier Tage um: In Gruppenarbeit bauen Sie ein End-to-End-Dashboard, das Metriken und Logs integriert, konfigurieren Alerts für kritische Szenarien und definieren mindestens ein SLO mit Error Budget. Die Ergebnisse präsentieren Sie dem Kurs, erhalten Feedback und nehmen konkrete Baupläne für Ihren eigenen Cluster mit.