Observability-Dashboards mit Claude konfigurieren: PromQL, Panels und Alert-Schwellenwerte

1. Warum Dashboards und Alerts so oft hinterherhinken

Observability-Setups wachsen in den meisten Teams organisch mit den Services mit. Ein neuer Endpunkt bekommt eine Handvoll Metriken, jemand baut schnell ein Panel dazu, und Monate später kann niemand mehr erklären, warum der Latenz-Alert ausgerechnet bei 800 Millisekunden auslöst. Das Werkzeug ist selten das Problem, Grafana und Prometheus sind ausgereift und gut dokumentiert, sondern die fehlende Zeit, Dashboards und Schwellenwerte sauber durchzudenken, bevor der nächste Sprint beginnt und die nächste Baustelle ruft.

Genau hier lohnt sich der produktive Einsatz von Claude als schneller Sparringspartner. Er liefert Panel-Entwürfe, prüft bestehende PromQL-Ausdrücke auf typische Fehler und schlägt Schwellenwerte basierend auf mitgelieferten historischen Werten vor. Die eigentliche Entscheidung, welche Signale für einen konkreten Service wirklich relevant sind, bleibt weiterhin beim Team, aber der Weg dorthin wird deutlich kürzer, weil das mühsame erste Grundgerüst nicht mehr von Hand getippt werden muss.

2. Grafana-Dashboard-JSON aus einer Beschreibung generieren lassen

Der naheliegendste Einstieg ist, Claude eine textuelle Beschreibung der gewünschten Panels zu geben und daraus valides Dashboard-JSON erzeugen zu lassen, das sich direkt per Provisioning oder manuellem Import in Grafana laden lässt. Entscheidend ist dabei, ausreichend Kontext mitzuliefern: welche Datenquelle verwendet wird, wie die Metriken tatsächlich heißen und welche Grafana-Schema-Version im Einsatz ist, damit die generierten Panels ohne Nacharbeit funktionieren und keine veralteten Feldnamen enthalten.

In der Praxis funktioniert das am besten iterativ. Zuerst lässt man ein Grundgerüst mit den wichtigsten Panels generieren, importiert das JSON lokal in eine Test-Instanz und gibt danach konkretes Feedback zu einzelnen Panels, etwa dass die Einheit falsch ist oder eine Legende fehlt. Claude passt dann gezielt genau diesen Teil des JSON an, ohne den Rest des Dashboards zu verändern, was gerade bei größeren Dashboards mit vielen Reihen deutlich schneller geht als eine komplette Neugenerierung.

{
  "title": "Checkout-Service Überblick",
  "panels": [
    {
      "type": "timeseries",
      "title": "Request-Latenz p95",
      "targets": [
        {
          "expr": "histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service=\"checkout\"}[5m])) by (le))",
          "legendFormat": "p95 Latenz"
        }
      ],
      "fieldConfig": {
        "defaults": { "unit": "s" }
      }
    }
  ]
}

3. PromQL-Queries von Claude prüfen und verbessern lassen

Ein zweiter, oft unterschätzter Einsatzbereich ist das reine Query-Review. Viele PromQL-Ausdrücke, die man in gewachsenen Dashboards findet, verwenden rate() mit einem viel zu kurzen Zeitfenster, vergessen die Aggregation über Labels mit by (le) vor histogram_quantile() oder mischen Counter- und Gauge-Metriken in derselben Formel, was zu irreführenden Kurven führt. Claude erkennt solche Muster zuverlässig, wenn man die vorhandenen Queries einfach einfügt und um eine kurze Erklärung der Metrik-Typen bittet.

Besonders wertvoll ist das bei Übernahme fremder Dashboards, etwa nach einem Teamwechsel oder bei der Migration eines Community-Dashboards aus dem Grafana-Marktplatz. Statt jede Query mühsam manuell nachzuvollziehen, lässt man Claude eine Liste von Auffälligkeiten erstellen, priorisiert nach Wahrscheinlichkeit eines echten Fehlers, und arbeitet diese Liste gezielt ab, statt blind zu vertrauen, dass ein importiertes Dashboard schon richtig sein wird.

# Vorher: falsches Zeitfenster, keine Aggregation nach le
rate(http_request_duration_seconds_bucket[30s])

# Nachher, nach Claude-Review: korrektes Fenster
# und korrekte Aggregation vor histogram_quantile
histogram_quantile(
  0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)
)

4. Sinnvolle Alert-Schwellenwerte durchdenken statt raten

Statische Schwellenwerte wie ein fester Wert von 500 Millisekunden für die Latenz sind fast immer ein Kompromiss aus Bauchgefühl und Zeitdruck. Sinnvoller ist es, Claude die tatsächliche Verteilung der letzten Wochen zu geben, etwa als exportierte CSV-Datei mit stündlichen Perzentilwerten, und daraus einen Schwellenwert ableiten zu lassen, der sich am realen Normalzustand orientiert statt an einer runden Zahl. Ein Latenz-Alert, der beim 99. Perzentil der letzten dreißig Tage plus einem Sicherheitsaufschlag ansetzt, löst deutlich seltener grundlos aus als ein geratener Fixwert.

Ebenso hilfreich ist es, Claude explizit nach dem Trade-off zwischen Sensitivität und Reaktionszeit fragen zu lassen. Ein zu enger Schwellenwert erzeugt ständig Fehlalarme bei normalen Lastspitzen, ein zu weiter Schwellenwert lässt echte Probleme lange unbemerkt. Claude kann für unterschiedliche Metrik-Typen konkrete Vorschläge liefern, etwa Perzentil-basierte Schwellenwerte für Latenz und trendbasierte Vorhersagen für Ressourcenverbrauch, statt überall dieselbe starre Prozentregel anzuwenden.

groups:
  - name: checkout-latency
    rules:
      - alert: CheckoutLatencyHigh
        expr: |
          histogram_quantile(0.95,
            sum(rate(http_request_duration_seconds_bucket{service="checkout"}[5m])) by (le)
          ) > 0.9
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Checkout p95-Latenz über historischem Normalwert"

5. Alert-Fatigue vermeiden: weniger, aber relevantere Alerts

Alert-Fatigue entsteht, wenn ein Team über Wochen mit Alarmen bombardiert wird, von denen die meisten harmlos sind, bis irgendwann auch der echte Vorfall im Rauschen untergeht und niemand mehr sofort reagiert. Ein bewährter Schritt ist, Claude die komplette Liste aller aktiven Alert-Regeln vorzulegen und nach Auffälligkeiten fragen zu lassen: doppelte Alerts, die dieselbe Ursache beschreiben, Alerts ohne klare Handlungsanweisung in der Annotation oder Regeln, die seit Monaten nie ausgelöst haben und vermutlich falsch konfiguriert sind.

Aus dieser Analyse lässt sich meist eine konkrete Konsolidierungsliste ableiten, etwa mehrere separate Fehlerquoten-Alerts pro Endpunkt zu einem einzigen, nach Service gruppierten Alert mit Label-basierter Aufschlüsselung zusammenzufassen. Wichtig ist, jede Konsolidierung im Team gegenzuprüfen, denn Claude kennt die organisatorischen Gründe für manche scheinbar redundante Regel nicht automatisch, etwa wenn zwei Teams bewusst getrennte Alerts für denselben Service benötigen, weil sie unterschiedliche Verantwortungsbereiche haben.

6. Multi-Window-Multi-Burn-Rate-Alerts mit Claude entwerfen

Ein Muster aus dem Google-SRE-Workbook, das in vielen Teams noch ungenutzt bleibt, sind Multi-Window-Multi-Burn-Rate-Alerts für SLO-Fehlerbudgets. Statt eines einzelnen starren Schwellenwerts kombiniert man ein kurzes und ein langes Zeitfenster: Nur wenn beide Fenster gleichzeitig eine erhöhte Burn-Rate zeigen, löst der Alert wirklich aus. Das reduziert Fehlalarme durch kurze Ausreißer drastisch, ohne die Reaktionszeit bei echten, anhaltenden Problemen zu verschlechtern.

Die Formeln dafür sind nicht komplex, aber fehleranfällig beim ersten Selbstschreiben, insbesondere die korrekte Berechnung der Burn-Rate aus dem Fehlerbudget und der SLO-Zielgröße. Claude eignet sich gut, um aus einer gegebenen SLO-Definition, etwa 99,9 Prozent Erfolgsquote über 30 Tage, direkt die passenden Prometheus-Regeln für mehrere Fenster und Schweregrade abzuleiten, inklusive der üblichen Kombination aus einem 5-Minuten- und einem 1-Stunden-Fenster für kritische Alerts sowie einem 6-Stunden- und 3-Tage-Fenster für weniger dringende Warnungen.

- alert: ErrorBudgetBurnRateCritical
  expr: |
    (
      sum(rate(http_requests_total{status=~"5..",service="checkout"}[5m]))
      /
      sum(rate(http_requests_total{service="checkout"}[5m]))
    ) > (14.4 * 0.001)
    and
    (
      sum(rate(http_requests_total{status=~"5..",service="checkout"}[1h]))
      /
      sum(rate(http_requests_total{service="checkout"}[1h]))
    ) > (14.4 * 0.001)
  labels:
    severity: critical

7. Dashboard-Varianten für unterschiedliche Zielgruppen ableiten

Ein technisch tiefes SRE-Dashboard mit zwanzig Panels ist für eine Führungskraft, die einmal täglich einen kurzen Blick auf die Systemgesundheit werfen möchte, wenig hilfreich. Statt ein zweites Dashboard komplett von Hand nachzubauen, lässt sich Claude bitten, aus dem bestehenden, detaillierten Dashboard-JSON eine reduzierte Variante mit nur den vier oder fünf aussagekräftigsten Panels abzuleiten, ergänzt um verständlichere Titel ohne interne Fachbegriffe.

Dasselbe Prinzip funktioniert auch umgekehrt: aus einem einfachen Überblicksdashboard eine detailliertere Debugging-Variante für den nächsten Incident ableiten, mit zusätzlichen Panels für einzelne Instanzen, Datenbankverbindungspools oder Warteschlangenlängen. Weil die Grundstruktur des JSON dabei erhalten bleibt, lassen sich beide Varianten parallel pflegen, ohne dass Änderungen an der einen Version manuell in die andere übertragen werden müssen.

8. Claude Code direkt im Grafana-Provisioning-Repository einsetzen

Teams, die Dashboards und Alerts als Code in einem Git-Repository mit Grafana-Provisioning verwalten, profitieren davon, Claude Code direkt in diesem Repository arbeiten zu lassen, statt JSON-Schnipsel manuell zwischen einem Chat-Fenster und der Codebasis hin und her zu kopieren. Claude Code sieht dann die bereits vorhandenen Dashboards, kann den etablierten Stil übernehmen und neue Panels konsistent zu den bestehenden benennen, statt bei jedem neuen Dashboard wieder bei null anzufangen.

Der Workflow bleibt dabei bewusst überprüfbar: Claude Code ändert die Dateien im Arbeitsverzeichnis, das Team sieht den vollständigen Diff über das übliche Versionskontrollsystem, bevor irgendetwas committet oder gar in die produktive Grafana-Instanz deployt wird. Gerade bei Alert-Regeln, deren Fehlkonfiguration im schlimmsten Fall dazu führt, dass niemand mehr benachrichtigt wird, ist dieser Zwischenschritt der Code-Review nicht verhandelbar.

cd observability-as-code
claude "Aktualisiere alerts/checkout.yaml: füge eine
Multi-Window-Burn-Rate-Regel für das 99,9-Prozent-SLO hinzu,
im gleichen Stil wie alerts/payment.yaml"

git diff alerts/checkout.yaml
# Review, dann committen
git add alerts/checkout.yaml
git commit -m "Burn-Rate-Alert für Checkout-SLO ergänzen"

9. Grenzen: Claude kennt euer System nicht automatisch

Claude kennt weder die tatsächlichen Metrik-Namen eures Systems noch die reale Verteilung eurer Latenzwerte, solange diese Informationen nicht explizit mitgegeben werden. Ohne konkreten Kontext generiert das Modell plausibel aussehende, aber möglicherweise falsche Metrik-Bezeichnungen oder Schwellenwerte, die an keiner realen Beobachtung hängen. Jede generierte Query und jeder vorgeschlagene Schwellenwert muss deshalb gegen echte Daten geprüft werden, bevor er produktiv scharf geschaltet wird.

Bewährt hat sich ein gestufter Rollout: neue Alert-Regeln zunächst im reinen Beobachtungsmodus ohne Benachrichtigung laufen lassen, eine Woche lang das Auslöseverhalten gegen echte Betriebsdaten beobachten und erst danach die tatsächliche Alarmierung aktivieren. Claude liefert den fachlich fundierten Startpunkt und beschleunigt die Erstellung erheblich, die Verantwortung für die tatsächliche Freigabe und die endgültige Kalibrierung bleibt aber beim Team, das die Konsequenzen eines Fehlalarms oder eines verpassten echten Vorfalls trägt.

10. Zusammenfassung

11. FAQ: Observability-Dashboards mit Claude: Häufige Fragen