Alarmregeln

Alarmregeln gehören zu Vaicoa Pro und Vaicoa Team. Die Uptime-Checks eines kostenlosen Kontos zeigen ihre Ergebnisse, senden aber keine Alarme.

Jede Regel, die Vaicoa für dein Team auswertet. Wie du einem Alarm von der Mitteilung bis zur Ursache folgst, steht unter Wenn etwas Aufmerksamkeit braucht.

So liest du die Tabellen

Spalte	Bedeutung
Mitteilung	auf dem iPhone der Titel der Push-Mitteilung, nach Critical: oder Warning:
Regel	zuerst der rule_key, dann der interne Name der Regel. Die App zeigt den rule_key unter dem Titel des Alarms (Warnung · disk_space_low), Webhooks senden ihn als alert.rule, PagerDuty als custom_details.rule
Schwere	kritisch oder Warnung
Löst aus, wenn	die Bedingung und wie lange sie anhalten muss, bevor der Alarm ausgelöst wird

Die Regeln werden alle 30 Sekunden ausgewertet. Die Schwellwerte sind für jedes Team gleich. Selbst festlegen kannst du nur das Antwortzeit-Budget eines Checks und das Höchstalter eines Jobs.

Server: Hetzner-Cloud-Metriken

Für Cloud-Server in einem verbundenen Projekt, aus den Metriken, die Hetzner für sie meldet. Dedizierte Server haben keine Hetzner-Metriken, deshalb decken diese beiden Regeln sie nicht ab.

Mitteilung	Regel	Schwere	Löst aus, wenn
server offline	host_offline · HostOffline	kritisch	Hetzner führt den Server als laufend, hat aber seit mehr als 3 Minuten keine Metriken für ihn geliefert. Bleibt aktiv, solange das anhält; endet, wenn wieder Metriken kommen oder der Server ausgeschaltet oder gelöscht wird
CPU saturated	cpu_saturated · CPUSaturated	Warnung	Hetzners CPU-Wert für den Server liegt 15 Minuten lang über 95 %

• server offline löst nie aus für einen Server, den Hetzner als ausgeschaltet meldet, auch wenn er zwischen zwei Synchronisierungen ausgeschaltet wurde, für einen gelöschten Server, solange die Hetzner-API nicht erreichbar ist oder das Token des Projekts ablehnt (dafür gibt es den Token-Alarm), und nicht, wenn Hetzner für alle Teams gleichzeitig still wird.
• Auch ein Server, der ausgeschaltet wurde, ohne dass du es getan hast, löst keinen Alarm aus: Hetzner meldet ihn als ausgeschaltet und nennt keinen Grund. Ein Uptime-Check auf seine Adresse überwacht das.

Server: der Agent meldet sich nicht mehr

Für Server, auf denen der Agent läuft. Der Agent sendet alle 30 Sekunden Metriken; diese Regel löst aus, wenn keine mehr ankommen.

Mitteilung	Regel	Schwere	Löst aus, wenn
stopped reporting	agent_silent · AgentSilent	kritisch	Ein dedizierter Server oder ein Cloud-Server, der nicht mit seiner Hetzner-Ressource verknüpft ist, hat mehr als 5 Minuten lang keine Agent-Metriken gesendet
stopped reporting	agent_silent · AgentSilent	Warnung	Der Agent eines Cloud-Servers hat mehr als 5 Minuten lang keine Metriken gesendet, während Hetzner die eigenen Metriken des Servers weiter liefert

• Der Alarm bleibt aktiv, solange der Server schweigt, und endet mit der ersten neuen Meldung.
• Kritisch, wo der Agent das einzige Signal ist: bei einem dedizierten Server oder einem Cloud-Server, der mit einem eigenen Agent-Token statt mit einem Flotten-Token registriert wurde und den Vaicoa deshalb nicht seiner Hetzner-Ressource zuordnen kann. Der Alarm kann einen ausgefallenen Server nicht von einem angehaltenen Agent unterscheiden; ein Uptime-Check auf die Adresse des Servers kann das.
• Warnung bei einem Cloud-Server, den Hetzner weiter meldet: Der Server läuft, aber bis der Agent sich wieder meldet, gibt es für ihn keine Festplatten-, Speicher- oder Log-Alarme. systemctl status cloudviewer-agent auf dem Server zeigt, warum.
• Schweigt auch Hetzner, löst nur server offline aus, nicht beide. Ein Cloud-Server, der nicht mit seiner Hetzner-Ressource verknüpft ist, kann beide bekommen.
• Die Regel löst nicht aus für einen Server, der sich noch nie gemeldet hat (Warten auf Agent) oder nur Job-Reports sendet, einen Server außer Dienst, einen Server mit entzogenen Tokens, ein Team ohne Pro oder Team, einen verknüpften Cloud-Server, den Hetzner nicht als laufend meldet (ausgeschaltet, im Rebuild), oder ein Prüfziel.
• Verstummen die Agents aller Teams gleichzeitig, liegt die Ursache bei uns, und die Regel hält sich zurück, statt alle zu alarmieren.

Server: der Agent

Für Cloud- und dedizierte Server, auf denen der Agent läuft, aus dem, was er auf dem Host misst.

Mitteilung	Regel	Schwere	Löst aus, wenn
disk space low	disk_space_low · DiskSpaceLow	Warnung	Ein Dateisystem ist 10 Minuten lang zu mehr als 80 % belegt
disk almost full	disk_space_critical · DiskSpaceCritical	kritisch	Ein Dateisystem ist 5 Minuten lang zu mehr als 90 % belegt
disk fills within a day	disk_fills_within_24h · DiskFillsWithin24h	Warnung	Ein Dateisystem ist zu mehr als 60 % belegt und nach dem Tempo der letzten sechs Stunden und der letzten Stunde innerhalb von 24 Stunden voll, 90 Minuten lang
disk fills within hours	disk_fills_within_4h · DiskFillsWithin4h	kritisch	Ein Dateisystem ist zu mehr als 70 % belegt und nach dem Tempo der letzten zwei Stunden und der letzten halben Stunde innerhalb von 4 Stunden voll, 45 Minuten lang
memory pressure	memory_pressure · MemoryPressure	Warnung	Die Speichernutzung liegt 10 Minuten lang über 90 %

• Die Festplatten-Regeln gelten für jeden Mountpoint einzeln. Dateisysteme im Speicher und Image-Dateisysteme (tmpfs, devtmpfs, ramfs, squashfs, erofs, overlay und ähnliche) werden übersprungen, ebenso die Volume-Mounts einzelner Pods auf einem Kubernetes-Node (/var/lib/kubelet/pods/…).
• Die beiden Prognosen brauchen zwei Raten, die übereinstimmen. Ein einzelner Schub, etwa ein Image-Pull oder ein Restore, löst sie deshalb nicht aus, nur stetiges Wachstum.
• Die Speichernutzung ist der Gesamtspeicher minus dem verfügbaren Speicher. Page Cache, den der Kernel freigeben kann, zählt also nicht.

Server: LVM-Thin-Pools

Für Server, die ihre LVM-Thin-Pools als node_lvm_thin_pool_data_percent und node_lvm_thin_pool_metadata_percent melden (nach vg und lv, die Prozentwerte, die lvs zeigt), wie es PaaSbox-Hosts tun.

Mitteilung	Regel	Schwere	Löst aus, wenn
thin pool filling	thin_pool_space_low · ThinPoolSpaceLow	Warnung	Die Daten eines Thin-Pools sind 15 Minuten lang zu mehr als 80 % belegt
thin pool almost full	thin_pool_space_critical · ThinPoolSpaceCritical	kritisch	Die Daten eines Thin-Pools sind 5 Minuten lang zu mehr als 90 % belegt
thin-pool metadata filling	thin_pool_metadata_low · ThinPoolMetadataLow	Warnung	Die Metadaten eines Thin-Pools sind 15 Minuten lang zu mehr als 80 % belegt
thin-pool metadata almost full	thin_pool_metadata_critical · ThinPoolMetadataCritical	kritisch	Die Metadaten eines Thin-Pools sind 5 Minuten lang zu mehr als 90 % belegt

• Ein voller Pool oder volle Metadaten lassen jeden Schreibzugriff auf jedes Volume im Pool scheitern, auch wenn das Dateisystem des Volumes noch Platz hat.

Log-Zeilen: der Agent

Aus den journald-Zeilen ab Schweregrad Warning, die der Agent für den Log-Kontext sendet. Es zählen nur Zeilen, die gespeichert wurden, also nach der Grenze von 120 Zeilen pro Minute und Server.

Mitteilung	Regel	Schwere	Löst aus, wenn
critical log lines	log_critical_lines · CriticalLogLine	Warnung	Mindestens eine Zeile mit Priorität 0–2 (emergency, alert, critical: zum Beispiel ein Kernel-Oops oder ein Out-of-Memory-Kill) in den letzten 10 Minuten. Löst sofort aus und endet 10 Minuten nach der letzten solchen Zeile
error-log burst	log_error_burst · ErrorLogBurst	Warnung	Mehr als 30 Zeilen mit Priorität 0–3 (error oder schlimmer) innerhalb von 15 Minuten, 5 Minuten lang

Für SSH- und sudo-Zeilen gibt es keine Regel.

Job-Reports

Aus deinen Job-Reports.

Mitteilung	Regel	Schwere	Löst aus, wenn
job failed	user_job_failed · UserJobFailed	Warnung	Der letzte Report des Jobs hat einen Exit-Code ungleich null, 5 Minuten lang
job stale	user_job_stale · UserJobStale	Warnung	Der letzte erfolgreiche Durchlauf des Jobs ist älter als das max_age_seconds, das er angegeben hat, 5 Minuten lang

• Ein Job, der kein max_age_seconds angibt, bekommt nur job failed.
• „Veraltet“ zählt ab dem letzten erfolgreichen Durchlauf. Ein Job, der nie erfolgreich war, gilt nie als veraltet.

Uptime-Checks

Aus deinen Uptime-Checks. Ein Check ist nur Nicht erreichbar, wenn beide Netze übereinstimmen. Uneinheitlich und Keine Daten lösen nie einen Alarm aus.

Mitteilung	Regel	Schwere	Löst aus, wenn
unreachable from outside	check_down · CheckDown	kritisch	Der Check ist 1 Minute lang nicht erreichbar
certificate expiring	check_cert_expiring · CheckCertExpiring	Warnung	Das Zertifikat ist noch weniger als 14 Tage gültig, 15 Minuten lang
certificate expires imminently	check_cert_expiring_critical · CheckCertExpiringCritical	kritisch	Das Zertifikat ist noch weniger als 3 Tage gültig, 15 Minuten lang
slower than its budget	check_slow · CheckSlow	Warnung	Die Antwortzeit aus einem der beiden Netze liegt 10 Minuten lang über dem Antwortzeit-Budget des Checks. Nur für Checks mit Budget, das du im Portal setzt

Die Mitteilung sagt „unreachable“ und nicht „down“, weil sie neben einer Ressource erscheinen kann, die Hetzner weiterhin als laufend meldet.

Unterdrückte Alarme

Solange der kritische Alarm aktiv ist, wird die passende Warnung nicht gesendet.

Solange dieser aktiv ist	unterdrückt er	bei gleichem
disk_space_critical	disk_space_low	Server und Mountpoint
disk_fills_within_4h	disk_fills_within_24h	Server und Mountpoint
thin_pool_space_critical	thin_pool_space_low	Server und Thin-Pool
thin_pool_metadata_critical	thin_pool_metadata_low	Server und Thin-Pool
check_cert_expiring_critical	check_cert_expiring	Check

Wohin Alarme gehen

Kanal	Schweregrade	Stummgeschaltete Alarme
Die App: Aktive Alarme, Historie, die Ansicht der Ressource	alle	angezeigt, als stumm gekennzeichnet
Push-Mitteilungen	alle; kritische sind auf dem iPhone zeitkritisch	nicht gesendet
E-Mail-Zusammenfassung	Warnung und kritisch oder nur kritisch	nie enthalten
Alarmziele: Webhook, PagerDuty	Warnung und kritisch oder nur kritisch, je Ziel	nie gesendet

Übersicht und Alarmziele tragen nie Alarme mit der Schwere info. Keine der Regeln auf dieser Seite ist info. Übersicht und Ziele einrichten: Alarme dorthin schicken, wo du arbeitest.

Stummschaltungen

• Dauer: 1 Stunde, 4 Stunden oder 24 Stunden. Die App kann eine Stummschaltung mit Stummschaltung aufheben vorzeitig beenden und mit Stummschaltung verlängern verlängern.
• Ein stummgeschalteter Alarm bleibt aktiv. Er bleibt sichtbar, als stumm gekennzeichnet, und wird in der Historie aufgezeichnet.
• Jedes Teammitglied kann einen Alarm in der App stummschalten.

Historie

• Die Alarm-Historie wird 90 Tage aufbewahrt.
• Historie in der App zeigt die letzten 30 Tage. Diese Woche N× ausgelöst zählt die letzten 7 Tage.
• get_alert_history im Claude-Connector liefert die letzten 7 Tage.

Was keine Regel hat

• Load Balancer, Floating IPs, Volumes, Netzwerke und primäre IPs haben keine eigenen Regeln. Um einen Load Balancer oder eine Floating IP zu überwachen, leg im Portal einen Uptime-Check an, der an der Ressource hängt; seine Alarme erscheinen dann dort.
• CPU auf dedizierten Servern: Die CPU-Regel liest Hetzners Cloud-Metriken, die dedizierte Server nicht haben.
• Load Average, Festplatten-I/O und Netzwerkverkehr: als Chart, ohne Regel.