Automatische Incident-Erkennung
LIVCK Cloud überwacht deine Services rund um die Uhr von mehreren verteilten Standorten. Fällt ein Service aus, erkennt LIVCK das automatisch und erstellt einen Incident.
So funktioniert die Erkennung
Ein Incident wird nicht beim ersten Fehler erstellt. LIVCK verlangt zwei Dinge, bevor ein Vorfall entsteht:
- Mehrheit der Standorte: Der Fehler muss von der Mehrheit deiner Prüf-Standorte gemeldet werden -- gemessen über verschiedene Netzwerke (Standorte in unterschiedlichen Rechenzentren/Providern). Mehrere Standorte im selben Netz zählen dabei als eine einzige Stimme, damit ein einzelner Netzausfall keine falsche Mehrheit vortäuscht. Zusätzlich muss eine Mindestzahl an Standorten frische Ergebnisse liefern (Quorum), sonst gilt die Lage als "unklar" und es entsteht kein Incident.
- Bestätigungszähler: Der Ausfall muss über mehrere aufeinanderfolgende Prüfrunden bestehen bleiben (Standard: 3). Ein einzelner fehlgeschlagener Check reicht also nicht -- der Fehler muss sich Runde für Runde bestätigen.
Das schützt vor Fehlalarmen, etwa bei einem kurzzeitigen Netzwerkproblem an einem einzelnen Standort.
Mehrheits-Regel
Bei drei konfigurierten Standorten (in drei verschiedenen Netzen) müssen mindestens zwei den Fehler melden, bevor ein Incident entsteht. So werden vereinzelte Verbindungsprobleme herausgefiltert.
Ablauf:
- Ein oder mehrere Standorte erkennen, dass dein Service nicht erreichbar ist
- LIVCK wartet, bis die Mehrheit der Netzwerke den Fehler bestätigt und der Bestätigungszähler die konfigurierte Anzahl an Prüfrunden erreicht
- Ist beides erfüllt, wird automatisch ein Incident mit passendem Schweregrad erstellt
- Dein Team wird über die konfigurierten Kanäle benachrichtigt
Automatische Incidents erkennen
Automatisch erstellte Incidents tragen in der Liste das Tag "Automatisch".
| Merkmal | Automatischer Incident | Manueller Incident |
|---|---|---|
| Erstellt durch | LIVCK Erkennung | Teammitglied |
| Kennzeichnung | Tag "Automatisch" | Kein Tag |
| Betroffene Services | Automatisch zugewiesen | Manuell gewählt |
| Bearbeitbar | Ja, vollständig | Ja, vollständig |
Automatische Auflösung
Ist dein Service wieder erreichbar, wird der Incident automatisch aufgelöst -- aber erst, wenn die Erholung genauso bestätigt ist wie zuvor der Ausfall: Die Mehrheit der Standorte muss über mehrere aufeinanderfolgende UP-Runden (Standard: 2) eine erfolgreiche Prüfung melden. Ein einzelner geglückter Check löst den Incident also nicht sofort auf.
Reopen-Schonfrist
Direkt nach der Auflösung gilt eine kurze Schonfrist: Fällt der Service in diesem Zeitfenster erneut aus, wird das dem gerade aufgelösten Vorfall zugeordnet, statt sofort einen komplett neuen Incident anzulegen. So vermeidest du eine Flut einzelner Incidents bei einem "wackelnden" Service.
Manuelle Kontrolle bleibt erhalten
Auch bei automatischen Incidents kannst du jederzeit Status-Updates posten, den Schweregrad ändern oder manuell auflösen. Die Erkennung unterstützt dich -- sie ersetzt nicht deine Kontrolle.
Automatische Incidents bearbeiten
Genau wie manuelle Incidents:
- Status-Updates posten
- Schweregrad anpassen
- Betroffene Services hinzufügen oder entfernen
- Auf der Statuspage veröffentlichen oder verbergen
Zusammenspiel mit Eskalationsrichtlinien
Automatische Incidents lösen die Eskalationsrichtlinie des betroffenen Services aus:
- Incident wird automatisch erkannt und erstellt
- Die zugewiesene Eskalationsrichtlinie startet sofort
- Dein Team wird Schritt für Schritt benachrichtigt
- Ein Teammitglied kann die Eskalation bestätigen und übernehmen
Empfehlung
Kombiniere die automatische Erkennung mit einer Eskalationsrichtlinie. So wird dein Team sofort benachrichtigt -- auch nachts oder am Wochenende.
Schweregrad bei automatischen Incidents
Der Schweregrad richtet sich danach, wie viele Standorte deinen Service als nicht erreichbar melden. Je größer der Anteil der ausgefallenen Standorte, desto höher der Schweregrad:
| Anteil ausgefallener Standorte | Incident-Schweregrad |
|---|---|
| Unter 50 % | Gering (Minor) |
| 50 % bis 75 % | Erheblich (Major) |
| 75 % oder mehr | Kritisch (Critical) |
Die Prozent-Schwellen (Standard: 50 % und 75 %) lassen sich über die Incident-Richtlinien anpassen.
Nur eingeschränkter Service bleibt "Gering"
Ist dein Service lediglich eingeschränkt (degraded), aber an keinem Standort komplett nicht erreichbar, wird der Incident höchstens als Gering eingestuft -- unabhängig davon, wie viele Standorte die Einschränkung melden.
Du kannst den Schweregrad jederzeit manuell anpassen.
Wartungen unterdrücken automatische Incidents
Während einer aktiven Wartung werden für die betroffenen Services keine automatischen Incidents erstellt (Maintenance-Blackout). So löst eine geplante, angekündigte Downtime keine unnötigen Vorfälle und Alarme aus. Sobald die Wartung abgeschlossen ist, greift die automatische Erkennung wieder wie gewohnt. Mehr dazu unter Wartungs-Benachrichtigungen.
Häufige Fragen
Kann ich die automatische Erkennung deaktivieren? Nein, einen Ein/Aus-Schalter gibt es nicht -- die automatische Erkennung läuft für jeden überwachten Service dauerhaft mit. Sie greift lediglich dann nicht, wenn du den Service pausierst oder es sich um einen manuellen Service handelt (der von keinem Standort geprüft wird). Über die Incident-Richtlinien steuerst du nicht ob, sondern wie empfindlich erkannt wird (z.B. Anzahl der Bestätigungsrunden und Schwellen).
Werden automatische Incidents auf meiner Statuspage angezeigt? Das hängt von deinen Einstellungen ab -- du kannst festlegen, ob sie direkt veröffentlicht oder zunächst als Entwurf erstellt werden.
Was passiert bei einem kurzen Ausfall von wenigen Sekunden? Durch Mehrheits-Regel und Bestätigungsverfahren werden sehr kurze Aussetzer in der Regel nicht als Incident gemeldet.
Weiterführende Themen
- Incidents verstehen -- Grundlagen zu Incidents und Schweregraden
- Eskalationsrichtlinien -- Automatische Benachrichtigungen konfigurieren
- Monitoring-Standorte -- Mehr zu den verschiedenen Prüf-Standorten
- Incident-Richtlinien -- Erkennungseinstellungen anpassen