Kubernetes Monitoring: 60% Kosten sparen mit dem richtigen Stack

TL;DR

• Datadog und Co. kosten bei 50+ Nodes schnell 5.000-15.000 EUR/Monat -- Prometheus + Grafana + Alertmanager erledigen 90% der Aufgaben fuer unter 500 EUR Infrastrukturkosten.
• Retention-Optimierung allein spart 30-40%: 80% der Queries betreffen die letzten 24 Stunden, trotzdem speichern die meisten Teams 90 Tage in voller Aufloesung.
• Alert Fatigue ist ein versteckter Kostentreiber: Teams mit 200+ Alerts pro Woche verbringen 15-20 Stunden mit Alert-Triage statt mit produktiver Arbeit.
• Der optimale Stack fuer den Mittelstand: Prometheus (Metriken), Loki (Logs), Grafana (Dashboards), Alertmanager (Benachrichtigungen) -- alles Open Source, alles Kubernetes-nativ.
• Downsampling und Recording Rules reduzieren den Storage-Bedarf um 50-70% ohne Informationsverlust fuer historische Analysen.

Warum Monitoring-Kosten ausser Kontrolle geraten

Monitoring ist wie eine Versicherung: Man merkt erst, was man hat, wenn etwas schiefgeht. Deshalb neigen Teams dazu, alles zu messen, alles zu speichern und alles zu alarmen. Das Ergebnis: explodierende Kosten bei sinkendem Nutzen.

Die typische Entwicklung sieht so aus:

Monat 1:   Basismetriken, 20 Alerts, 500 EUR/Monat
Monat 6:   Custom Metrics, 80 Alerts, 2.000 EUR/Monat
Monat 12:  APM + Tracing, 200 Alerts, 8.000 EUR/Monat
Monat 18:  "Wir brauchen ein groesseres Budget" -- 12.000 EUR/Monat

Das Problem ist nicht Monitoring an sich. Das Problem sind drei Fehler, die fast jedes Team macht: zu teure Tools, zu lange Retention und zu viele Alerts.

Kostenvergleich: Prometheus vs. Datadog vs. Managed Monitoring

Bevor Sie sich fuer einen Stack entscheiden, muessen Sie die tatsaechlichen Kosten verstehen. Die Lizenzkosten sind nur die Spitze des Eisbergs -- Betriebsaufwand, Engineering-Time und Opportunitaetskosten zaehlen mit.

Kostenmatrix fuer einen typischen Mittelstands-Cluster

Annahme: 30 Nodes, 300 Pods, 50.000 aktive Metriken, 30 Tage Retention.

Die Zahlen sprechen eine klare Sprache: Bei einem Self-Managed Prometheus-Stack sparen Sie gegenueber Datadog rund 70%. Gegenueber Google Cloud Monitoring sind es immer noch 40-50%.

Aber: Self-Managed bedeutet, dass Ihr Team den Stack betreiben muss. Wenn Sie nur einen DevOps-Engineer haben, der bereits am Limit arbeitet, kann Grafana Cloud die bessere Wahl sein -- die Kosten liegen aehnlich, der Betriebsaufwand ist deutlich geringer.

Der optimale Monitoring-Stack fuer den Mittelstand

Fuer die meisten Mittelstandsunternehmen mit 10-100 Nodes empfehlen wir diesen Stack:

Installation: Der vollstaendige Stack in 10 Minuten

# Namespace erstellen
kubectl create namespace monitoring

# kube-prometheus-stack (Prometheus + Grafana + Alertmanager)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set prometheus.prometheusSpec.retention=15d \
  --set prometheus.prometheusSpec.retentionSize=40GB \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi \
  --set prometheus.prometheusSpec.resources.requests.memory=2Gi \
  --set prometheus.prometheusSpec.resources.limits.memory=4Gi \
  --set grafana.persistence.enabled=true \
  --set grafana.persistence.size=5Gi

# Loki fuer Logs (kosteneffizient statt ELK)
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack \
  --namespace monitoring \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=100Gi \
  --set promtail.enabled=true

# OpenCost fuer Kosten-Transparenz
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost \
  --namespace monitoring

Gesamte Infrastrukturkosten fuer diesen Stack: 300-500 EUR/Monat bei einem typischen Cloud-Provider. Das ist ein Bruchteil dessen, was kommerzielle Loesungen kosten.

Retention-Optimierung: Wo das groesste Sparpotenzial liegt

Die meisten Teams speichern alle Metriken in voller Aufloesung fuer 30, 60 oder sogar 90 Tage. Das ist in den meisten Faellen Verschwendung.

Analyse: Welche Daten werden wirklich abgefragt?

Aus der Praxis mit ueber 20 Mittelstands-Clustern:

Letzte 1 Stunde:     45% aller Queries
Letzte 24 Stunden:   35% aller Queries
Letzte 7 Tage:       15% aller Queries
Aelter als 7 Tage:    5% aller Queries

95% aller Queries betreffen Daten der letzten 7 Tage. Trotzdem zahlen Sie fuer 30-90 Tage volle Aufloesung.

Loesung: Recording Rules und Downsampling

Recording Rules aggregieren haeufig genutzte Queries vorab und speichern das Ergebnis als neue Zeitreihe. Das reduziert sowohl die Query-Last als auch den Storage-Bedarf.

# prometheus-recording-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: cost-optimized-recording-rules
  namespace: monitoring
spec:
  groups:
    - name: downsampled-metrics
      interval: 5m
      rules:
        # CPU-Auslastung pro Namespace (5-Minuten-Durchschnitt)
        - record: namespace:cpu_usage:avg5m
          expr: |
            avg by (namespace) (
              rate(container_cpu_usage_seconds_total{container!=""}[5m])
            )

        # Memory pro Namespace (5-Minuten-Durchschnitt)
        - record: namespace:memory_usage_bytes:avg5m
          expr: |
            sum by (namespace) (
              container_memory_working_set_bytes{container!=""}
            )

        # Pod-Restart-Rate pro Deployment (stuendlich)
        - record: deployment:pod_restarts:rate1h
          expr: |
            sum by (namespace, deployment) (
              increase(kube_pod_container_status_restarts_total[1h])
            )

        # Request-Latenz P99 pro Service (5-Minuten-Fenster)
        - record: service:http_request_duration:p99_5m
          expr: |
            histogram_quantile(0.99,
              sum by (namespace, service, le) (
                rate(http_request_duration_seconds_bucket[5m])
              )
            )

Retention-Strategie: Drei Stufen

Mit Thanos oder Cortex laesst sich diese dreistufige Retention automatisieren. Fuer die meisten Mittelstands-Cluster reicht die Kombination aus Recording Rules und einer Prometheus-Retention von 15 Tagen voellig aus.

Ersparnis: 50-70% weniger Storage-Bedarf, 30-40% schnellere Queries.

Alert Fatigue eliminieren: Weniger Alerts, schnellere Reaktion

Alert Fatigue ist der Zustand, in dem Ihr Team so viele Alerts erhaelt, dass es aufhoert, sie ernst zu nehmen. Das ist nicht nur ein Produktivitaetsproblem -- es ist ein Sicherheitsrisiko.

Symptome erkennen

Typische Alert-Fatigue-Indikatoren:

- Mehr als 50 Alerts pro Woche pro Engineer
- Alert-Acknowledge-Time ueber 30 Minuten
- Mehr als 60% der Alerts sind False Positives
- Team hat Slack-Channel auf "Mute" gestellt
- Kritische Alerts gehen in der Masse unter

Die Alert-Pyramide: Struktur statt Chaos

Nicht jeder Alert muss sofort jemanden aus dem Bett klingeln. Strukturieren Sie Ihre Alerts in drei Ebenen:

Alertmanager-Konfiguration fuer die Pyramide

# alertmanager-config.yaml
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: cost-optimized-routing
  namespace: monitoring
spec:
  route:
    receiver: default-slack
    groupBy: ['namespace', 'alertname']
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 4h
    routes:
      # P1: Sofort per PagerDuty
      - matchers:
          - name: severity
            value: critical
        receiver: pagerduty-critical
        repeatInterval: 15m
        continue: false

      # P2: Ticket erstellen
      - matchers:
          - name: severity
            value: warning
        receiver: jira-ticket
        repeatInterval: 8h
        groupWait: 5m
        continue: false

      # P3: Nur Dashboard/Slack
      - matchers:
          - name: severity
            value: info
        receiver: default-slack
        repeatInterval: 24h

  receivers:
    - name: pagerduty-critical
      pagerdutyConfigs:
        - serviceKey:
            name: pagerduty-secret
            key: service-key
          description: '{{ .CommonAnnotations.summary }}'

    - name: jira-ticket
      webhookConfigs:
        - url: 'http://alertmanager-jira-bridge:8080/create'

    - name: default-slack
      slackConfigs:
        - channel: '#k8s-monitoring'
          sendResolved: true
          title: '{{ .CommonAnnotations.summary }}'

Alert-Hygiene: Quartalszyklus einfuehren

Planen Sie alle 3 Monate einen Alert-Review ein:

1. Alle Alerts der letzten 90 Tage exportieren (Alertmanager API)
2. False-Positive-Rate pro Alert berechnen -- alles ueber 30% wird ueberarbeitet oder entfernt
3. Actionability pruefen: Fuehrt der Alert zu einer konkreten Aktion? Wenn nein, ist es kein Alert, sondern ein Log-Eintrag
4. Thresholds anpassen: Statische Thresholds durch dynamische ersetzen (z.B. Standardabweichung statt feste Prozentzahl)

Erfahrungswert: Nach dem ersten Review fallen 40-60% der Alerts weg. Die verbleibenden sind die, die wirklich zaehlen.

Loki statt ELK: 80% guenstiger loggen

Der ELK-Stack (Elasticsearch, Logstash, Kibana) ist der Platzhirsch im Log-Management. Aber fuer Kubernetes-Workloads ist er oft ueberdimensioniert -- und teuer.

Loki speichert Logs nicht als vollindizierten Text, sondern als Chunks, die nur ueber Labels adressiert werden. Das spart enorm viel Storage und RAM, ist aber ein Trade-off: Freitextsuche ueber Millionen Logzeilen ist mit Loki langsamer als mit Elasticsearch.

Fuer den typischen Kubernetes-Use-Case (Fehlersuche in einem bestimmten Pod/Namespace in einem bestimmten Zeitfenster) ist Loki mehr als ausreichend -- und 80% guenstiger.

Praxis-Checkliste: Monitoring-Kosten in 5 Schritten senken

Wenn Sie heute anfangen wollen, Ihre Monitoring-Kosten zu senken, arbeiten Sie diese Checkliste ab:

Schritt 1: Kosten-Inventur (Tag 1)

• Aktuelle Monitoring-Kosten erfassen (Lizenzen, Infrastruktur, Personalaufwand)
• Anzahl aktiver Metriken, Log-Volumen und Retention ermitteln
• Benchmarken gegen die Kostenmatrix oben

Schritt 2: Retention ueberpruefen (Woche 1)

• Query-Muster analysieren: Welche Zeitraeume werden tatsaechlich abgefragt?
• Recording Rules fuer Top-20-Queries einrichten
• Retention auf 15 Tage reduzieren (wenn keine Compliance-Anforderung dagegen spricht)

Schritt 3: Alert-Review durchfuehren (Woche 2)

• Alle Alerts auflisten und nach Haeufigkeit sortieren
• False-Positive-Rate pro Alert berechnen
• Alert-Pyramide einfuehren (P1/P2/P3)
• Alles ueber 30% False Positives ueberarbeiten oder entfernen

Schritt 4: Tooling evaluieren (Woche 3-4)

• Wenn SaaS: Kosten pro Metrik und pro Host berechnen
• Wenn Self-Managed: Betriebsaufwand ehrlich bewerten
• Bei Datadog/New Relic: Prometheus + Grafana als Alternative testen

Schritt 5: Kontinuierliche Optimierung (laufend)

• Monatliches Kosten-Review im Team
• Quartalszyklus fuer Alert-Hygiene
• Jaehrlicher Stack-Review: Stimmt das Tooling noch?

Wann lohnt sich ein kommerzielles Tool trotzdem?

Self-Managed Prometheus ist nicht immer die beste Wahl. Kommerzielle Tools haben ihre Berechtigung:

• Weniger als 2 DevOps-Engineers im Team: Der Betriebsaufwand fuer einen Self-Managed Stack kann den Kostenvorteil auffressen. Grafana Cloud ist dann oft der bessere Kompromiss.
• APM und Distributed Tracing sind Pflicht: Wenn Ihre Microservices-Architektur so komplex ist, dass Sie Request-Tracing ueber 10+ Services brauchen, sind Datadog oder Dynatrace schwer zu schlagen.
• Multi-Cloud mit 100+ Nodes: Ab einer gewissen Groesse wird der Self-Managed-Betrieb komplex genug, dass ein Managed Service wirtschaftlicher ist.

Fuer die typische Mittelstands-Umgebung (10-50 Nodes, 1-3 Cluster, 2-5 DevOps-Engineers) ist der Open-Source-Stack in den meisten Faellen die bessere Wahl -- wirtschaftlich und technisch.

Fazit: 60% sparen ist realistisch

Die 60% Kostenreduktion ist keine Marketing-Zahl. Sie setzt sich zusammen aus:

• 30-40% durch Wechsel von SaaS auf Self-Managed (oder guenstigeres SaaS)
• 15-20% durch Retention-Optimierung und Downsampling
• 10-15% durch Alert-Reduktion (weniger Personalaufwand fuer Triage)

Der wichtigste Schritt ist der erste: Verstehen Sie, was Sie heute ausgeben und wofuer. Der Rest ergibt sich daraus.

Weiterfuehrende Artikel

• Kubernetes Monitoring mit Prometheus und Grafana: Der Praxis-Guide -- Detaillierte Anleitung fuer den Prometheus-Stack
• Kubernetes Kosten senken: 10 Praxis-Tipps -- Allgemeine Kostenoptimierung ueber Monitoring hinaus
• 24/7 Kubernetes-Betrieb im Mittelstand -- Warum On-Call-Kosten oft unterschaetzt werden
• Kubernetes Compliance automatisieren -- Monitoring als Teil der Compliance-Strategie