Observability für Kubernetes: LGTM Stack im Home Lab

Moin zusammen! Als langjähriger Sysadmin und Heimlabor-Enthusiast habe ich in den letzten Jahren unzählige Stunden damit verbracht, meine Systeme zu optimieren und vor allem – sichtbar zu machen. Wer schon mal ein komplexeres Setup mit Proxmox, Docker, Kubernetes und vielleicht noch ein paar N8N-Workflows am Laufen hatte, weiß: Ohne gute Observability stehst du schnell im Dunkeln. Eine meiner absoluten Lieblingslösungen dafür, besonders im Kubernetes-Umfeld, ist der Grafana LGTM-Stack.

Der c't-Workshop hat mich wieder daran erinnert, wie wichtig es ist, diese Tools nicht nur zu kennen, sondern sie auch praktisch einzusetzen. In meiner Erfahrung ist das der einzige Weg, um wirklich zu verstehen, was in deinem Cluster vor sich geht, Probleme frühzeitig zu erkennen und Engpässe zu beheben, bevor sie zu Ausfällen führen. Deshalb habe ich diesen Guide für smoth.me zusammengestellt, um dir meine Erfahrungen bei der Einrichtung des LGTM-Stacks in deinem Heimlabor zu teilen. Wir werden Metriken, Logs und Traces sammeln, visualisieren und damit die Basis für ein robustes Monitoring legen.

Wichtig zu wissen: Wir konzentrieren uns hier auf eine pragmatische Einrichtung für das Heimlabor. Das bedeutet, wir verwenden oft die Standard-Helm-Charts und deren Konfigurationen, die sich in meiner Praxis als sehr zuverlässig erwiesen haben.

Warum Observability im Heimlabor?

Du fragst dich vielleicht, warum du dir den Aufwand für Observability in deinem Heimlabor machen solltest. Ganz einfach: Es ist nicht nur ein cooles Lernprojekt, sondern auch unglaublich nützlich. Wenn dein Home Assistant plötzlich träge wird, deine Docker-Container mysteriöse Fehler werfen oder deine N8N-Workflows nicht mehr triggern, bist du mit einem Observability-Stack in der Lage, die Ursache schnell zu finden. Es geht darum, Transparenz zu schaffen und proaktiv statt reaktiv zu handeln.

Der LGTM-Stack, bestehend aus Loki (Logs), Grafana (Visualisierung), Tempo (Traces) und Prometheus (Metriken), bietet eine umfassende Lösung. Es ist ein mächtiges Quartett, das sich nahtlos in Kubernetes integrieren lässt.

Voraussetzungen für den Start

Bevor wir uns ins Getümmel stürzen, stellen wir sicher, dass deine Umgebung bereit ist. Wer das zum ersten Mal einrichtet, stolpert oft über fehlende Tools oder Berechtigungen. Mein Tipp: Nimm dir hier kurz Zeit, alles zu prüfen.

• Ein laufender Kubernetes-Cluster: Das ist die Basis. Egal ob du einen vollwertigen Cluster, K3s auf einem Raspberry Pi, MicroK8s oder Minikube nutzt – Hauptsache, er läuft und du hast Admin-Zugriff. In meiner Erfahrung funktionieren alle diese Optionen gut, wobei K3s für Home Labs oft die erste Wahl ist.
• kubectl installiert und konfiguriert: Du musst mit deinem Cluster interagieren können. Prüfe das mit kubectl get nodes.
• helm installiert: Der Paketmanager für Kubernetes ist unser bester Freund, wenn es darum geht, komplexe Anwendungen wie den LGTM-Stack zu deployen. Falls nicht, installiere es nach der offiziellen Anleitung.
• Grundlegendes Kubernetes-Wissen: Du solltest wissen, was Pods, Deployments, Services, ConfigMaps und vielleicht auch Ingress sind. Wir werden diese Konzepte nutzen.
• Netzwerkgrundlagen: Verständnis für Port-Forwarding und ggf. DNS-Konfiguration ist hilfreich, um später auf Grafana zugreifen zu können.

Der LGTM-Stack: Was ist was?

Bevor wir die Komponenten installieren, ein kurzer Überblick, damit du weißt, was wir da eigentlich tun:

• Loki: Ein Log-Aggregator, der speziell für Kubernetes-Umgebungen entwickelt wurde. Im Gegensatz zu anderen Lösungen indexiert Loki nicht den gesamten Log-Inhalt, sondern nur Metadaten (Labels). Das macht ihn extrem ressourcenschonend und schnell.
• Grafana: Das Schweizer Taschenmesser für Visualisierung. Hier werden wir unsere Metriken, Logs und Traces in Dashboards und Graphen darstellen.
• Tempo: Ein Open-Source-Traces-Backend. Es ermöglicht dir, End-to-End-Anfragen über verschiedene Microservices hinweg zu verfolgen, was bei der Fehlersuche in verteilten Systemen Gold wert ist.
• Prometheus: Der De-facto-Standard für Monitoring in der Cloud-Native-Welt. Prometheus sammelt Metriken von deinen Anwendungen und Infrastrukturkomponenten.

Gemeinsam bilden sie eine mächtige Plattform für die Observability.

Schritt-für-Schritt-Anleitung: LGTM-Stack im Kubernetes-Heimlabor

Jetzt geht's ans Eingemachte! Wir installieren die Komponenten nacheinander. Ich empfehle, sie in einem eigenen Namespace zu deployen, um Ordnung zu halten.

1. Namespace für Observability erstellen

Zuerst erstellen wir einen dedizierten Namespace. Das ist gute Praxis und hält deinen Cluster sauber.

kubectl create namespace observability

2. Helm Repositories hinzufügen

Wir benötigen die offiziellen Helm Charts von Grafana Labs und Prometheus.

helm repo add grafana https://grafana.github.io/helm-charts
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm repo update stellt sicher, dass du die neuesten Versionen der Charts ziehst. In meiner Erfahrung ist es immer gut, hier aktuell zu bleiben.

3. Prometheus installieren

Prometheus ist unser Metriken-Sammler. Wir installieren das Prometheus-Stack-Chart, das auch nützliche Komponenten wie kube-state-metrics und node-exporter mitbringt. Diese sind essenziell, um den Zustand deines Clusters und deiner Nodes zu überwachen.

helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace observability \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \
  --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false \
  --set prometeus.prometheusSpec.ruleSelectorNilUsesHelmValues=false \
  --set prometheus.prometheusSpec.scrapeConfigSelectorNilUsesHelmValues=false \
  --set grafana.enabled=false \
  --set alertmanager.enabled=false \
  --set prometheusOperator.enabled=true \
  --version 55.4.0 # Prüfe die aktuelle Version!

Erklärung der Parameter:

• --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false und ähnliche: Diese sind wichtig, damit Prometheus standardmäßig ServiceMonitore und PodMonitore im gesamten Namespace (oder Cluster, je nach Konfiguration) erkennt, anstatt nur die vom Chart erstellten. Das ist entscheidend, wenn du später eigene Anwendungen monitorst.
• --set grafana.enabled=false: Wir installieren Grafana später separat, um mehr Kontrolle zu haben.
• --set alertmanager.enabled=false: Für den Anfang lassen wir Alertmanager deaktiviert, um Komplexität zu reduzieren. Du kannst ihn später aktivieren.
• --version 55.4.0: Mein Tipp: Prüfe vor der Installation immer die aktuelle Version des Charts. Versionen ändern sich schnell!

Überprüfe die Installation:

kubectl get pods -n observability -l app.kubernetes.io/name=prometheus

4. Loki und Promtail installieren

Loki sammelt unsere Logs, und Promtail ist der Agent, der die Logs von jedem Pod auf jeder Node an Loki sendet.

helm install loki grafana/loki-stack \
  --namespace observability \
  --set grafana.enabled=false \
  --set prometheus.enabled=false \
  --set promtail.enabled=true \
  --set promtail.serviceMonitor.enabled=true \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=10Gi \
  --version 2.9.1 # Prüfe die aktuelle Version!

Erklärung der Parameter:

• --set grafana.enabled=false, --set prometheus.enabled=false: Wir wollen diese Komponenten nicht doppelt installieren.
• --set promtail.enabled=true: Aktiviert den Log-Sammelagenten.
• --set promtail.serviceMonitor.enabled=true: Ermöglicht Prometheus, Metriken von Promtail zu scrapen.
• --set loki.persistence.enabled=true --set loki.persistence.size=10Gi: Wichtig! Ohne Persistenz gehen deine Logs bei einem Neustart verloren. Stelle sicher, dass dein Cluster einen StorageClass hat, der Persistent Volumes bereitstellen kann. Für ein Heimlabor ist oft hostpath oder ein NFS-basierter StorageClass ausreichend. Passe die Größe nach Bedarf an.
• --version 2.9.1: Auch hier: Aktuelle Version prüfen!

Überprüfe die Installation:

kubectl get pods -n observability -l app.kubernetes.io/name=loki
kubectl get pods -n observability -l app.kubernetes.io/name=promtail

5. Tempo installieren

Tempo ist unser Tracing-Backend. Es ist erstaunlich einfach zu installieren und bietet enorme Einblicke in Anwendungsabläufe.

helm install tempo grafana/tempo \
  --namespace observability \
  --set tempo.persistence.enabled=true \
  --set tempo.persistence.size=10Gi \
  --version 1.5.0 # Prüfe die aktuelle Version!

Erklärung der Parameter:

• --set tempo.persistence.enabled=true --set tempo.persistence.size=10Gi: Wie bei Loki ist Persistenz auch für Traces essenziell, damit diese nicht verloren gehen. Wiederhole hier die Überprüfung deines StorageClass.
• --version 1.5.0: Aktuelle Version prüfen!

Überprüfe die Installation:

kubectl get pods -n observability -l app.kubernetes.io/name=tempo

6. Grafana installieren und konfigurieren

Jetzt kommt die Schaltzentrale: Grafana. Hier visualisieren wir alles.

helm install grafana grafana/grafana \
  --namespace observability \
  --set adminPassword='dein_sicheres_passwort' \
  --set service.type=ClusterIP \
  --set ingress.enabled=true \
  --set ingress.annotations."kubernetes\.io/ingress\.class"=nginx \
  --set ingress.hosts[0].host=grafana.dein-domain.de \
  --set ingress.hosts[0].paths[0].path=/ \
  --set persistence.enabled=true \
  --set persistence.size=5Gi \
  --version 7.0.0 # Prüfe die aktuelle Version!

Erklärung der Parameter:

• --set adminPassword='dein_sicheres_passwort': Ganz wichtig! Setze hier ein sicheres Passwort. Das ist der initiale Login für den Admin-User.
• --set service.type=ClusterIP: Grafana wird intern zugänglich gemacht.
• --set ingress.enabled=true: Aktiviert einen Ingress-Controller für externen Zugriff. Du benötigst einen Ingress-Controller in deinem Cluster (z.B. NGINX Ingress Controller), den du separat installieren musst, falls noch nicht geschehen.
• --set ingress.annotations."kubernetes\.io/ingress\.class"=nginx: Weist den Ingress dem NGINX Controller zu. Passe dies an, falls du einen anderen Controller nutzt.
• --set ingress.hosts[0].host=grafana.dein-domain.de: Ersetze grafana.dein-domain.de durch deine gewünschte Domain oder Subdomain. Stelle sicher, dass dieser DNS-Eintrag auf die IP deines Ingress-Controllers zeigt.
• --set persistence.enabled=true --set persistence.size=5Gi: Für Grafana-Dashboards, Datenquellen und Nutzer.
• --version 7.0.0: Aktuelle Version prüfen!

Überprüfe die Installation:

kubectl get pods -n observability -l app.kubernetes.io/name=grafana
kubectl get ingress -n observability

7. Grafana Datenquellen konfigurieren

Sobald Grafana läuft und du über deine konfigurierte Domain (z.B. grafana.dein-domain.de) zugreifen kannst (Login: admin / dein_sicheres_passwort), müssen wir die Datenquellen hinzufügen.

Gehe in Grafana zu Connections -> Data sources und füge folgende hinzu:

• Prometheus:
  • Name: Prometheus
  • Type: Prometheus
  • URL: http://prometheus-kube-prometheus-prometheus.observability.svc.cluster.local:9090 (Dies ist der interne Kubernetes Service Name und Port)
  • Scrape interval: 15s (Standard, kann angepasst werden)
• Loki:
  • Name: Loki
  • Type: Loki
  • URL: http://loki.observability.svc.cluster.local:3100
• Tempo:
  • Name: Tempo
  • Type: Tempo
  • URL: http://tempo.observability.svc.cluster.local:3100

Wichtig: Die URLs nutzen die internen Kubernetes-Service-Namen. Da sich alle Komponenten im selben Namespace befinden, ist der Pfad <service-name>.<namespace>.svc.cluster.local:<port>. Das ist in meiner Erfahrung der zuverlässigste Weg, um interne Kommunikation sicherzustellen.

8. Erste Tests und Dashboards

Nachdem die Datenquellen konfiguriert sind, kannst du erste Tests durchführen:

• Prometheus: Gehe in Grafana zu Explore, wähle die Prometheus-Datenquelle und gib einen PromQL-Query ein, z.B. kube_node_info oder node_cpu_seconds_total. Du solltest Daten sehen.
• Loki: Wähle die Loki-Datenquelle. Gib einen LogQL-Query ein, z.B. {namespace="observability"}, um Logs aus unserem Namespace zu sehen. Oder spezifischer: {namespace="kube-system", app="kube-apiserver"}.
• Tempo: Tempo benötigt Instrumentierung in deinen Anwendungen. Das ist ein fortgeschrittener Schritt. Für den Anfang kannst du aber schon sehen, dass die Datenquelle verbunden ist.

Mein Tipp: Importiere fertige Dashboards! Grafana Labs bietet eine riesige Sammlung von Dashboards. Suche nach "Kubernetes Cluster Monitoring (via Prometheus)" oder "Loki logs". Du kannst sie über Dashboards -> Import importieren und die Prometheus/Loki-Datenquellen zuweisen.

Häufige Fehler und Lösungen

Bei der Einrichtung solcher komplexen Stacks läuft nicht immer alles glatt. Hier sind ein paar Probleme, über die ich selbst schon gestolpert bin:

1. Prometheus sammelt keine Metriken von meinen Anwendungen

• Problem: Du hast eine eigene Anwendung deployed, aber Prometheus scheint keine Metriken davon zu scrapen.
• Mögliche Ursachen:
  1. Fehlende ServiceMonitore/PodMonitore: Prometheus findet deine Anwendung nicht automatisch. Du musst einen ServiceMonitor oder PodMonitor (Custom Resources von Prometheus Operator) erstellen, der Prometheus mitteilt, welche Services/Pods er scrapen soll.
  2. Falsche Labels: Der Selector im ServiceMonitor passt nicht zu den Labels deines Services.
  3. RBAC-Berechtigungen: Der Prometheus-ServiceAccount hat nicht die nötigen Rechte, um Services und Endpoints in anderen Namespaces zu listen.
  4. Falscher Port/Pfad: Die Anwendung exponiert Metriken auf einem anderen Port oder Pfad als dem Standard /metrics.
• Lösung:
  • Erstelle einen ServiceMonitor für deine Anwendung. Ein Beispiel für einen ServiceMonitor:

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: meine-app-monitor
      labels:
        release: prometheus # Wichtig: Muss dem "release" Label deines Prometheus-Charts entsprechen
    spec:
      selector:
        matchLabels:
          app: meine-app # Label deines Services
      endpoints:
      - port: http-metrics # Name des Ports im Service
        path: /metrics
      namespaceSelector:
        matchNames:
        - default # Oder der Namespace deiner App

  • Überprüfe die Labels des ServiceMonitor und des Ziel-Services.
  • Stelle sicher, dass der Prometheus-ServiceAccount über die notwendigen ClusterRole und ClusterRoleBinding verfügt, um Ressourcen im gesamten Cluster zu überwachen (das kube-prometheus-stack Chart sollte das standardmäßig einrichten, aber es ist gut, es zu prüfen).
  • Überprüfe den Metriken-Endpunkt und den Port in deiner Anwendung und passe den ServiceMonitor entsprechend an.

2. Loki empfängt keine Logs von Promtail

• Problem: Du siehst keine Logs in Grafana, wenn du die Loki-Datenquelle auswählst.
• Mögliche Ursachen:
  1. Promtail läuft nicht: Die Promtail-Pods sind nicht gestartet oder stürzen ab.
  2. Promtail-Konfiguration: Promtail ist falsch konfiguriert und weiß nicht, wohin es die Logs senden soll oder welche Logs es sammeln soll.
  3. Netzwerk: Promtail kann Loki nicht erreichen.
  4. Persistenzprobleme: Wenn Loki keine Persistenz hat, sind Logs nach einem Neustart weg.
• Lösung:
  • Überprüfe den Status der Promtail-Pods: kubectl get pods -n observability -l app.kubernetes.io/name=promtail. Schau dir die Logs an: kubectl logs -f <promtail-pod-name> -n observability.
  • Stelle sicher, dass die Loki-URL in der Promtail-Konfiguration korrekt ist. Das Helm-Chart sollte dies automatisch richtig setzen, aber ein Blick in die ConfigMap von Promtail kann nicht schaden.
  • Prüfe die Netzwerkverbindung zwischen Promtail und Loki. Wenn beide im selben Namespace sind und der Service-Name korrekt ist, sollte das kein Problem sein.
  • Vergewissere dich, dass Loki eine persistente Speicherung konfiguriert hat (loki.persistence.enabled=true).

3. Grafana-Datenquellen können nicht verbunden werden (404, Network Error)

• Problem: Du kannst die Datenquellen in Grafana nicht speichern oder erhältst "Network Error" oder "404 Not Found".
• Mögliche Ursachen:
  1. Falsche URL: Die URL für Prometheus, Loki oder Tempo ist falsch geschrieben oder der Service ist nicht erreichbar.
  2. Firewall/NetworkPolicy: Eine Firewall oder Kubernetes NetworkPolicy blockiert den Zugriff von Grafana auf die anderen Komponenten.
  3. DNS-Auflösung: Der interne DNS-Name (*.svc.cluster.local) wird nicht korrekt aufgelöst.
• Lösung:
  • Überprüfe die URLs nochmals ganz genau. Tippfehler sind hier der häufigste Fehler! Verwende die vollen Service-Namen: http://prometheus-kube-prometheus-prometheus.observability.svc.cluster.local:9090, http://loki.observability.svc.cluster.local:3100, http://tempo.observability.svc.cluster.local:3100.
  • Wenn du NetworkPolicies in deinem Cluster nutzt, stelle sicher, dass Grafana (im observability Namespace) ausgehenden Traffic zu den anderen Services im selben Namespace erlauben darf.
  • Teste die DNS-Auflösung und Erreichbarkeit: Du kannst einen temporären Pod im observability Namespace starten (z.B. einen busybox Pod) und von dort aus versuchen, die Services per ping oder wget zu erreichen. Beispiel:

    kubectl run -it --rm --image=busybox --namespace observability -- sh
    # Im busybox-Pod:
    wget -O- http://loki.observability.svc.cluster.local:3100/ready
    # Erwartet einen 200 OK oder ähnliches

Fazit und nächste Schritte

Glückwunsch! Du hast jetzt einen voll funktionsfähigen Observability-Stack in deinem Kubernetes-Heimlabor am Laufen. Das ist ein riesiger Schritt, um die Kontrolle über deine Systeme zu gewinnen.

In meiner Erfahrung ist die Einrichtung nur der Anfang. Die wahre Magie beginnt, wenn du anfängst, eigene Dashboards zu bauen, spezifische Metriken und Logs deiner Anwendungen zu scrapen und Alerting einzurichten. Hier sind ein paar Ideen für deine nächsten Schritte:

• Eigene Anwendungen instrumentieren: Füge Prometheus-Exporter zu deinen eigenen Anwendungen hinzu, um deren interne Metriken zu sammeln.
• Alerting mit Alertmanager: Aktiviere den Alertmanager (im Prometheus-Chart enthalten) und konfiguriere Benachrichtigungen für kritische Zustände.
• Tracing für deine Microservices: Integriere OpenTelemetry oder Jaeger-Clients in deine Anwendungen, um Traces an Tempo zu senden. Das ist besonders bei Microservices extrem aufschlussreich.
• Weitere Dashboards: Baue dir eigene, auf deine Bedürfnisse zugeschnittene Dashboards in Grafana.
• Persistenz-Strategie überdenken: Für ein Heimlabor ist die lokale Persistenz oft ausreichend. Für produktivere Setups solltest du über verteilte Storage-Lösungen nachdenken.
• Sicherheit: Verstärke die Sicherheit deines Grafana-Zugangs (z.B. mit OAuth oder LDAP-Integration).

Der LGTM-Stack ist ein mächtiges Werkzeug, das dir hilft, deine Kubernetes-Umgebung nicht nur zu betreiben, sondern auch wirklich zu verstehen. Viel Spaß beim Experimentieren und Happy Monitoring!