Kubernetes mit kube-prometheus-stack überwachen

Wie viel Arbeitsspeicher bleibt auf deinen Nodes? Welche Pods starten ständig neu? Und kommt ein Alarm tatsächlich beim zuständigen Team an? Mit kube-prometheus-stack richtest du Metriken, Dashboards und Alarmierung für deinen Kubernetes-Cluster gemeinsam ein.

Diese Anleitung führt dich von der Helm-Installation über persistenten Speicher bis zum Monitoring einer eigenen Anwendung. Zum Schluss prüfst du die Alarmzustellung mit einem Testalert. So entsteht eine Grundlage, die du an die Anforderungen deines Produktivbetriebs anpassen kannst.

Was ist kube-prometheus-stack?

kube-prometheus-stack ist ein Helm-Chart der prometheus-community. Es installiert standardmäßig Prometheus Operator, Prometheus, Alertmanager, Grafana, node-exporter und kube-state-metrics. Dazu kommen vorkonfigurierte Kubernetes-Dashboards und Alert-Regeln.

Das Chart installiert auch Custom Resource Definitions (CRDs). Sie erweitern Kubernetes um Ressourcentypen wie ServiceMonitor, PodMonitor und PrometheusRule. Du legst Ressourcen dieser Typen an; der Operator verarbeitet die von deiner Prometheus-Instanz ausgewählten Ressourcen. Chart-Dokumentation.

graph LR
  SM["ServiceMonitor / PodMonitor"] --> OP["Prometheus Operator"]
  PR["PrometheusRule"] --> OP
  OP -->|"konfiguriert und verwaltet"| P["Prometheus"]
  OP -->|"verwaltet"| AM["Alertmanager"]
  P -->|"ruft Metriken ab"| NE["node-exporter"]
  P -->|"ruft Metriken ab"| KSM["kube-state-metrics"]
  P -->|"ruft /metrics ab"| APP["Eigene Anwendung"]
  P -->|"Alerts"| AM
  AM --> N["E-Mail, Slack, Webhook"]
  G["Grafana"] -->|"PromQL-Abfragen"| P

Was unterscheidet kube-prometheus-stack vom Prometheus Operator?

kube-prometheus-stack ist ein Helm-Chart, das die Kernkomponenten des kube-prometheus-Projekts installiert, während der Prometheus Operator darin nur eine Komponente ist, die Prometheus und Alertmanager anhand von Kubernetes-Ressourcen verwaltet.

Das Chart hieß früher prometheus-operator und wurde umbenannt, weil es mehr als den Operator installiert: Neben ihm bringt es die übrigen Komponenten aus der Tabelle oben mit. Den vollständigen kube-prometheus-Stack bildet es trotzdem nicht ab. Prometheus Adapter und Blackbox Exporter gehören laut Chart-Dokumentation nicht zum Lieferumfang.

Voraussetzungen

Du brauchst:

• Einen Kubernetes-Cluster mit Linux-Worker-Nodes und einer vom gewählten Chart unterstützten Kubernetes-Version, beispielsweise centron Managed Kubernetes. Läuft im Cluster bereits ein Prometheus Operator, etwa als Teil eines vom Anbieter mitgelieferten Monitorings, klärst du vor der Installation, wie ein zweiter Operator abgegrenzt wird. Ob die CRDs schon vorhanden sind, zeigt kubectl get crd | grep monitoring.coreos.com.
• kubectl mit Rechten zum Anlegen clusterweiter Ressourcen (CRDs, ClusterRoles, ClusterRoleBindings, Webhook-Konfigurationen) sowie von Ressourcen im Monitoring-Namespace und in kube-system. Für die Erstinstallation wird dafür häufig ein administrativer Zugang genutzt.
• Eine zum Chart passende Helm-Version. Die folgenden Befehle verwenden Helm 3.
• Eine StorageClass mit dynamischer Bereitstellung für Prometheus, Alertmanager und Grafana.
• Ausreichend CPU und RAM auf geeigneten Nodes. Der Prometheus-Container im Beispiel reserviert allein 2Gi RAM; Sidecars und die anderen Komponenten benötigen zusätzliche Ressourcen.
• Für die Befehle eine Bash-Umgebung, etwa unter Linux oder WSL, sowie curl, jq und base64.
• Für E-Mail-Benachrichtigungen einen aus dem Cluster erreichbaren SMTP-Server und passende Zugangsdaten.

Prüfe den Cluster-Zugriff und die verfügbaren StorageClasses:

$ kubectl cluster-info
$ kubectl get nodes
$ kubectl get storageclass

Ohne expliziten storageClassName verwendet Kubernetes für neue PVCs die Standard-StorageClass. Fehlt sie, trägst du eine geeignete Klasse in die Konfiguration ein. Für die lokale Prometheus-Datenbank eignet sich beispielsweise ein Block-Volume mit unterstütztem Dateisystem; NFS wird von Prometheus nicht unterstützt. StorageClasses, Prometheus Storage.

Helm-Repository hinzufügen und Version festlegen

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update
$ helm search repo prometheus-community/kube-prometheus-stack

Die Chart-Dokumentation nennt das Chart zusätzlich als OCI-Artefakt oci://ghcr.io/prometheus-community/charts/kube-prometheus-stack und verwendet diese Quelle in ihren Installationsbeispielen. Diese Anleitung bleibt beim klassischen Helm-Repository; dessen Index enthält Version 91.9.0.

Diese Anleitung bezieht sich auf die Konfiguration von Chart 91.9.0. Setze die Version ausdrücklich, damit spätere Ausführungen nicht versehentlich ein anderes Release installieren:

$ CHART_VERSION='91.9.0'
$ helm show chart prometheus-community/kube-prometheus-stack --version "$CHART_VERSION"

Prüfe insbesondere kubeVersion gegen deinen Cluster. Beim Wechsel zu einer neueren Chart-Version liest du vorher die Upgrade-Hinweise.

Lege anschließend dein Arbeitsverzeichnis an. Die weiteren Dateipfade beziehen sich darauf:

$ mkdir -p "$HOME/monitoring"
$ cd "$HOME/monitoring"
$ umask 077

values.yaml anlegen

Das folgende Beispiel aktiviert persistenten Speicher für alle drei zustandsbehafteten Komponenten. Das Grafana-Chart erzeugt bei einer frischen Installation ohne Passwortvorgabe ein zufälliges Administratorpasswort. Das bekannte Standardpasswort früherer Chart-Versionen wurde mit Version 79 entfernt. Änderung der Passwortvorgabe.

Speichere die Konfiguration als values.yaml und ersetze die SMTP-Platzhalter:

prometheus:
  prometheusSpec:
    retention: 15d
    retentionSize: 40GB
    # Nur Ressourcen mit dem Label dieses Releases auswählen.
    serviceMonitorSelectorNilUsesHelmValues: true
    podMonitorSelectorNilUsesHelmValues: true
    ruleSelectorNilUsesHelmValues: true
    serviceMonitorSelector: {}
    podMonitorSelector: {}
    ruleSelector: {}
    # Passend gelabelte Ressourcen in allen Namespaces finden.
    serviceMonitorNamespaceSelector: {}
    podMonitorNamespaceSelector: {}
    ruleNamespaceSelector: {}
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
    storageSpec:
      volumeClaimTemplate:
        spec:
          # storageClassName: deine-block-storage-class
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          # storageClassName: deine-block-storage-class
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 2Gi
  config:
    global:
      resolve_timeout: 5m
    route:
      receiver: team-mail
      group_by: ["alertname", "namespace"]
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      routes:
        - receiver: "null"
          matchers:
            - 'alertname = "Watchdog"'
    receivers:
      - name: "null"
      - name: team-mail
        email_configs:
          - to: "<deine-team-adresse>"
            from: "<absender-adresse>"
            smarthost: "<smtp-server>:587"
            auth_username: "<smtp-benutzer>"
            auth_password: "<smtp-passwort>"
            require_tls: true
            send_resolved: true
grafana:
  persistence:
    enabled: true
    # storageClassName: deine-block-storage-class
    size: 10Gi

Die Speichergrößen und Ressourcen sind Startwerte für das Beispiel. Dimensioniere sie nach Clustergröße, Zahl der Zeitreihen und Aufbewahrungsbedarf. Ein einzelner geeigneter Node muss genügend Kapazität für den Prometheus-Pod haben.

Aufbewahrung: retention: 15d begrenzt die Aufbewahrungszeit, retentionSize: 40GB die Größe der aufbewahrten Daten. Es greift die zuerst erreichte Grenze. Prometheus empfiehlt, dafür höchstens 80–85 % des zugewiesenen Speicherplatzes zu verplanen. Die Reserve deckt vor allem den Platz ab, den laufende Kompaktierungen vorübergehend zusätzlich belegen. WAL und Head-Chunks zählen bereits zur retentionSize. Überwache deshalb auch den freien Volume-Speicher. Speicherplanung.

Ressourcenauswahl: Die *SelectorNilUsesHelmValues-Optionen sorgen hier dafür, dass das Chart bei leeren Objektselektoren auf das Label release: kube-prometheus-stack einschränkt. Dieses Label erhalten später auch unsere eigenen Ressourcen. Die Namespace-Selektoren erlauben ihre Suche in allen Namespaces; du kannst den Suchbereich bei Bedarf enger fassen. Chart-Standardwerte.

Watchdog und E-Mail: Der dauerhaft aktive Watchdog-Alert wird hier an den leeren Receiver geleitet. Für eine laufende Prüfung der Alarmkette kannst du ihn später an einen externen Dienst senden, der beim Ausbleiben des Signals alarmiert. send_resolved: true aktiviert zusätzlich Entwarnungs-Mails.

Die SMTP-Daten in dieser Datei sind eine einfache Einstiegskonfiguration. Schütze die Datei und lege sie nicht mit echten Zugangsdaten im Repository ab. Für den Dauerbetrieb verwaltest du die Alertmanager-Konfiguration über ein Kubernetes-Secret, beispielsweise mit External Secrets oder Sealed Secrets. Helm speichert verwendete Werte ebenfalls in seinen Release-Daten; Dateirechte allein ersetzen deshalb kein Secret-Management. Ein vorhandenes Grafana-Secret lässt sich über grafana.admin.existingSecret einbinden.

Control-Plane-Monitoring an den Cluster anpassen

Bei Managed Kubernetes sind die Metrik-Endpunkte von etcd, Scheduler und Controller-Manager je nach Anbieter nicht zugänglich. Nur wenn das für deinen Cluster zutrifft, ergänzt du diese Werte in derselben Datei:

kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false
kubeControllerManager:
  enabled: false

Das deaktiviert deren Monitoring, nicht die Kubernetes-Komponenten selbst. Die Abfrage des Kubernetes-API-Servers bleibt davon unberührt. Setzt dein Cluster keinen kube-proxy ein, ergänzt du entsprechend kubeProxy.enabled: false.

kube-prometheus-stack installieren

$ helm upgrade --install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --version "$CHART_VERSION" \
  --values values.yaml \
  --wait --timeout 10m

Die weiteren Beispiele verwenden den Release-Namen kube-prometheus-stack. Bei einem anderen Namen können sich Service-Namen und Release-Labels ändern.

Prüfe nach der Installation sowohl Pods als auch PersistentVolumeClaims:

$ kubectl get pods -n monitoring
$ kubectl get pvc -n monitoring

Die gestarteten Pods sollten bereit sein und die PVCs den Status Bound erreichen. Die Dauer hängt unter anderem von Image-Downloads und Storage-Provisionierung ab. Da der Operator weitere Ressourcen asynchron anlegt, bleibt diese Prüfung auch nach einem erfolgreichen Helm-Befehl sinnvoll.

Der node-exporter läuft als DaemonSet auf den geeigneten Linux-Nodes. Die Zahl seiner Pods hängt deshalb von der Node-Auswahl und den Scheduling-Bedingungen ab.

Grafana und Prometheus öffnen

Starte für Grafana einen Port-Forward:

$ kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

Lass dieses Terminal geöffnet. Lies in einem zweiten Terminal das erzeugte Passwort aus:

$ kubectl get secret -n monitoring kube-prometheus-stack-grafana \
  -o jsonpath='{.data.admin-password}' | base64 --decode
$ printf '\n'

Öffne http://localhost:3000 und melde dich als admin an. Unter Dashboards findest du die mitgelieferten Ansichten für Nodes, Namespaces und Workloads. Wenn du stattdessen grafana.admin.existingSecret verwendest, liest du die Zugangsdaten aus diesem Secret.

Für Prometheus startest du einen weiteren Port-Forward in einem eigenen Terminal:

$ kubectl port-forward -n monitoring svc/kube-prometheus-stack-prometheus 9090:9090

Die Oberfläche ist dann unter http://localhost:9090 erreichbar. Für einen dauerhaften Teamzugriff kannst du beispielsweise einen Ingress mit TLS und Authentifizierung oder einen internen Zugang über VPN verwenden. Prometheus und Alertmanager unterstützen auch selbst TLS und Basic Auth. Veröffentliche ihre Oberflächen nicht ohne Zugriffsschutz. Prometheus-Authentifizierung, Alertmanager HTTPS.

Eigene Anwendung per ServiceMonitor anbinden

Ein ServiceMonitor beschreibt, welche Services Prometheus abfragen soll. Das Beispiel setzt eine bereits laufende Anwendung mit diesen Eigenschaften voraus:

Die Anwendung muss am betreffenden Endpunkt Metriken in einem von Prometheus unterstützten Format ausliefern. Ein ServiceMonitor instrumentiert die Anwendung nicht nachträglich.

Speichere diese Ressource als shop-api-servicemonitor.yaml:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: shop-api
  namespace: shop
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: shop-api
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

$ kubectl apply -f shop-api-servicemonitor.yaml

Dabei greifen zwei Auswahlschritte: Das Release-Label macht den ServiceMonitor für unsere Prometheus-Instanz sichtbar. spec.selector.matchLabels wählt anschließend die Services aus. Weil kein eigener Namespace-Selektor im ServiceMonitor gesetzt ist, sucht er hier im Namespace shop.

port: metrics bezeichnet den Namen des Service-Ports, keine Portnummer. Ohne abweichendes jobLabel entspricht das spätere Prometheus-Label job dem Service-Namen, hier shop-api. ServiceMonitor-Referenz.

Eine Alert-Regel für die Anwendung anlegen

Die folgende Regel meldet, wenn Prometheus fünf Minuten lang keinen erfolgreichen Scrape des Metrik-Endpunkts von shop-api feststellt. Sie berücksichtigt auch den Fall, dass sämtliche passenden Targets aus der Discovery verschwinden.

Speichere sie als shop-api-rules.yaml:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: shop-api-alerts
  namespace: shop
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: shop-api
      rules:
        - alert: ShopApiMetricsUnavailable
          expr: (sum(up{namespace="shop", job="shop-api", endpoint="metrics"}) or vector(0)) == 0
          for: 5m
          labels:
            severity: critical
            namespace: shop
            service: shop-api
          annotations:
            summary: "Keine erreichbaren Metrik-Targets für shop-api"
            description: "Seit mindestens 5 Minuten fehlen erfolgreiche Scrapes des Metrik-Endpunkts von shop-api im Namespace shop."

$ kubectl apply -f shop-api-rules.yaml

Für jeden Scrape hat up den Wert 1 bei Erfolg oder 0 bei einem Fehler. sum(...) zählt damit die erfolgreich abgefragten Targets. or vector(0) liefert auch dann einen Nullwert, wenn überhaupt keine passenden Zeitreihen vorhanden sind. Der Namespace-Filter verhindert, dass ein gleichnamiger Dienst aus einem anderen Namespace den Ausfall verdeckt.

Die Regel geht von einem dauerhaft erwarteten Dienst aus: Bewusstes Scale-to-zero, ein falscher Selektor oder ein fehlender ServiceMonitor lösen ebenfalls aus. Ein erfolgreicher Scrape beweist außerdem nicht, dass die API fachlich funktioniert. Ergänze bei Bedarf Verfügbarkeitsprüfungen oder Alerts auf Fehlerrate und Antwortzeit.

Installation verifizieren

Während der Prometheus-Port-Forward läuft, kannst du in einem weiteren Terminal die aktiven Targets abfragen:

$ curl -fsS 'http://localhost:9090/api/v1/targets' \
  | jq -r '.data.activeTargets[] | [.labels.namespace, .labels.job, .labels.endpoint, .health, .lastError] | @tsv'

Prüfe, ob die erwarteten Cluster-Targets und die Targets von shop-api vorhanden sind und up melden. Eine Liste ohne down reicht nicht: Ein vollständig fehlendes Target erscheint darin gar nicht. Bei Fehlern hilft die Spalte lastError.

Ob die Anwendungsregel geladen ist, zeigt die Rules-API:

$ curl -fsS 'http://localhost:9090/api/v1/rules' \
  | jq '.data.groups[] | select(.name == "shop-api") | .rules[] | {name, state, health, lastError}'

Ohne Ausgabe wurde die Regel noch nicht geladen oder nicht ausgewählt. Bei einem Fehler prüfst du health und lastError. Eine geladene, gesunde Regel bestätigt noch keine funktionierende E-Mail-Zustellung.

Alarmzustellung mit einem Testalert prüfen

Ein zeitweiliger Testalert prüft den Weg von Prometheus über Alertmanager bis zum Postfach, ohne deine Anwendung herunterzufahren. Informiere die Empfänger vor dem Test.

Speichere als monitoring-testalert.yaml:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: monitoring-notification-test
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: monitoring-notification-test
      rules:
        - alert: MonitoringNotificationTest
          expr: vector(1)
          for: 1m
          labels:
            severity: warning
            namespace: monitoring
          annotations:
            summary: "Geplanter Test der Monitoring-Benachrichtigung"
            description: "Dies ist ein Testalert. Es liegt kein gemeldeter Anwendungsausfall vor."

$ kubectl apply -f monitoring-testalert.yaml

Sobald die Regel geladen und ausgewertet wird, wird der Alert zunächst pending und nach einer Minute firing. Hinzu kommen die Auswertungsintervalle, group_wait: 30s und die Mailzustellung. Prüfe den Status in Prometheus und anschließend den Eingang im Postfach.

Entferne die Testregel nach Abschluss:

$ kubectl delete -f monitoring-testalert.yaml

Mit send_resolved: true ist auch eine Entwarnungs-Mail vorgesehen; sie kann durch die Gruppierungsintervalle verzögert eintreffen. Bleibt die erste Nachricht aus, prüfe nacheinander den Alert in Prometheus, seinen Eingang und mögliche Silences in Alertmanager sowie SMTP-Erreichbarkeit und Zugangsdaten.

Die eigentliche Anwendungsregel prüfst du zusätzlich in einer Testumgebung: einmal mit vorhandenen, aber nicht erreichbaren Metrik-Targets und einmal mit vollständig fehlenden Targets.

Warum erscheint ein ServiceMonitor nicht in Prometheus?

Typische Ursachen sind ein nicht passendes Release-Label, ein ausgeschlossener Namespace oder ein Service ohne passende Labels und Portnamen.

Prüfe zunächst die Auswahl der Prometheus-Ressource:

$ kubectl get prometheus -n monitoring kube-prometheus-stack-prometheus -o json \
  | jq '.spec | {serviceMonitorSelector, serviceMonitorNamespaceSelector}'

Mit der Beispielkonfiguration erwartest du release: kube-prometheus-stack im Objektselektor und {} im Namespace-Selektor. Ein leerer Objektselektor {} würde alle ServiceMonitors innerhalb der ausgewählten Namespaces erfassen; er hebt eine Namespace-Einschränkung nicht auf.

Prüfe anschließend den ServiceMonitor und den ausgewählten Service:

$ kubectl get servicemonitor -n shop shop-api -o yaml
$ kubectl get svc -n shop -l app=shop-api -o yaml
$ kubectl get endpointslice -n shop -l kubernetes.io/service-name=shop-api

Kontrolliere Service-Labels, Portname metrics und vorhandene Endpunkte. Erscheint das Target, aber sein Scrape scheitert, prüfst du Netzwerkzugang, NetworkPolicies, Pfad und gegebenenfalls TLS oder Authentifizierung. Konfigurationsprobleme lassen sich außerdem in den Operator-Logs nachvollziehen:

$ kubectl logs -n monitoring deployment/kube-prometheus-stack-operator --tail=100

Weitere typische Fehler

PVCs bleiben Pending

Prüfe die Events des betroffenen Claims und die Konfiguration der StorageClass:

$ kubectl describe pvc -n monitoring
$ kubectl get storageclass

Mögliche Ursachen sind eine fehlende Standardklasse, Storage-Quoten oder Probleme beim CSI-Provisioner. Bei WaitForFirstConsumer kann ein Claim warten, bis der Scheduler einen geeigneten Node für den Pod gefunden hat.

Veraltete CRDs nach einem Chart-Update

Helm 3 aktualisiert CRDs aus dem crds-Verzeichnis standardmäßig nicht bei einem Upgrade. Das Chart bietet einen optionalen CRD-Upgradejob (crds.upgradeJob.enabled), den es selbst als Vorschaufunktion kennzeichnet; alternativ aktualisierst du die CRDs entsprechend den Hinweisen für die Zielversion manuell.

Für Chart 91.9.0 befinden sich die Dateien nach dem Entpacken unter charts/crds/crds/. Setze CHART_VERSION in einer neuen Shell erneut auf die Zielversion, sonst lädt helm pull das neueste Release. Bei anderen Versionen prüfst du den Pfad im entpackten Archiv. In einem neuen Arbeitsverzeichnis lautet der manuelle Schritt:

$ helm pull prometheus-community/kube-prometheus-stack \
  --version "$CHART_VERSION" --untar
$ kubectl apply --server-side \
  -f kube-prometheus-stack/charts/crds/crds/

Serverseitiges Apply vermeidet die Größenprobleme der Annotation, die clientseitiges Apply bei umfangreichen CRDs anlegen würde. Treten Feldkonflikte auf, prüfst du deren Ursache. --force-conflicts übernimmt die betroffenen Felder und gehört deshalb nicht unbesehen in jeden Updatebefehl. Helm und CRDs, Upgrade-Anleitung.

Dauerhafte Alerts für Control-Plane-Komponenten

Prüfe, ob die betreffenden Metrik-Endpunkte im Cluster verfügbar sind. Je nach Discovery und Fehler können beispielsweise TargetDown oder komponentenspezifische Alerts wie KubeControllerManagerDown auftreten. Bei vom Anbieter nicht bereitgestellten Endpunkten passt du die Monitoring-Auswahl wie oben beschrieben an.

Prometheus wird mit OOMKilled beendet

Unterscheide zwischen einem überschrittenen Container-Speicherlimit und Speichermangel auf dem Node. Die Pod-Konfiguration und Events geben erste Hinweise:

$ kubectl describe pod -n monitoring prometheus-kube-prometheus-stack-prometheus-0
$ kubectl get limitrange -n monitoring

requests.memory reserviert Ressourcen für das Scheduling. limits.memory begrenzt den Containerverbrauch. Nur den Request anzuheben beseitigt ein zu niedriges Limit nicht; im Beispiel ist kein eigenes Limit gesetzt. Prüfe auch, ob Cluster-Vorgaben eines ergänzen. Kubernetes-Ressourcenverwaltung.

Diese PromQL-Abfrage zeigt Metriknamen mit vielen aktiven Zeitreihen:

topk(10, count by (__name__)({__name__=~".+"}))

Bei hoher Kardinalität begrenzt du variable Labelwerte möglichst bereits in der Anwendung oder verwirfst entbehrliche Serien gezielt über metricRelabelings. Entferne Labels nicht pauschal: Unterschiedliche Serien können dadurch identisch werden, ohne dass ihre Messwerte aggregiert werden. Prometheus Relabeling.

Installation zurückbauen

Brauchst du die Installation nicht mehr, entfernst du zuerst die Beispielressourcen dieser Anleitung. Den Testalert hast du bereits nach der Prüfung gelöscht. Besteht er noch, entfernst du ihn zusätzlich mit kubectl delete -f monitoring-testalert.yaml.

$ kubectl delete -f shop-api-rules.yaml -f shop-api-servicemonitor.yaml

Danach entfernst du das Release:

$ helm uninstall kube-prometheus-stack --namespace monitoring

helm uninstall entfernt die Ressourcen des Releases und seine Release-Historie. Einige Bestandteile bleiben dabei trotzdem im Cluster.

Kubelet-Service: Den Service kube-prometheus-stack-kubelet im Namespace kube-system legt der Operator zur Laufzeit an, nicht das Chart. helm uninstall erfasst ihn deshalb nicht. Prüfe ihn mit kubectl get service -n kube-system kube-prometheus-stack-kubelet und entferne ihn mit kubectl delete service -n kube-system kube-prometheus-stack-kubelet. Sonst fragt eine spätere Installation unter einem anderen Release-Namen die Kubelets doppelt ab.

Volume Claims von Prometheus und Alertmanager: Der Operator betreibt beide als StatefulSet und legt ihre Claims über volumeClaimTemplates an. Solche Claims bleiben beim Löschen des StatefulSets standardmäßig erhalten (whenDeleted: Retain). Prüfe, welche Claims übrig sind, und lösche sie erst, wenn du die gespeicherten Daten nicht mehr brauchst:

$ kubectl get pvc -n monitoring
$ kubectl delete pvc -n monitoring <pvc-name>

<pvc-name> steht für den Namen eines Claims aus der Liste des ersten Befehls.

Volume Claim von Grafana: Das Grafana-Chart betreibt Grafana standardmäßig als Deployment und legt den Claim als eigene Ressource des Releases an. helm uninstall entfernt ihn deshalb mit. Sichere vorher Dashboards, die du in Grafana selbst angelegt hast und weiter brauchst.

Persistente Volumes: Für dynamisch bereitgestellte Volumes entscheidet die reclaimPolicy der StorageClass, ob mit dem Claim auch das Volume gelöscht wird. Ohne Angabe in der StorageClass gilt Delete. Reclaim Policy.

CRDs: helm uninstall lässt die CRDs des Charts bestehen. Die Chart-Dokumentation sieht vor, sie bei Bedarf manuell zu löschen. Mit einer CRD entfernt Kubernetes auch alle Ressourcen dieses Typs im gesamten Cluster, also auch ServiceMonitors und Regeln, die nicht aus dieser Anleitung stammen. Lösche die CRDs deshalb nur, wenn kein anderer Operator sie nutzt. Das betrifft besonders den in den Voraussetzungen genannten Fall eines bereits vorhandenen Prometheus Operators:

$ kubectl delete crd \
  alertmanagerconfigs.monitoring.coreos.com \
  alertmanagers.monitoring.coreos.com \
  podmonitors.monitoring.coreos.com \
  probes.monitoring.coreos.com \
  prometheusagents.monitoring.coreos.com \
  prometheuses.monitoring.coreos.com \
  prometheusrules.monitoring.coreos.com \
  scrapeconfigs.monitoring.coreos.com \
  servicemonitors.monitoring.coreos.com \
  thanosrulers.monitoring.coreos.com

Hast du die verbliebenen Claims geprüft und brauchst nichts mehr aus dem Namespace, entfernst du ihn zum Schluss:

$ kubectl delete namespace monitoring

Externe Systeme und Dauerbetrieb

Auch Dienste außerhalb des Clusters lassen sich mit Prometheus überwachen. Stellt ein System bereits einen kompatiblen Metrik-Endpunkt bereit, brauchst du keinen zusätzlichen Exporter. Für andere Systeme liefern passende Exporter die Metriken. Externe Targets kannst du beispielsweise über die ScrapeConfig-Ressource anbinden.

Ob du umgebende VMs im selben Prometheus oder getrennt vom Cluster-Monitoring überwachst, hängt von Zuständigkeiten, benötigten Prüfungen und der Frage ab, wer auf Alarme reagiert.

Für den Dauerbetrieb legst du außerdem fest, wie Zugangsschutz, Secret-Verwaltung, Datensicherung und Wiederherstellung funktionieren. Persistente Volumes erhalten Daten über Pod-Neustarts hinweg, ersetzen aber weder Backups noch eine passende Ausfallstrategie. Ob du mehrere Replikas oder zusätzlichen Langzeitspeicher wie Thanos oder Grafana Mimir benötigst, hängt von deinen Verfügbarkeits-, Skalierungs- und Aufbewahrungsanforderungen ab.

Fazit

Mit kube-prometheus-stack erhältst du eine gemeinsame Basis für Kubernetes-Metriken, Dashboards und Alarmierung. Für eine brauchbare Installation brauchst du passenden persistenten Speicher, eine festgelegte Chart-Version und eine nachvollziehbare Auswahl deiner Monitoring-Ressourcen.

Prüfe anschließend drei Dinge getrennt: Sind alle erwarteten Targets vorhanden und erreichbar? Erfassen deine Regeln die gewünschten Fehlerfälle? Kommen Benachrichtigungen beim Team an? Erst dieser vollständige Weg macht aus gesammelten Metriken ein Monitoring, auf das du im Betrieb zurückgreifen kannst.

Weitere Workloads im selben Cluster, etwa einen GitLab Runner auf Kubernetes, bindest du nach demselben Muster an, sofern sie einen Metrik-Endpunkt bereitstellen: Service mit benanntem Port, ServiceMonitor mit Release-Label und eine passende Regel.