Ereignisse & Benachrichtigungen
Neben den laufenden Messwerten meldet der Agent Ereignisse: Dinge, die zu einem bestimmten Zeitpunkt passiert sind. Ein unerwarteter Neustart um 03:12 Uhr taucht in keiner CPU-Kurve auf -- als Ereignis schon.
Alle Ereignisse eines Servers landen in der Karte Verlauf auf der Detailseite. Über "Alle anzeigen" kommst du zur vollständigen Liste.
Die vier Lautstärken
Für jeden Ereignistyp legst du fest, wie laut LIVCK reagieren soll:
| Stufe | Wirkung |
|---|---|
| Nur Verlauf | Erscheint im Verlauf, benachrichtigt niemanden. |
| Info | Informations-Benachrichtigung mit niedriger Dringlichkeit -- nie ein nächtlicher Anruf. |
| Warnung | Warn-Benachrichtigung mit niedriger Dringlichkeit. |
| Alarm | Benachrichtigung mit hoher Dringlichkeit -- durchläuft deine Eskalationsrichtlinie und kann dich nachts wecken. |
Zugestellt wird über deine gewohnten Benachrichtigungskanäle und die üblichen Benachrichtigungsregeln.
Was der Agent meldet
Die Voreinstellungen sind so gewählt, dass du nur bei echten Problemen geweckt wirst:
| Ereignis | Voreinstellung | Bedeutung |
|---|---|---|
| Unerwarteter Neustart | Alarm | Der Server ist neu gestartet, ohne sich vorher abzumelden -- Absturz, Stromausfall oder ein hartes Reset durch den Hoster. Die gemeldete Ausfalldauer steht am Ereignis. |
| Festplatte voll | Alarm | Ein Dateisystem ist zu 100 % belegt. Das Ereignis nennt den betroffenen Einhängepunkt und wird erst wieder ausgelöst, wenn die Belegung zwischenzeitlich unter 95 % gefallen war. |
| Out-of-Memory-Kill | Warnung | Der Kernel hat mindestens einen Prozess wegen Speichermangel beendet. Klassische Ursache für „der Dienst war plötzlich weg". |
| Dateisystem schreibgeschützt | Warnung | Ein Dateisystem wurde read-only umgehängt -- typischerweise nach einem Storage- oder Dateisystemfehler. Meist der Vorbote eines Ausfalls. |
| Zeitabweichung erkannt | Warnung | Die Uhr des Servers weicht deutlich von der LIVCK-Zeit ab. Große Abweichungen verzerren Zeitreihen und Zertifikatsprüfungen. |
| Konfigurationsfehler | Warnung | Der Agent konnte eine Konfiguration nicht übernehmen und arbeitet mit der letzten funktionierenden weiter. |
| Puffer-Überlauf | Warnung | Der Agent konnte über längere Zeit nicht senden und musste die ältesten Messwerte verwerfen. |
| Sauber heruntergefahren | Info | Der Server wurde geplant heruntergefahren oder neu gestartet. Wird nicht als Ausfall gewertet. |
| System gestartet | Nur Verlauf | Der Server ist hochgefahren. |
| Konfiguration angewendet | Nur Verlauf | Der Agent hat eine neue Messkonfiguration übernommen. |
Ereignisse erzeugen keine Incidents
Sie benachrichtigen, ändern aber nicht den Status des Servers. Incidents entstehen aus zwei anderen Quellen: aus einem Server, der nicht mehr meldet (Offline), und aus einer ausgelösten Alarm-Regel.
Warum ein sauberes Herunterfahren kein Alarm ist
Genau das ist der Unterschied zwischen einem Server, den du selbst neu startest, und einem, der abstürzt. Ein geplanter Neustart meldet sich ordentlich ab, LIVCK wartet geduldig auf seine Rückkehr und schweigt. Ein Absturz meldet sich gar nicht ab -- und wird laut.
In der Konfigurationsliste erscheinen zusätzlich Ereignistypen, die bereits vorbereitet, aber noch nicht vom Agenten gemeldet werden -- etwa Neustart geplant, Agent aktualisiert, Agent-Update fehlgeschlagen und die systemd-Ereignisse Service-Unit fehlgeschlagen / Service-Unit instabil. Du kannst sie schon einstellen; sie treten derzeit einfach nicht auf. Der Ausgang eines Agent-Updates steht so lange im Reiter Updates.
Voreinstellungen ändern
Die Zuordnung gilt je Server. Du findest sie auf der Detailseite des Servers unter Ereignis-Benachrichtigungen im aufklappbaren Bereich Erweitert.
- Server öffnen
- Bereich Erweitert ausklappen
- Beim gewünschten Ereignistyp die Stufe wählen
Änderungen werden sofort gespeichert. Dafür brauchst du das Recht, Services zu bearbeiten -- siehe Rollen & Berechtigungen.
Weniger ist mehr
Wenn deine Server planmäßig nachts neu starten, stell Sauber heruntergefahren und System gestartet auf Nur Verlauf. Umgekehrt lohnt es sich, Out-of-Memory-Kill auf Alarm hochzustufen, wenn dein Dienst darauf empfindlich reagiert.
Weiterführende Themen
- Alarm-Regeln -- Alarme aus Schwellwerten statt aus Ereignissen
- Serverliste & Detailansicht -- wo der Verlauf steht
- Benachrichtigungskanäle -- wohin Benachrichtigungen gehen
- Eskalationsrichtlinien -- was bei Alarmen mit hoher Dringlichkeit passiert