Zum Inhalt

Alert Rules

Eine Alert-Rule ist die Regel, wann und wie eine Notification ausgelöst wird. Standard-Workflow:

  1. Welche Hosts/Services umfasst die Regel? (Filter)
  2. Bei welchem Status / Pattern wird sie aktiv? (Trigger)
  3. Welcher Channel bekommt die Notification? (Channels)
  4. In welcher Reihenfolge / nach welcher Wartezeit? (Eskalation)
  5. Werden mehrere gleichzeitige Alerts gruppiert? (Gruppierung)

Regel anlegen

/alert-rules → Neu.

Filter

Welche Services sind betroffen?

Filter Beispiel
Tenants „nur Acme GmbH"
Hosts bestimmte Hostnames
Tags production, db
Profile „nur APC Smart-UPS"
Check-Type agent_disk, snmp_*
Service-Display-Name (Regex) ^Battery

Wenn alle Filter leer sind, gilt die Regel global.

Trigger

Trigger-Typ Bedeutung
Status feuert bei WARN, CRIT, UNKNOWN, NO_DATA (mehrfach wählbar)
Pattern (Message-Regex) Regex auf check_results.message
Threshold (Wert-Vergleich) value > 80, value < 0.5 etc.
Anomaly wenn der Service eine Anomaly-Detection hat und |z| > sensitivity
Log-Pattern siehe Logs — separater Regel-Typ

Status-Trigger feuert nur bei Hard-States — Soft → Recovery passiert lautlos.

Test-Button

Bevor du speicherst: Test simuliert einen Treffer. Zeigt:

  • Welche Hosts/Services wären betroffen
  • An welche Channels würde gesendet
  • Welcher Eskalations-Pfad käme zum Einsatz

So vermeidest du, dass deine erste Alert-Welle direkt 2000 Hosts trifft.

Seit v0.17.4

Test-Button-Bug behoben — vorher hat er bei Tenant-Filtern still nichts gemacht.

Channels

Pro Regel kannst du beliebig viele Channels zuweisen. Wenn die Regel feuert, gehen alle gleichzeitig raus (oder zeitlich gestaffelt via Eskalation, siehe unten).

Konfiguration der Channels: Notification Channels.

Eskalation

Mehrstufige Strategie für „der Operator sieht es nicht, der Manager soll es sehen, dann das ganze Team".

escalation:
  - after: 0min
    channels: [ops-email]
  - after: 15min
    channels: [ops-push, manager-email]
  - after: 60min
    channels: [oncall-pager, ceo-sms]

Die Stufen werden überprüft, solange der Alert aktiv ist. Wird der Alert acknowledged oder löst sich auf, stoppt die Eskalation.

Gruppierung

Wenn 50 Hosts gleichzeitig down gehen — willst du 50 Mails oder eine Mail mit „50 Hosts kritisch"? Gruppierung macht letzteres möglich.

grouping:
  by: [tenant, profile]   # ein Mail pro (Tenant, Profil)-Kombination
  wait_seconds: 30        # 30 s sammeln, bevor losgeschickt
  group_interval: 300     # innerhalb 5 Min nicht erneut gruppieren

Implementiert im Worker (AlertGrouper). Erste Match → Timer startet, weitere Matches in 30 s werden gesammelt, dann ein gemeinsames Notification-Payload an die Channels.

Pause / Aktiv

Pro Regel enabled Toggle. Pausiert: Regel wird nicht ausgewertet, aber bleibt erhalten. Sinnvoll während Migrationen oder Wartungs-Wellen.

Reihenfolge / Priorität

Regeln haben einen priority-Wert. Bei mehreren matchenden Regeln gewinnt die höchste Priorität — relevant für Mute-Patterns („Wenn diese Regel feuert, alle anderen für den Service ignorieren").

Inhibition (kurz)

Eine Alert-Rule kann angeben, dass ihre Treffer andere Rules unterdrücken:

inhibits:
  - target_filter: { tag: 'critical-infra' }

Praxis: „Wenn der Eltern-Switch CRIT, unterdrücke alle Alerts an dahinter hängenden Hosts." Detaillierter: Dependencies & Inhibition.

Log-Alert-Rules

Spezielle Variante für Logs — Regex-Pattern, Threshold, Absence. Eigene UI unter /alert-rules/log.

Details: Logs → Log-Alert-Regeln.

Recovery-Notifications

Standardmäßig wird auch beim Recovery (Hard → OK) eine Notification verschickt — „Service X ist wieder OK". Pro Channel abschaltbar (siehe Channels).

Audit

Alert-Rule-Änderungen landen im Audit-Log mit Diff. Wer hat den Threshold von 80 auf 50 geändert? Filter target_kind = alert_rule.

Kombinierte Beispiele

Regel 1: Disk-Voll

name: Disk Full Critical
filter:
  check_type: agent_disk
trigger:
  threshold: value >= 95
channels: [ops-email, ops-push]
escalation:
  - after: 0min,    channels: [ops-email]
  - after: 30min,   channels: [ops-push, manager-email]
grouping:
  by: [host]
recovery_notify: true

Regel 2: Cert läuft ab

name: TLS-Cert läuft bald ab
filter:
  check_type: ssl_certificate
trigger:
  status: [WARN, CRIT]
channels: [ops-email]
recovery_notify: false   # sobald Cert verlängert ist, kein Recovery-Spam

Regel 3: Suspicious Auth Pattern

name: Brute-Force-Versuche
type: log_alert
mode: threshold
pattern: 'Failed password for'
window_minutes: 5
threshold: 20
channels: [security-team-email]

Anschluss