TL;DR

Gute Kubernetes-Dashboards folgen der USE-Methode (Utilization, Saturation, Errors) für Infrastruktur und der RED-Methode (Rate, Errors, Duration) für Services. Mit ConfigMap-Provisioning verwaltest du Dashboards als Code direkt im Cluster. Dieser Guide zeigt dir die wichtigsten Panels und wie du sie automatisiert ausrollst.

Grafana Dashboards für Kubernetes richtig bauen

Die meisten Grafana-Dashboards in Kubernetes-Clustern sind Müll. Zu viele Panels, keine klare Struktur, und niemand schaut drauf, bis es brennt. Das Problem ist selten Grafana selbst — es fehlt eine Methodik.

Dieser Guide zeigt dir, wie du Dashboards baust, die im Incident tatsächlich helfen.

USE-Methode: Infrastruktur überwachen

Brendan Gregg hat die USE-Methode entwickelt: Utilization, Saturation, Errors. Für jede Ressource (CPU, Memory, Disk, Network) stellst du drei Fragen:

# Utilization: Wie stark wird die Ressource genutzt?
sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod)
/
sum(kube_pod_container_resource_requests{resource="cpu", namespace="production"}) by (pod)

# Saturation: Wird die Ressource gedrosselt?
sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="production"}[5m])) by (pod)

# Errors: Gibt es Fehler?
sum(rate(node_disk_io_time_weighted_seconds_total[5m])) by (instance)

Das ergibt pro Ressource genau drei Panels. Für einen Node-Overview brauchst du also 12 Panels — nicht 47.

Die wichtigsten USE-Panels

RED-Methode: Services überwachen

Für Microservices nutzt du die RED-Methode von Tom Wilkie: Rate, Errors, Duration.

# Rate: Requests pro Sekunde
sum(rate(http_requests_total{namespace="production"}[5m])) by (service)

# Errors: Fehlerrate in Prozent
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service) * 100

# Duration: P99-Latenz
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{namespace="production"}[5m])) by (le, service)
)

Pro Service drei Panels. Ein Dashboard für zehn Services hat 30 Panels — mit Template-Variablen sogar nur drei.

Dashboard-Struktur: Weniger ist mehr

Ein bewährtes Layout für ein Cluster-Overview:

Row 1 — Cluster Health: Node-Status, Pod-Status, Pending Pods Row 2 — CPU: Cluster-Utilization, Top-5-Pods, Throttling Row 3 — Memory: Cluster-Utilization, Top-5-Pods, OOMKilled Row 4 — Network: Ingress Traffic, Error Rate, Latenz

Nutze Grafana-Variablen für Namespace und Timerange. Damit filterst du ein Dashboard auf verschiedene Teams, ohne Duplikate zu pflegen.

Dashboard-as-Code mit ConfigMaps

Manuell erstellte Dashboards gehen verloren. Besser: Dashboards als JSON in ConfigMaps speichern und über den Grafana-Sidecar automatisch laden.

apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboard-cluster-overview
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
data:
  cluster-overview.json: |
    {
      "dashboard": {
        "title": "Cluster Overview",
        "uid": "cluster-overview-v1",
        "timezone": "browser",
        "refresh": "30s",
        "panels": [
          {
            "title": "CPU Utilization by Node",
            "type": "timeseries",
            "gridPos": { "h": 8, "w": 12, "x": 0, "y": 0 },
            "targets": [
              {
                "expr": "1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) by (instance)",
                "legendFormat": "{{ instance }}"
              }
            ],
            "fieldConfig": {
              "defaults": {
                "unit": "percentunit",
                "thresholds": {
                  "steps": [
                    { "color": "green", "value": null },
                    { "color": "yellow", "value": 0.7 },
                    { "color": "red", "value": 0.9 }
                  ]
                }
              }
            }
          },
          {
            "title": "Memory Usage by Node",
            "type": "timeseries",
            "gridPos": { "h": 8, "w": 12, "x": 12, "y": 0 },
            "targets": [
              {
                "expr": "1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)",
                "legendFormat": "{{ instance }}"
              }
            ],
            "fieldConfig": {
              "defaults": {
                "unit": "percentunit"
              }
            }
          }
        ],
        "templating": {
          "list": [
            {
              "name": "namespace",
              "type": "query",
              "query": "label_values(kube_pod_info, namespace)"
            }
          ]
        }
      }
    }

Der Grafana-Sidecar (Teil des kube-prometheus-stack Helm Charts) erkennt ConfigMaps mit dem Label grafana_dashboard: "1" und lädt sie automatisch.

Alerting-Integration

Dashboards ohne Alerts sind nur Dekoration. Definiere Alerts direkt in Grafana oder besser in Prometheus-Rules:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-resource-alerts
  namespace: monitoring
spec:
  groups:
    - name: kubernetes.resources
      rules:
        - alert: HighCPUThrottling
          expr: |
            sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod, namespace)
            / sum(rate(container_cpu_usage_seconds_total[5m])) by (pod, namespace)
            > 0.25
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.pod }} wird stark gedrosselt"

Anti-Patterns vermeiden

Zu viele Dashboards: Fünf gute Dashboards schlagen 50 mittelmäßige. Starte mit: Cluster Overview, Namespace Overview, Pod Detail, Ingress/Service.

Fehlende Thresholds: Panels ohne farbliche Schwellenwerte sind schwer zu lesen. Nutze Grün/Gelb/Rot konsequent.

Statische Queries: Hardcodierte Namespace-Filter erzeugen Dashboard-Wildwuchs. Nutze Template-Variablen.

Kein Versionskontrolle: Dashboard-JSON gehört ins Git-Repository, nicht nur in die Grafana-Datenbank.

FAQ

Welche Dashboards brauche ich mindestens?

Vier: Cluster Overview (Nodes, globale Metriken), Namespace Overview (Ressourcen pro Team), Pod Detail (einzelne Workloads debuggen), Ingress/Network (Traffic und Latenzen).

USE oder RED — wann nutze ich was?

USE für Infrastruktur-Ressourcen (CPU, Memory, Disk, Network auf Node-Ebene). RED für Services und Applikationen (HTTP-Endpoints, gRPC-Services). Beides ergänzt sich.

Wie versioniere ich Grafana Dashboards?

Exportiere das Dashboard-JSON über die Grafana-API oder UI, speichere es als ConfigMap im Git-Repo. Der Grafana-Sidecar im kube-prometheus-stack lädt ConfigMaps mit dem Label grafana_dashboard: "1" automatisch.

Was ist der Grafana-Sidecar?

Ein Container im Grafana-Pod, der ConfigMaps im Cluster überwacht. Neue oder geänderte ConfigMaps mit dem richtigen Label werden automatisch als Dashboard importiert — ohne Grafana-Neustart.

Wie oft sollte das Dashboard refreshen?

Für Echtzeit-Debugging: 10-30 Sekunden. Für Team-Overviews: 1-5 Minuten. Zu häufiges Refreshing belastet Prometheus unnötig.