TL;DR

Prometheus Recording Rules berechnen häufig genutzte PromQL-Ausdrücke im Voraus und speichern die Ergebnisse als neue Zeitreihen. Damit werden Dashboards schneller, Alerts zuverlässiger und komplexe Queries wiederverwendbar. Dieser Guide zeigt dir die Konfiguration über den Prometheus Operator in Kubernetes mit praktischen Beispielen.

Recording Rules: Schnellere Queries in Kubernetes

Wer Prometheus in Kubernetes betreibt, kennt das Problem: Dashboards laden langsam, weil jedes Panel dieselben aufwendigen Aggregationen berechnet. Recording Rules lösen das, indem sie PromQL-Ausdrücke regelmäßig auswerten und das Ergebnis als neue Metrik speichern.

Ein Grafana-Dashboard mit 20 Panels, die alle rate(container_cpu_usage_seconds_total[5m]) aggregieren, erzeugt 20 identische Queries. Mit einer Recording Rule wird die Berechnung einmal durchgeführt:

groups:
  - name: kubernetes_cpu_rules
    interval: 30s
    rules:
      - record: namespace:container_cpu_usage_seconds:sum_rate
        expr: |
          sum by (namespace) (
            rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])
          )

Wann Recording Rules sinnvoll sind

Nicht jede Query braucht eine Recording Rule. Drei Situationen, in denen sie sich lohnen:

Query-Performance: Aggregationen über tausende Zeitreihen (z.B. alle Container eines Clusters) dauern Sekunden. Eine Recording Rule reduziert das auf einen simplen Lookup.

Dashboard-Ladezeiten: Wenn mehrere Panels dieselbe Berechnung nutzen, spart eine gemeinsame Recording Rule Rechenzeit proportional zur Panel-Anzahl.

Alert-Stabilität: Alerts, die auf komplexen Expressions basieren, können durch Recording Rules robuster werden. Die vorberechnete Metrik steht sofort bereit, statt bei jedem Evaluierungszyklus neu berechnet zu werden.

PrometheusRule-Ressource im Cluster

Der Prometheus Operator bringt die Custom Resource PrometheusRule mit. Darüber definierst du Recording Rules direkt als Kubernetes-Objekt:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-recording-rules
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: cluster_resource_usage
      interval: 30s
      rules:
        - record: cluster:cpu_usage:sum
          expr: |
            sum(
              rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])
            )

        - record: cluster:memory_working_set:sum
          expr: |
            sum(container_memory_working_set_bytes{container!="POD",container!=""})

        - record: namespace:cpu_requests:sum
          expr: |
            sum by (namespace) (
              kube_pod_container_resource_requests{resource="cpu"}
            )

        - record: namespace:memory_requests:sum
          expr: |
            sum by (namespace) (
              kube_pod_container_resource_requests{resource="memory"}
            )

Das Label release: kube-prometheus-stack ist entscheidend — der Prometheus Operator selektiert PrometheusRules anhand von Labels. Ohne das passende Label wird die Rule ignoriert.

Anwenden und prüfen:

kubectl apply -f kubernetes-recording-rules.yaml

# Prüfen ob die Rule geladen wurde
kubectl get prometheusrules -n monitoring

Naming Conventions

Prometheus hat eine klare Konvention für Recording-Rule-Namen. Das Format ist:

level:metric_name:operations

Gute Namen:

• namespace:container_cpu_usage_seconds:sum_rate
• cluster:node_cpu_utilisation:avg
• node:memory_available_bytes:ratio

Schlechte Namen:

• my_custom_cpu_metric (kein Level, keine Operation)
• cpu_total (zu unspezifisch)

Praktische Rule Groups

Hier sind drei Rule Groups, die in den meisten Kubernetes-Clustern nützlich sind.

Namespace-Ressourcen

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: namespace-resource-rules
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: namespace_resources
      interval: 60s
      rules:
        - record: namespace:cpu_utilisation:ratio
          expr: |
            sum by (namespace) (
              rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[5m])
            )
            /
            sum by (namespace) (
              kube_pod_container_resource_requests{resource="cpu"}
            )

        - record: namespace:memory_utilisation:ratio
          expr: |
            sum by (namespace) (
              container_memory_working_set_bytes{container!="POD",container!=""}
            )
            /
            sum by (namespace) (
              kube_pod_container_resource_requests{resource="memory"}
            )

        - record: namespace:pod_count:count
          expr: |
            count by (namespace) (kube_pod_info)

Node-Metriken

        - record: node:cpu_utilisation:avg1m
          expr: |
            1 - avg by (node) (
              rate(node_cpu_seconds_total{mode="idle"}[1m])
            )

        - record: node:memory_utilisation:ratio
          expr: |
            1 - (
              node_memory_MemAvailable_bytes
              / node_memory_MemTotal_bytes
            )

Interval richtig wählen

Das interval-Feld bestimmt, wie oft die Rule ausgewertet wird. Zu niedrig belastet Prometheus, zu hoch liefert veraltete Daten.

Für die meisten Recording Rules sind 30 bis 60 Sekunden ein guter Kompromiss. Prometheus selbst evaluiert Alerts standardmäßig alle 15 Sekunden — deine Recording Rules sollten mindestens genauso häufig aktualisieren, wenn Alerts darauf basieren.

Debugging und Validierung

Nach dem Deployment prüfst du, ob die Rules aktiv sind:

# PrometheusRule-Status im Cluster
kubectl get prometheusrules -n monitoring -o wide

# Prometheus-UI: Rules-Seite aufrufen
kubectl port-forward svc/kube-prometheus-stack-prometheus -n monitoring 9090:9090
# Browser: http://localhost:9090/rules

# Direkt die neue Metrik abfragen
curl -s 'http://localhost:9090/api/v1/query?query=cluster:cpu_usage:sum' | jq .

Wenn eine Rule nicht auftaucht, prüfe die Labels der PrometheusRule-Ressource. Der Prometheus Operator loggt Probleme:

kubectl logs -l app.kubernetes.io/name=prometheus-operator -n monitoring --tail=50

FAQ

Wie viele Recording Rules sind zu viele?

Es gibt keine feste Grenze, aber jede Rule erzeugt eine neue Zeitreihe. Bei 100 Rules mit je 50 Label-Kombinationen entstehen 5.000 zusätzliche Zeitreihen. Überwache prometheus_tsdb_head_series um den Overhead im Blick zu behalten.

Kann ich Recording Rules für Alerts verwenden?

Ja, und das ist sogar empfohlen. Alerting Rules können auf Recording Rules referenzieren. Das macht Alert-Expressions kürzer und die Evaluation schneller.

Was passiert bei einem Prometheus-Neustart?

Recording Rules werden nach dem Neustart sofort wieder evaluiert. Es entsteht eine kurze Lücke in den vorberechneten Zeitreihen, die dem Evaluierungsintervall entspricht. Historische Daten bleiben über den TSDB erhalten.

Wie unterscheiden sich Recording Rules von Alerting Rules?

Recording Rules speichern das Ergebnis als neue Metrik. Alerting Rules lösen eine Benachrichtigung aus, wenn eine Bedingung erfüllt ist. Beide nutzen PromQL, aber der Zweck ist grundverschieden.

Nächster Schritt: Nutze deine Recording Rules als Grundlage für ServiceMonitor und PodMonitor, um auch Custom-App-Metriken effizient zu erfassen.