Zum Inhalt

SLA-Reports

Wie viel war der Service in einem Zeitraum verfügbar? Wie viel Downtime ist ihm zuzurechnen? Welcher Anteil davon war geplant?

Definition

Verfügbarkeit (in %) = (Gesamt-Sekunden − unverfügbare Sekunden) / Gesamt-Sekunden × 100.

Was zählt als „unverfügbar":

  • Hard-CRITICAL-Phasen
  • Hard-NO_DATA-Phasen (default)
  • Hard-WARNING (default nicht — konfigurierbar)

Was zählt nicht:

  • Geplante Downtimes (default — konfigurierbar mit „streng" auf zählen umstellen)
  • ACK-Phasen (zählen weiterhin als Ausfall — ACK ist nur Notification-Pause, nicht „die Welt war OK")
  • Inhibition-Phasen (zählen für den inhibitierten Service, weil er aus dem Kundenblickwinkel down war — zählen nicht für den Eltern-Host doppelt)

Report erzeugen

/reports/sla → Neuer Report:

Feld Bedeutung
Scope Tenant / Tag / Hosts
Zeitraum letzter Monat / Quartal / Custom
Granularität pro Service / pro Host / pro Tenant
Downtime-Wertung „nicht zählen" (default) / „streng"
WARN als Ausfall? default nein

Output: Tabelle mit Verfügbarkeit pro Zeile + Detail-Aufklappung mit allen Vorfällen.

Beispiel-Output

Tenant Acme — April 2026
─────────────────────────────────────────────────────────────────
Service                       Verfügbar   Geplant   Ungeplant
api.acme.com / HTTP             99.92%    02:14h    00:32h
api.acme.com / TLS-Cert        100.00%    -         -
db01.acme.local / Postgres     100.00%    -         -
sw-core / IF Gi1/0/1            99.45%    -         03:58h
sw-core / IF Gi1/0/2           100.00%    -         -
─────────────────────────────────────────────────────────────────
Tenant gesamt                   99.83%    02:14h    04:30h

Klick auf eine Zeile expandiert eine Detailliste mit Start, Ende, Dauer, Ursache (CRIT-Reason, Downtime-Comment).

Berechnungsmethodik

flowchart LR
    H[check_results-Hypertable] --> AGG[State-Buckets pro Service]
    AGG --> CALC[Sekunden pro Status]
    DT[Downtimes-Tabelle] --> EXCL[Geplante Sekunden ausschließen]
    CALC --> EXCL
    EXCL --> AVAIL[Verfügbarkeit %]

Implementiert als Python-Job (api/app/services/sla.py) mit TimescaleDB-Window-Functions. Performant auch für 90 Tage × 5000 Services (~3 s).

Export

Format Wofür
HTML in Browser Interaktive Sicht
PDF Versand an Kunde — siehe PDF-Reports
CSV Weiterverarbeitung in Excel

Geplante Reports

/reports/scheduled → Neu:

  • monatlicher SLA-Report pro Tenant
  • automatisch am 1. um 06:00 generiert
  • Ergebnis als PDF an konfigurierte E-Mail-Adressen

Empfehlung: pro Tenant einen monatlichen Report → Kunde bekommt automatisch sein Compliance-Dokument.

Mehrere SLA-Klassen

Wenn unterschiedliche Services unterschiedliche SLA-Erwartungen haben („API: 99,9 %, Wiki: 99,0 %"), arbeite mit Tags:

  • Tag sla-tier-99-9 für API-Services
  • Tag sla-tier-99-0 für interne Services

Reports filterst du nach Tag, du kriegst pro Tag-Filter eine eigene Verfügbarkeitssicht.

SLA + Anomaly

Anomaly-Events zählen nicht automatisch als Ausfall — sie sind nur Hinweis. Wenn ein Anomaly zu einem Hard-CRIT führt (nach Eskalation oder manuellen Schritt), zählt das CRIT, nicht das Anomaly.

Permission

Permission Wirkung
sla.view Reports einsehen
sla.export PDF / CSV erzeugen
sla.schedule geplante Reports anlegen

Anschluss