Prometheus Stack: Kubernetes-Monitoring einrichten

TL;DR

Der kube-prometheus-stack liefert Prometheus, Grafana und Alertmanager als Komplettpaket per Helm. ServiceMonitor-CRDs machen manuelle Scrape-Configs überflüssig, PrometheusRule-Objekte definieren Alerts deklarativ. Für die meisten Cluster reichen 50 Gi Storage und 30 Tage Retention. Dieser Guide zeigt Installation, Custom-Monitoring und Alerting Schritt für Schritt.

Installation per Helm

Der schnellste Weg zum produktionsreifen Monitoring-Stack:

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 \
  --create-namespace \
  -f values-monitoring.yaml

Die wichtigsten Helm-Values gehören in eine eigene Datei:

# values-monitoring.yaml
prometheus:
  prometheusSpec:
    retention: 30d
    retentionSize: "45GB"
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: gp3
          resources:
            requests:
              storage: 50Gi
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        memory: 4Gi
    serviceMonitorSelectorNilUsesHelmValues: false
    ruleSelectorNilUsesHelmValues: false

grafana:
  persistence:
    enabled: true
    size: 10Gi
  adminPassword: "CHANGE-ME"

alertmanager:
  alertmanagerSpec:
    resources:
      requests:
        cpu: 100m
        memory: 128Mi

Zwei Einstellungen sind entscheidend: serviceMonitorSelectorNilUsesHelmValues: false sorgt dafür, dass Prometheus alle ServiceMonitor-Objekte im Cluster erkennt -- nicht nur die mit dem Helm-Release-Label. Gleiches gilt für ruleSelectorNilUsesHelmValues.

Nach der Installation prüfen:

kubectl -n monitoring get pods
kubectl -n monitoring get svc

Grafana erreicht ihr per Port-Forward:

kubectl -n monitoring port-forward svc/monitoring-grafana 3000:80

Was der Stack mitbringt

Der kube-prometheus-stack installiert über 100 vorkonfigurierte Alert-Regeln und rund 30 Grafana-Dashboards. Die wichtigsten:

Dazu kommen kube-state-metrics (Kubernetes-Objekte als Metriken) und der node-exporter als DaemonSet auf jedem Node.

ServiceMonitor: Eigene Apps überwachen

Eure Anwendung exponiert Metriken auf /metrics? Dann braucht ihr einen ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: order-service
  namespace: production
spec:
  selector:
    matchLabels:
      app: order-service
  endpoints:
    - port: http-metrics
      interval: 30s
      path: /metrics
      scrapeTimeout: 10s
  namespaceSelector:
    matchNames:
      - production

Prometheus erkennt den ServiceMonitor automatisch und beginnt mit dem Scraping. Kein Neustart nötig, keine ConfigMap-Änderung.

Ob der Target erkannt wird, prüft ihr unter Prometheus -> Status -> Targets:

kubectl -n monitoring port-forward svc/monitoring-kube-prometheus-prometheus 9090:9090
# Browser: http://localhost:9090/targets

Falls der Target nicht auftaucht: Prüft, ob der Service einen Port mit dem Namen http-metrics hat und ob der Namespace-Selector stimmt.

PrometheusRule: Alerts deklarativ definieren

Alerts werden als PrometheusRule-Objekte im Cluster hinterlegt. Prometheus lädt sie automatisch.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
  namespace: monitoring
spec:
  groups:
    - name: order-service
      rules:
        - alert: OrderServiceHighErrorRate
          expr: |
            sum(rate(http_requests_total{service="order-service", code=~"5.."}[5m]))
            /
            sum(rate(http_requests_total{service="order-service"}[5m]))
            > 0.05
          for: 5m
          labels:
            severity: critical
            team: commerce
          annotations:
            summary: "Order-Service Fehlerrate über 5%"
            description: "Aktuelle Rate: {{ $value | humanizePercentage }}"

        - alert: OrderServiceHighLatency
          expr: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{service="order-service"}[5m])) by (le)
            ) > 2
          for: 10m
          labels:
            severity: warning
            team: commerce
          annotations:
            summary: "Order-Service P99-Latenz über 2 Sekunden"

Das for-Feld verhindert, dass kurze Spikes sofort Alerts auslösen. 5 Minuten für kritische und 10 Minuten für Warnungen sind ein guter Startpunkt.

Retention und Storage richtig dimensionieren

Die Retention bestimmt, wie lange Prometheus Metriken vorhält. Mehr Retention bedeutet mehr Speicher.

Faustregeln:

• 15 Tage: Reicht für Echtzeit-Monitoring und kurzfristiges Debugging
• 30 Tage: Standard für die meisten Teams, genug für Monatsvergleiche
• 90+ Tage: Nutzt besser Thanos oder Grafana Mimir für Long-Term-Storage

Speicherbedarf abschätzen:

# Aktuelle Ingestion-Rate prüfen
kubectl -n monitoring port-forward svc/monitoring-kube-prometheus-prometheus 9090:9090 &

curl -s 'http://localhost:9090/api/v1/query?query=prometheus_tsdb_head_series' | \
  python3 -c "import json,sys; d=json.load(sys.stdin); print(f'Aktive Serien: {int(d[\"data\"][\"result\"][0][\"value\"][1]):,}')"

Wenn der Speicher knapp wird: Hochkardinalitäre Metriken identifizieren und per metric_relabel_configs im ServiceMonitor filtern.

# Labels mit hoher Kardinalität droppen
endpoints:
  - port: http-metrics
    metricRelabelings:
      - sourceLabels: [__name__]
        regex: "go_gc_.*"
        action: drop
      - sourceLabels: [request_id]
        action: labeldrop

Häufige Fehler vermeiden

Alertmanager nicht konfiguriert: Der Stack installiert Alertmanager, aber ohne Receiver (Slack, PagerDuty, E-Mail) landen Alerts im Nirgendwo. Konfiguriert mindestens einen Receiver direkt bei der Installation.

Zu viele Alerts: 200 Alert-Regeln klingen gut, führen aber zu Alert Fatigue. Startet mit 10–15 kritischen Regeln und erweitert schrittweise.

Kein Persistent Volume: Ohne PV gehen bei einem Pod-Restart alle Metriken verloren. Prometheus und Grafana brauchen zwingend persistenten Speicher.

ServiceMonitor-Labels falsch: Der häufigste Grund, warum Targets nicht auftauchen. Der ServiceMonitor muss zum Service-Label passen, nicht zum Deployment.

FAQ

Wie viel kostet der kube-prometheus-stack an Cluster-Ressourcen?

Für einen Cluster mit 10 Nodes rechnet mit ca. 3 Gi RAM und 2 CPU-Cores für den gesamten Stack (Prometheus, Grafana, Alertmanager, kube-state-metrics, node-exporter). Der größte Posten ist Prometheus selbst.

Kann ich mehrere Prometheus-Instanzen betreiben?

Ja, per Prometheus-Operator könnt ihr mehrere Prometheus-CRs deployen -- z.B. eine für Infrastructure-Metriken und eine für Application-Metriken. Das reduziert die Last pro Instanz.

Wie sichere ich Grafana-Dashboards?

Dashboards als JSON in Git versionieren und per ConfigMap mit dem Label grafana_dashboard: "1" deployen. Der Grafana-Sidecar importiert sie automatisch. Manuelle Änderungen im UI gehen beim Neustart verloren.

Brauche ich Thanos oder Mimir?

Nur wenn ihr Multi-Cluster-Monitoring oder Retention über 90 Tage braucht. Für einzelne Cluster mit 30 Tagen Retention ist der kube-prometheus-stack allein ausreichend.