Rancher 2.15: Monitoring sicher auf den Upstream-Stack migrieren

Rancher 2.15 trennt Monitoring in zwei Lebenszyklen

Rancher 2.15 verändert grundlegend, wie Kubernetes-Monitoring bereitgestellt wird. An die Stelle des monolithischen Komplett-Charts rancher-monitoring tritt eine entkoppelte Architektur: Das Upstream-Chart kube-prometheus-stack liefert Prometheus Operator, Prometheus, Alertmanager, Grafana, Exporter und Rules; rancher-monitoring-dashboards ergänzt Ranchers Dashboards und die Service-Proxys für die Rancher-Oberfläche.

In der offiziellen Dokumentation für Rancher 2.15 wirkt dieser Wechsel beinahe wie ein Ersatz mit zwei Klicks: zuerst die Runtime, dann die Dashboard-Integration. In realen Clustern entstehen die Risiken jedoch an den neuen Zuständigkeitsgrenzen. Proxy-Fehler bleiben bis zum HTTP 504 unsichtbar, CRDs folgen einem vom Helm-Release entkoppelten Lebenszyklus, und zu enge Selektoren erzeugen Scrape-Konfigurationen ohne die erwarteten Targets.

Im Monitoring-Proxy kann sich der Bruch zunächst nur so zeigen:

host not found in upstream
"kube-prometheus-stack-grafana.cattle-monitoring-system.svc.cluster.local"

Selbst nachdem die erwarteten Services existieren, kann ein bereits laufender NGINX-Proxy veraltete ClusterIPs behalten: Die Workloads wirken gesund, Rancher antwortet dennoch mit HTTP 504. Unabhängig davon können vorhandene ServiceMonitor-Objekte wegen der Standardselektoren vollständig aus der generierten Scrape-Konfiguration fehlen.

Dieses Runbook ist deshalb als praxiserprobtes Übergabehandbuch für Plattformteams geschrieben, die Rancher-2.15-Cluster neu aufsetzen oder bestehende Monitoring-Installationen migrieren. Es behandelt nicht nur die Installationsreihenfolge, sondern auch CRD-Zuständigkeit, Metrikhistorie, Storage, Selektoren, Dashboards, Alert-Routing und Recovery. Bestehende Legacy-Installationen bleiben unterstützt; für Neuinstallationen ist der getrennte Stack jedoch der offizielle Weg nach vorn.

---

Die neue Aufgabenteilung

Das bisherige Chart war bequem, weil Rancher das gesamte Monitoring in einer Release-Einheit auslieferte. Damit hing aber auch der Lebenszyklus eines umfangreichen Observability-Stacks an Ranchers Release-Zyklus. Durch die Trennung stammt die Runtime wieder aus dem verbreiteten prometheus-community Helm-Chart, während Rancher-spezifische UI-Bestandteile separat bleiben.

Bereich	Bisheriges rancher-monitoring	Getrennter Stack ab Rancher 2.15
Runtime	Gebündelte Rancher-Distribution	Upstream kube-prometheus-stack
Rancher-UI	Bestandteil desselben Releases	rancher-monitoring-dashboards mit Proxy
Operator und CRDs	An Rancher-Chartversion gebunden	Über das Upstream-Chart versioniert
Grafana-Dashboards	Runtime und Rancher-Dashboards gemeinsam	Dashboard-ConfigMaps unabhängig aktualisierbar
Upgrade-Zuständigkeit	Ein bequemer, aber grober Zyklus	Zwei getrennte und explizit gepinnte Zyklen
Portabilität	Rancher-spezifische Chartkonventionen	Standardressourcen des Prometheus Operators
Betriebsaufwand	Weniger Entscheidungen bei der Erstinstallation	Mehr Values- und Versionspflege, dafür klare Grenzen

Die Trennung ist technisch schlüssig. Prometheus, Grafana und Alertmanager brauchen keinen Rancher-spezifischen Fork, nur um innerhalb von Rancher erreichbar zu sein. Der Preis dafür ist transparent: Aus einer One-Click-App werden zwei Releases und eine Values-Datei, für die das Plattformteam Verantwortung übernimmt.

Zwischen den Charts besteht ein Namensvertrag. Bei einem Upstream-Release namens kube-prometheus-stack erwartet Ranchers Proxy folgende Services:

kube-prometheus-stack-grafana
kube-prometheus-stack-prometheus
kube-prometheus-stack-alertmanager

Nach außen stellt er die aus Rancher bekannten Namen bereit:

rancher-monitoring-grafana
rancher-monitoring-prometheus
rancher-monitoring-alertmanager

Ein anderer Helm-Releasename ist möglich, sofern zugleich die drei Upstream-Servicewerte im Dashboard-Chart angepasst werden. Der dokumentierte Name hält diese Fehlerquelle aus der Migration heraus.

---

Das fehlende Betriebshandbuch: fünf kritische Stellen

1. CRDs überleben Helm-Releases und wirken im gesamten Cluster

Prometheus, Alertmanager, ServiceMonitor, PodMonitor, PrometheusRule und AlertmanagerConfig sind keine internen, namespaced Details eines Helm-Releases. Ihre Definitionen bilden clusterweite APIs. Die zugehörigen Objekte können von Teams in zahlreichen Namespaces verwendet werden.

Helm installiert CRDs aus dem Verzeichnis crds/ vor den regulären Ressourcen, überspringt bereits vorhandene Definitionen und aktualisiert oder löscht sie absichtlich nicht. Damit verhindert Helm impliziten Datenverlust, überlässt Versions- und Zuständigkeitsfragen aber dem Betreiber. Dieses Verhalten ist in Helms Empfehlungen für CRDs beschrieben. Deshalb führt kube-prometheus-stack eigene Hinweise für CRD-Upgrades.

Die Migration darf nie mit dem Löschen der CRDs *.monitoring.coreos.com beginnen. Mit einer CRD verschwinden auch sämtliche Custom Resources dieser API. Zuerst inventarisieren und exportieren. Während der Übergabe sollte genau ein aktiver Prometheus Operator für die betreffenden Ressourcen zuständig sein. Zwei konkurrierende Operatoren sind keine Hochverfügbarkeit.

In der Praxis gibt es zwei saubere Vorgehensweisen:

• Geordnete Übergabe: Alle Monitoring-Ressourcen exportieren, die alte Runtime entfernen, weitere Abhängigkeiten von den CRDs ausschließen, die Definitionen auf den Stand des neuen Operators bringen und danach den Upstream-Stack installieren.
• Getrennter CRD-Lebenszyklus: Die Prometheus-Operator-CRDs als eigenes Plattformartefakt verwalten, vor dem neuen Operator in einer kompatiblen Version installieren und im Chart crds.enabled: false setzen. Das verlangt einen zusätzlichen Prozess, macht die Zuständigkeit für Cluster-APIs aber eindeutig.

Das crds.upgradeJob des Charts kann neuere Definitionen anwenden. In Chartversion 88.3.0 ist diese Funktion allerdings als Preview gekennzeichnet und benötigt clusterweites RBAC. Das ist eine Architekturentscheidung, kein schneller Workaround während einer Störung.

2. Ein behaltenes PVC ist noch keine Migration der Metrikhistorie

Prometheus speichert lokale TSDB-Blöcke und ein Write-Ahead Log auf seinem Datenvolume. Dieser lokale Speicher ist weder geclustert noch repliziert. Das Prometheus-Projekt empfiehlt Snapshots für konsistente Backups und weist darauf hin, dass eine Kopie des laufenden TSDB-Verzeichnisses aktuelle Daten verlieren oder einen inkonsistenten Stand erfassen kann. Die offizielle Storage-Dokumentation erläutert Block- und WAL-Struktur.

Vor dem Entfernen des alten Releases muss eine dieser Varianten feststehen:

• Sauberer Schnitt: Der neue Prometheus beginnt mit einem leeren PVC. Das alte Volume bleibt für ein klar begrenztes Rollback-Zeitfenster erhalten.
• Snapshot und Restore: Die TSDB-Admin-API wird vorübergehend freigeschaltet, ein Snapshot erzeugt, mit Storage-Werkzeugen kopiert und in einer kompatiblen Prometheus-Version testweise wiederhergestellt. Das ist ein eigenes Migrationsvorhaben.
• Historie außerhalb des Pods: Remote Write oder ein Langzeitspeicher wie Thanos, Mimir beziehungsweise ein anderer kompatibler Backend-Dienst übernimmt die Zeitreihen. Langfristig ist das die sauberste Grenze, kurzfristig jedoch kein gefahrloser Schalter.

Das alte PVC sollte nicht allein deshalb in das neue StatefulSet eingehängt werden, weil das Dateisystem erreichbar ist. Zuvor sind Prometheus-Versionen, AccessMode, SecurityContext, Benennung der StatefulSet-Claims und der Rückweg zu prüfen.

3. ServiceMonitors können vorhanden sein und trotzdem ignoriert werden

Der Prometheus Operator ordnet ServiceMonitor- und PodMonitor-Objekte über Label- und Namespace-Selektoren einem Prometheus-Objekt zu. Das Upstream-Chart begrenzt die Erkennung normalerweise auf Monitore mit den Labels seines Helm-Releases. Von Rancher oder Anwendungen bereitgestellte Monitore tragen diese Labels nicht zwingend.

Der Fehler bleibt unauffällig: ServiceMonitor und Ziel-Service existieren, Prometheus erzeugt dennoch keinen Scrape-Job. Im Troubleshooting des Prometheus Operators ist beschrieben, wie sich die generierte Konfiguration kontrollieren lässt.

Für einen zentralen Plattform-Prometheus verwendeten wir:

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelector: {}
    serviceMonitorNamespaceSelector: {}
    podMonitorSelector: {}
    podMonitorNamespaceSelector: {}

Ein leerer Selektor erfasst alle passenden Objekte; ein nicht gesetzter Selektor besitzt je nach Feld eine andere Bedeutung. Die breite Erkennung passt nur, wenn das Plattformteam die Berechtigung zum Anlegen von Monitoring-Ressourcen kontrolliert. In einem Multi-Tenant-Cluster sollten Namespace-Labels und ein explizites Monitor-Label beliebige clusterweite Scrape-Konfigurationen verhindern.

4. Rancher-Dashboards sind provisionierte Dateien, keine Grafana-Plugins

Das Dashboard-Chart installiert weder eine Grafana-Erweiterungs-CRD noch ein Plugin. Es erzeugt Dashboard-ConfigMaps, üblicherweise in cattle-dashboards, mit diesem Label:

grafana_dashboard: "1"

Der Grafana-Sidecar beobachtet entsprechend markierte ConfigMaps und Secrets namespaceübergreifend, schreibt die enthaltenen JSON-Dateien nach /tmp/dashboards und stößt das Neuladen der Grafana-Provisionierung an. Grafana liest diese Dateien über einen Provisioning-Provider ein. Die Grundlage dafür ist Grafanas reguläre Dashboard-Provisionierung.

Eigene Dashboards lassen sich somit vollständig als Kubernetes-Objekte per GitOps verwalten. JSON-Dateien von Grafana.com benötigen dabei meist eine Nachbearbeitung. Der interaktive Import ersetzt Variablen wie ${DS_PROMETHEUS}; die dateibasierte Provisionierung tut das nicht. Fest eingetragene Datasource-UIDs sind ebenfalls unzuverlässig. Alle Prometheus-Referenzen müssen auf die vom Chart erzeugte UID prometheus zeigen, der Importblock __inputs kann entfernt werden.

5. Installationsvorgaben ersetzen keine Kapazitätsplanung

Scrape-Intervall, Aufbewahrungsdauer, Kardinalität, Anzahl der Rules und parallele Grafana-Abfragen bestimmen den tatsächlichen Ressourcenbedarf. Die von Rancher für K3s genannten 1.750 MiB Request und 2.500 MiB Limit funktionierten in unserem kleinen Cluster als Startwert. Eine allgemeine Dimensionierung lässt sich daraus nicht ableiten.

Der Admission Webhook des Prometheus Operators sollte aktiv bleiben. Er weist fehlerhafte PrometheusRule-Objekte zurück, bevor sie das Laden von Rules beeinträchtigen. Wenn Certificate-Patch-Job oder Webhook-Endpunkt ausfallen, muss diese Abhängigkeit repariert werden. Eine dauerhaft auf Ignore gesetzte FailurePolicy verschiebt das Problem lediglich in den späteren Betrieb.

---

Runbook für die Migration

Die folgenden Befehle gehen von rancher.yaml als Kubeconfig, dem Kontext rancher und dem Namespace cattle-monitoring-system aus. Chartversionen gehören auf einen getesteten Stand gepinnt. In unserer Installation liefen kube-prometheus-stack 88.3.0 mit Prometheus Operator 0.93.0 sowie rancher-monitoring-dashboards 110.0.0+up0.1.2.

Phase 0: Änderungen stoppen und Istzustand sichern

Diese Bestandsaufnahme erfolgt vor jeder Deinstallation:

export KUBECONFIG="$PWD/rancher.yaml"
export MONITORING_NAMESPACE="cattle-monitoring-system"

kubectl config current-context
helm list -A | grep -E 'rancher-monitoring|kube-prometheus'

helm -n "$MONITORING_NAMESPACE" \
  get values rancher-monitoring --all > legacy-rancher-monitoring-values.yaml

kubectl get crd | grep monitoring.coreos.com
kubectl get prometheuses,alertmanagers,servicemonitors,podmonitors,prometheusrules \
  -A -o wide
kubectl -n "$MONITORING_NAMESPACE" get pvc
kubectl get pv -o custom-columns='NAME:.metadata.name,CLAIM_NAMESPACE:.spec.claimRef.namespace,CLAIM_NAME:.spec.claimRef.name,RECLAIM:.spec.persistentVolumeReclaimPolicy,CLASS:.spec.storageClassName'

Anschließend werden die Custom Resources exportiert. Das Backup gehört an einen geschützten Ort, da Rules und Endpunkte interne Topologie offenlegen können.

for resource in \
  prometheuses.monitoring.coreos.com \
  alertmanagers.monitoring.coreos.com \
  servicemonitors.monitoring.coreos.com \
  podmonitors.monitoring.coreos.com \
  prometheusrules.monitoring.coreos.com \
  alertmanagerconfigs.monitoring.coreos.com
do
  kubectl get "$resource" -A -o yaml > "backup-${resource%%.*}.yaml"
done

Die Prometheus-Versionen vor und nach der Migration werden dokumentiert. Jetzt fällt auch die Entscheidung zwischen Neustart der Historie, Snapshot-Migration und externer Aufbewahrung. Soll das alte PV das Löschen seines Claims überstehen, sind vorab das Verhalten des Storage-Treibers und die ReclaimPolicy Retain zu prüfen. Retain schützt vor automatischer Löschung des Backends, ersetzt aber kein Backup.

Phase 1: Alten Monitoring-Stack entfernen, APIs bewusst erhalten

Während der Übergabe werden Monitoring-Ressourcen nicht verändert. Die bisherige App rancher-monitoring lässt sich in Rancher unter Apps > Installed Apps entfernen. Wurde das Release unmittelbar mit Helm verwaltet, lautet der entsprechende Befehl:

helm -n "$MONITORING_NAMESPACE" uninstall rancher-monitoring

Ein separates CRD-Release wird nicht pauschal mit deinstalliert; kubectl delete crd ist tabu. Zuerst prüfen wir, ob der alte Prometheus, Alertmanager, das Operator-Deployment und zugehörige Webhooks verschwunden sind, während exportierte ServiceMonitor- und PrometheusRule-Objekte weiterhin verfügbar bleiben.

kubectl -n "$MONITORING_NAMESPACE" get \
  deploy,statefulset,daemonset,job,pod,pvc
kubectl get validatingwebhookconfiguration,mutatingwebhookconfiguration \
  | grep -E 'prometheus|monitoring' || true

Kollidieren alte Hooks, Webhooks, ClusterRoles oder Services mit dem neuen Release, zeigen Labels und Annotations deren Besitzer. Metadaten werden nicht überschrieben, bevor klar ist, welcher Controller die Ressource noch verwendet.

Bevor ein neuerer Operator mit den behaltenen CRDs startet, prüfen wir die tatsächliche Schemaänderung und wenden die Definitionen genau jener Chartversion an, die anschließend installiert wird:

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

helm show crds prometheus-community/kube-prometheus-stack \
  --version 88.3.0 > kube-prometheus-stack-crds-88.3.0.yaml

kubectl diff -f kube-prometheus-stack-crds-88.3.0.yaml
kubectl apply --server-side \
  --field-manager=kube-prometheus-stack-crds \
  -f kube-prometheus-stack-crds-88.3.0.yaml

Meldet Server-Side Apply einen Zuständigkeitskonflikt, wird an dieser Stelle gestoppt. Der Konflikt ist gemeinsam mit dem Controller aufzulösen, der die betroffenen Felder aktuell verwaltet. --force-conflicts gehört nicht als pauschaler Migrationsparameter in das Runbook. Bei einem eigenständigen CRD-Lebenszyklus wird dieses gerenderte Artefakt versioniert und wie jede Änderung einer Cluster-API geprüft; in den nachfolgenden Values steht dann crds.enabled: false.

Phase 2: Eine eigene values.yaml festlegen

Diese kompakte Konfiguration lief auf unserem Single-Node-K3s-Cluster. Sie enthält sowohl Ranchers Integrationsvorgaben als auch die während der Installation nötigen Korrekturen:

crds:
  enabled: true
  upgradeJob:
    enabled: false

grafana:
  grafana.ini:
    security:
      allow_embedding: true
    auth:
      disable_login_form: false
    auth.anonymous:
      enabled: true
      org_role: Viewer
    dashboards:
      default_home_dashboard_path: /tmp/dashboards/rancher-default-home.json
    users:
      auto_assign_org_role: Viewer

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelector: {}
    serviceMonitorNamespaceSelector: {}
    podMonitorSelector: {}
    podMonitorNamespaceSelector: {}
    scrapeInterval: 30s
    evaluationInterval: 30s
    retention: 15d
    resources:
      requests:
        cpu: 250m
        memory: 1750Mi
      limits:
        memory: 2500Mi

prometheusOperator:
  admissionWebhooks:
    enabled: true

# Für diese Control-Plane-Komponenten verwendet K3s Ranchers PushProx-Pfad.
kubeEtcd:
  enabled: false
kubeControllerManager:
  enabled: false
kubeScheduler:
  enabled: false
kubeProxy:
  enabled: false

Auf einer regulären Kubernetes-Distribution sollten die vier deaktivierten Komponenten nicht ungeprüft übernommen werden.

Für dauerhaften Produktionsspeicher ergänzen wir eine getestete StorageClass und lassen Abstand zwischen PVC-Größe und RetentionSize:

prometheus:
  prometheusSpec:
    retention: 15d
    retentionSize: 40GB
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: longhorn
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 50Gi

grafana:
  persistence:
    enabled: true
    storageClassName: longhorn
    size: 5Gi

longhorn ist durch eine tatsächlich betriebene und im Restore getestete StorageClass zu ersetzen. Provisionierte Dashboards hängen nicht an Grafanas Datenbank; Benutzer, Änderungen über die UI, Einstellungen und anderer veränderlicher Zustand dagegen schon.

Phase 3: Zuerst die Upstream-Runtime installieren

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

helm upgrade --install kube-prometheus-stack \
  prometheus-community/kube-prometheus-stack \
  --version 88.3.0 \
  --namespace "$MONITORING_NAMESPACE" \
  --create-namespace \
  --values kube-prometheus-stack-values.yaml \
  --wait \
  --timeout 15m

Prometheus, Alertmanager, Grafana, Operator, kube-state-metrics und node-exporter müssen bereit sein. Ein Helm-Release in pending-install wird nicht durch wiederholte Installationsversuche gesund. Zuerst werden Hooks, Jobs, Events, Webhook-Zertifikate und PVCs untersucht.

helm -n "$MONITORING_NAMESPACE" status kube-prometheus-stack
kubectl -n "$MONITORING_NAMESPACE" get pods,pvc
kubectl -n "$MONITORING_NAMESPACE" get events \
  --sort-by=.lastTimestamp | tail -40

Phase 4: Ranchers Dashboard-Integration ergänzen

rancher-monitoring-dashboards wird erst aus Ranchers 2.15-Chartkatalog installiert, wenn die drei Upstream-Services existieren. Die Rancher-Oberfläche ist an dieser Stelle hilfreich: Sie übergibt Cluster-ID, Clustername, Rancher-URL und System-Project-ID automatisch.

Unter Apps > Charts wählen wir rancher-monitoring-dashboards, als Ziel cattle-monitoring-system und behalten die vorgegebenen Upstream-Servicenamen, wenn das Runtime-Release kube-prometheus-stack heißt. Für K3s bleibt k3sServer.enabled: true, bei anderen Distributionen wird der Wert entsprechend der Chartbeschreibung deaktiviert.

Wurde das Dashboard-Chart zu früh installiert, folgt ein Upgrade beziehungsweise Retry, sobald die Runtime bereit ist. Nach einer vollständigen Neuinstallation der Runtime starten wir nur den Proxy neu. Dadurch löst NGINX die geänderten Service-ClusterIPs erneut auf:

kubectl -n "$MONITORING_NAMESPACE" rollout restart \
  deployment/rancher-monitoring-dashboards-monitoring-proxy
kubectl -n "$MONITORING_NAMESPACE" rollout status \
  deployment/rancher-monitoring-dashboards-monitoring-proxy \
  --timeout=3m

Genau dieser Neustart beseitigte in unserer Installation den HTTP 504 nach dem Neuaufsetzen des Upstream-Releases.

Phase 5: Eigene Dashboards als Kubernetes-Objekte verwalten

Für Dashboard 17682, Kubernetes PersistentVolume Overview, haben wir die JSON-Datei geladen, __inputs entfernt und sämtliche Prometheus-Datasource-UIDs auf prometheus vereinheitlicht. Das eingecheckte Objekt folgt diesem Aufbau:

apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboard-kubernetes-persistentvolume-overview
  namespace: cattle-dashboards
  labels:
    grafana_dashboard: "1"
    app.kubernetes.io/part-of: custom-grafana-dashboards
  annotations:
    grafana.com/dashboard-id: "17682"
    grafana.com/dashboard-revision: "1"
data:
  kubernetes-persistentvolume-overview.json: |-
    {
      "id": null,
      "uid": "peR80gTGk",
      "title": "Kubernetes PersistentVolume Overview",
      "schemaVersion": 38,
      "version": 1,
      "panels": [
        {
          "id": 1,
          "type": "timeseries",
          "title": "PersistentVolume usage",
          "datasource": {
            "type": "prometheus",
            "uid": "prometheus"
          },
          "targets": [
            {
              "refId": "A",
              "expr": "100 * kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes"
            }
          ]
        }
      ]
    }

Die gekürzte JSON-Datei zeigt nur die Objektstruktur. Im angewendeten Manifest muss der vollständige Dashboard-Export stehen.

kubectl apply -f grafana-dashboard-kubernetes-persistentvolume-overview.yaml

Weitere Dashboards folgen demselben Ablauf: Revision fest pinnen, Dateiname und UID stabil halten, Datasource-UIDs normalisieren, reine Importparameter entfernen, grafana_dashboard: "1" setzen und die ConfigMap anwenden. PromQL aus fremden Dashboards gehört vor der Übernahme geprüft. Abfragen können Metriknamen oder Labels voraussetzen, die die eigenen Exporter nicht liefern.

Sidecar-provisionierte Dashboards sind deklarativ. Bei allowUiUpdates: false wird deshalb die ConfigMap als Quelle geändert, nicht das Dashboard in der Grafana-Oberfläche. Andernfalls überschreibt der nächste Abgleich die UI-Anpassung. Eigene Dashboards erscheinen in Grafana, erzeugen aber keinen zusätzlichen Rancher-Menüpunkt. Ranchers integrierte Links verweisen auf bekannte Dashboard-UIDs.

Phase 6: Vorhandene Alerts per AlertmanagerConfig routen

Eine AlertmanagerConfig verteilt Alerts, die bereits von PrometheusRule-Objekten erzeugt werden. Sie definiert selbst keine Alert-Regel. Für unsere n8n-Anbindung war keine eigene Rule nötig, weil der Stack die betreffenden Alerts schon erzeugte.

Zuerst erhält die Alertmanager-Custom-Resource Selektoren, die ausschließlich ausdrücklich markierte Configs aus dem geschützten Monitoring-Namespace laden:

alertmanager:
  alertmanagerSpec:
    alertmanagerConfigSelector:
      matchLabels:
        alertmanagerconfig: n8n-webhook
    alertmanagerConfigNamespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: cattle-monitoring-system
    alertmanagerConfigMatcherStrategy:
      type: None

Der Operator verwendet standardmäßig die Matcher-Strategie OnNamespace. Sie beschränkt eine Config auf Alerts, deren namespace-Label mit dem Namespace der Config übereinstimmt. Eine zentrale Config in cattle-monitoring-system würde dadurch einen Großteil der Workload-Alerts nicht erfassen. None erlaubt clusterweites Matching; die beiden Selektoren begrenzen gleichzeitig, wer eine solche Route bereitstellen darf. Die genaue Semantik steht in der API-Referenz des Prometheus Operators.

Für ein leicht nachvollziehbares Beispiel steht die Platzhalter-URL direkt in der AlertmanagerConfig. So bleibt die eigentliche Routing-Logik ohne zusätzliches Secret-Objekt sichtbar:

apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: n8n-webhook
  namespace: cattle-monitoring-system
  labels:
    alertmanagerconfig: n8n-webhook
spec:
  route:
    receiver: n8n-webhook
    groupBy:
      - namespace
      - alertname
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 4h
    matchers:
      - name: alertname
        matchType: "!~"
        value: "Watchdog|InfoInhibitor"
  receivers:
    - name: n8n-webhook
      webhookConfigs:
        - url: "https://n8n.example.com/webhook/..."
          sendResolved: true
          timeout: 10s

Danach werden Helm-Werte und Objekt angewendet:

helm upgrade kube-prometheus-stack \
  prometheus-community/kube-prometheus-stack \
  --version 88.3.0 \
  --namespace "$MONITORING_NAMESPACE" \
  --values kube-prometheus-stack-values.yaml \
  --wait --timeout 15m

kubectl apply -f alertmanager-n8n-webhook.yaml

Der Test dieser Route mit einem realen Host-Alert, bei uns der Zeitabweichungswarnung NodeClockNotSynchronising - bestätigte zusammen mit der anschließenden Resolved-Meldung die End-to-End-Zustellung bis n8n.

Der Webhook-Pfad ist wie ein Zugangstoken zu behandeln: In einer Produktionsumgebung wird der Platzhalter beim Deployment über das etablierte Secret-Management ersetzt, die echte URL jedoch nicht ins Git-Repository eingecheckt.

---

Checkliste für die Abnahme

Zwei Helm-Releases mit Status deployed reichen nicht als Abnahme. Diese fünf Prüfungen decken die entscheidenden Schnittstellen ab.

• Workloads und Storage: Alle dauerhaft laufenden Pods sind Ready, Prometheus besitzt das vorgesehene PVC und kein unerwartetes emptyDir hat den persistenten Speicher ersetzt.

  helm -n "$MONITORING_NAMESPACE" list
  kubectl -n "$MONITORING_NAMESPACE" get pods,pvc
  

• Rancher-Proxys: Grafana, Prometheus und Alertmanager antworten über die Rancher-seitigen Services.

  kubectl -n "$MONITORING_NAMESPACE" exec \
    deployment/rancher-monitoring-dashboards-monitoring-proxy -- \
    wget -qO- http://rancher-monitoring-grafana/api/health
  
  kubectl -n "$MONITORING_NAMESPACE" exec \
    deployment/rancher-monitoring-dashboards-monitoring-proxy -- \
    wget -qO- http://rancher-monitoring-prometheus:9090/-/ready
  
  kubectl -n "$MONITORING_NAMESPACE" exec \
    deployment/rancher-monitoring-dashboards-monitoring-proxy -- \
    wget -qO- http://rancher-monitoring-alertmanager:9093/-/ready
  

• Target-Erkennung: Die API für aktive Targets enthält keine ungeklärten down-Ziele. Die ServiceMonitors der Anwendungen tauchen in der generierten Prometheus-Konfiguration auf.

  kubectl -n "$MONITORING_NAMESPACE" port-forward \
    svc/kube-prometheus-stack-prometheus 9090:9090
  curl -fsS 'http://127.0.0.1:9090/api/v1/targets?state=active' \
    | jq -r '[.data.activeTargets[].health] | group_by(.)[] | "\(.[0]): \(length)"'
  

• Dashboard-Provisionierung und Rancher-UI: Ranchers Monitoring-Menü öffnet Grafana, Prometheus Targets und Alertmanager. Die Grafana-Suche findet Ranchers Dashboards sowie die eigene UID peR80gTGk.

  kubectl -n "$MONITORING_NAMESPACE" port-forward \
    svc/kube-prometheus-stack-grafana 3000:80
  curl -fsS 'http://127.0.0.1:3000/api/search?query=Rancher' | jq length
  

• Alert-Zustellung: Die gerenderte Alertmanager-Konfiguration enthält den n8n-Receiver, das letzte Reload war erfolgreich, ein kontrollierter Test-Alert trifft genau einmal ein und nach dessen Ende folgt die Resolved-Nachricht. Vor der Freigabe werden außerdem die Fehlerzähler des Receivers kontrolliert.

Unser Endzustand bestand aus zwei deployten Releases, vollständig bereiten Pods, 15 von 15 erreichbaren Prometheus-Targets, 16 geladenen Rancher-Dashboards und einer erfolgreichen n8n-Zustellung. Diese Zahlen dokumentieren den getesteten Cluster und sind keine allgemeingültigen Sollwerte.

---

Was nach der Migration besser wartbar ist

Das sichtbare Ergebnis ist nicht bloß ein weiteres Dashboard, sondern eine klare Zuständigkeitsgrenze.

Der Prometheus Operator lässt sich nach Prüfung seiner Upstream-Hinweise zu CRDs und inkompatiblen Änderungen aktualisieren, ohne auf ein Rancher-spezifisches Runtime-Chart zu warten. Ranchers Dashboards folgen ihrem eigenen Zyklus. Anwendungsteams nutzen weiterhin die Standardressourcen ServiceMonitor, PodMonitor und PrometheusRule. Eigene Grafana-Dashboards und Alert-Routen liegen als überprüfbare Kubernetes-Manifeste vor statt ausschließlich als UI-Zustand.

Die anspruchsvollen Aufgaben bleiben beim Plattformteam: getestete Chart-Pins, CRD-Upgrades, Storage und Retention, Grenzen der Selektoren, Webhook-Zugangsdaten sowie Restore-Übungen. Die Charttrennung beseitigt diese Arbeit nicht. Sie ordnet sie den Upstream-Komponenten zu, deren Dokumentation und Werkzeuge unmittelbar anwendbar sind.

Meine Empfehlung aus Betriebssicht: Die Umstellung mit repräsentativen CRDs und Storage in einer Testumgebung proben, das alte PV für ein zeitlich begrenztes Rollback behalten und nach jeder Neuerstellung der Runtime den Rancher-Proxy prüfen. Dashboards und Alert-Routen gehören von Anfang an in Versionsverwaltung. So bleibt ein standardnaher Prometheus-Stack mit einer kleinen Rancher-Integrationsschicht statt einer dauerhaften Bindung an einen herstellerspezifischen Release-Zyklus.

An dieser Zuständigkeitsgrenze kann eine erfahrene technische Zweitmeinung teure Fehlentscheidungen verhindern. Wenn Sie eine Rancher-Monitoring-Migration, eine CRD-Übergabe oder das Prometheus-Storage planen, kontaktieren Sie uns; eine kurze Prüfung vor der Deinstallation ist erheblich günstiger als die Rekonstruktion gelöschter Monitoring-APIs oder einer unerwartet verlorenen Metrikhistorie.