Alarm-Regeln
Mit Alarm-Regeln legst du fest, wann ein Server nicht mehr gesund ist: „CPU über 90 % für 10 Minuten", „Root-Partition über 85 %", „Datenbank nicht erreichbar". Löst eine Regel aus, ändert LIVCK den Status des Servers, öffnet einen Incident und benachrichtigt dein Team über die gewohnten Kanäle.
Alarm-Regeln sind das Gegenstück zu den Bedingungen beim klassischen Monitoring -- nur auf Server-Metriken statt auf HTTP-Antworten.
Wo du sie findest
Zwei Wege führen hin:
- Server → Server öffnen → Bearbeiten → Reiter Alarm-Regeln
- Direkt aus einer Metrik-Kachel der Detailansicht über den Alarm-Knopf -- der Dialog ist dann schon mit der passenden Metrik und Instanz vorbelegt
Drei Regeln sind schon da
Beim ersten Anmelden eines Servers legt LIVCK ein Standard-Paket an, damit du nicht bei Null anfängst:
| Metrik | Regel | Dauer | Auswirkung |
|---|---|---|---|
| CPU-Auslastung gesamt | ≥ 90 % | 10 Minuten | Beeinträchtigt |
| Arbeitsspeicher-Belegung | ≥ 90 % | 10 Minuten | Beeinträchtigt |
| Belegung der Root-Partition | ≥ 85 % | sofort | Beeinträchtigt |
Du kannst sie anpassen, deaktivieren oder löschen. Solange du sie unverändert lässt, zählen sie nicht gegen dein Regel-Limit.
Eine Regel anlegen
Klicke auf "Regel hinzufügen". Der Dialog fragt sechs Dinge ab:
Metrik
Jeder gemessene Wert lässt sich überwachen, gruppiert nach: CPU, System-Last, Ressourcen-Druck (PSI), Arbeitsspeicher, Swap, Prozesse, Laufzeit, Festplatte, Festplatten-I/O, Netzwerk, GPU, SMART und Agent.
Bei Metriken, die es mehrfach gibt, wählst du zusätzlich die Instanz: den Einhängepunkt (/, /var), das Gerät (sda, nvme0n1), die Schnittstelle (eth0), die GPU, den Datenträger oder das Erreichbarkeits-Ziel. Die Auswahlliste enthält nur Instanzen, die dieser Server auch tatsächlich meldet.
Operator
| Operator | Bedeutung |
|---|---|
| größer als (>) | Wert muss darüber liegen |
| größer oder gleich (≥) | Wert muss den Schwellwert erreichen oder überschreiten |
| kleiner als (<) | Wert muss darunter liegen |
| kleiner oder gleich (≤) | Wert muss den Schwellwert erreichen oder unterschreiten |
Bei An/Aus-Werten -- Erreichbarkeit eines Prüfziels, SMART-Gesundheitsstatus -- gibt es statt Operator und Schwellwert einen einfachen Umschalter: Alarm auslösen, wenn der Wert 0 (nicht erreichbar / nicht OK) oder 1 (erreichbar / OK) ist. Der Alarm hebt sich automatisch auf, sobald sich der Zustand umkehrt.
Schwellwert
Der Vergleichswert. LIVCK begrenzt die Eingabe passend zur Einheit -- Prozentwerte auf 0 bis 100, Byte- und Zähler-Werte auf nicht-negative Zahlen.
Dauer
Wie lange die Bedingung ununterbrochen erfüllt sein muss, bevor die Regel auslöst. Angabe in Sekunden, von 0 (sofort) bis 86.400 (24 Stunden).
Die Dauer ist dein wichtigster Filter gegen Fehlalarme
Eine CPU-Spitze von 95 % während eines Deployments ist normal. 95 % über zehn Minuten sind ein Problem. Setze bei schwankenden Werten (CPU, Last, Netzwerk) 300 bis 600 Sekunden an -- bei Werten, die sich langsam bewegen (Festplattenbelegung), kannst du direkt bei 0 bleiben.
Auswirkung
| Auswirkung | Was passiert |
|---|---|
| Beeinträchtigt | Der Service wechselt auf Beeinträchtigt (gelb). LIVCK legt einen Incident mit geringer Schwere an und benachrichtigt mit niedriger Dringlichkeit. |
| Ausfall | Der Service wechselt auf Offline (rot). LIVCK legt einen vollwertigen Incident an und alarmiert mit hoher Dringlichkeit -- inklusive Eskalation, wenn eine hinterlegt ist. |
Bei fehlenden Daten
Was gelten soll, wenn der Agent diese Metrik gerade nicht meldet -- etwa weil eine Festplatte ausgehängt wurde:
| Option | Verhalten |
|---|---|
| Ignorieren (Zustand halten) | Standard und meist richtig: Der letzte bekannte Zustand bleibt bestehen. |
| Als Verletzung werten | Fehlender Wert gilt als Alarm. Sinnvoll, wenn das Fehlen selbst schon ein Problem ist. |
| Als Erholung werten | Fehlender Wert gilt als Entwarnung. |
Ein fehlender Wert ist nie eine Null
LIVCK setzt fehlende Messwerte niemals stillschweigend auf 0 -- eine Regel „Festplatte kleiner als 10 % frei" schlägt also nicht Alarm, nur weil die Platte kurz nicht gemeldet wurde.
Der Lebenszyklus einer Regel
Jede Regel hat einen sichtbaren Zustand:
| Zustand | Bedeutung |
|---|---|
| OK | Der Schwellwert wird eingehalten. |
| Ausstehend | Der Schwellwert ist verletzt, die eingestellte Dauer läuft aber noch. Noch kein Alarm. |
| Alarm | Die Regel hat ausgelöst -- Status geändert, Incident offen, Benachrichtigung raus. |
| Unterdrückt | Der Server ist offline. Die Regel wird eingefroren, bis er zurück ist. |
Kein Alarm-Gewitter, wenn ein Server ausfällt
Fällt ein Server komplett aus, würden schlagartig alle Regeln „keine Daten" melden. LIVCK unterdrückt sie deshalb automatisch und meldet nur das Eigentliche: Der Server ist offline. Kommt er zurück, werten die Regeln normal weiter aus.
Sinkt der Wert wieder unter den Schwellwert, erholt sich die Regel von selbst, der Status kehrt auf Online zurück und der Incident wird automatisch geschlossen.
Hysterese (Erholungs-Abstand)
Für Werte, die um den Schwellwert herum pendeln, gibt es einen Erholungs-Abstand: Die Regel löst bei 90 % aus, gilt aber erst bei z.B. 85 % wieder als erholt. Das verhindert Alarm-Ping-Pong.
Dieser Wert lässt sich derzeit nur über die API setzen, nicht im Dialog. In der Oberfläche erreichst du denselben Effekt meist einfacher über eine längere Dauer.
Was Vorrang hat
Melden mehrere Signale gleichzeitig, gilt diese Rangfolge:
Server offline > Regel „Ausfall" > Regel „Beeinträchtigt" > Online
Ein manuell überschriebener Status schlägt alles -- die Auswertung im Hintergrund läuft aber weiter.
Wie viele Regeln du anlegen darfst
Es gilt das gleiche Limit wie für Bedingungen beim klassischen Monitoring:
| Plan | Regeln pro Server |
|---|---|
| Free | 5 |
| Ab Solo-Plan Solo | 15 |
| Ab Team-Plan Team | 30 |
| Ab Business-Plan Business | 50 |
Nur selbst angelegte Regeln zählen -- das mitgelieferte Standard-Paket ist frei, solange du es nicht inhaltlich änderst. Der Zähler über der Liste zeigt dir deinen Stand.
Bewährte Regeln zum Abschauen
| Ziel | Metrik | Regel | Dauer | Auswirkung |
|---|---|---|---|---|
| Festplatte läuft voll | Festplattenbelegung / | ≥ 90 % | sofort | Ausfall |
| Inodes laufen voll | Inode-Belegung / | ≥ 90 % | sofort | Beeinträchtigt |
| Speicherdruck | Swap-Belegung | ≥ 50 % | 600 s | Beeinträchtigt |
| Dauerhafte Überlast | CPU gesamt | ≥ 95 % | 900 s | Beeinträchtigt |
| Lahmer Cloud-Nachbar | CPU Steal | ≥ 20 % | 600 s | Beeinträchtigt |
| Storage hakelt | Ressourcen-Druck I/O | ≥ 50 % | 300 s | Beeinträchtigt |
| Netzwerkprobleme | Empfangsfehler eth0 | > 0 | 300 s | Beeinträchtigt |
| Laufwerk stirbt | SMART-Gesundheit | Wert = 0 | sofort | Ausfall |
| Datenbank weg | Erreichbarkeit des Ziels | Wert = 0 | 120 s | Ausfall |
Über die API
Ab dem Ab Team-Plan Team-Plan kannst du Alarm-Regeln auch über die API verwalten -- praktisch, um sie zusammen mit deiner Infrastruktur auszurollen.
Weiterführende Themen
- Was gemessen wird -- alle verfügbaren Metriken
- Ereignisse & Benachrichtigungen -- Alarme aus Systemereignissen statt Schwellwerten
- Erreichbarkeits-Prüfungen -- Ziele, auf die du Regeln setzen kannst
- Eskalationsrichtlinien -- wer bei einem Ausfall wann gerufen wird
- Benachrichtigungskanäle -- wohin die Alarme gehen