Alarme

Überblick — was diese Seite leistet

Infrastruktur ▸ Alarme (/infra/alert) ist die Konsole für Alarmgruppen (Richtlinien). Ein Betreiber fügt einer einzigen Richtlinie (infr_alert_policy) Bedingungen aus vier Bereichen (System / Web / DB / Sicherheit) hinzu, stellt den Faktor jedes Schwellenwerts auf dem Bildschirm ein, und bei einer Überschreitung werden die Empfänger der Gruppe (infr_alert_recipient) automatisch per SMS/E-Mail benachrichtigt.

Sie ersetzt die frühere Seite „Kapazität und Alarme“ (/infra/capacity), die nun hierher weiterleitet.

Wesentliche Merkmale:

• Eine Richtlinie ist ein Überwachungspaket: Schweregrad, Unterdrückung erneuter Alarme (Abkühlzeit), Bereiche, Bedingungen, Kanäle und Empfänger liegen alle auf einer Karte. Legen Sie mehrere Richtlinien an, getrennt nach Team oder Schicht (z. B. „Infrastruktur-Nachtbereitschaft“, „Sicherheitsbetrieb“).
• Auswertung und Versand sind getrennt: AlertEvaluator wertet die Bedingungen aus; AlertDispatcher eröffnet Alarme und versendet sie. Beide werden von der Schaltfläche [Jetzt prüfen] in der Konsole und vom geplanten Befehl infr:eval-alerts gemeinsam genutzt.
• Deduplizierung, Abkühlzeit, Sammelversand, automatisches Schließen: Wiederholte Überschreitungen werden zu einem Alarm zusammengefasst, während der Abkühlzeit wird der erneute Versand unterdrückt, die Benachrichtigungen einer Richtlinie werden zu einer Nachricht gebündelt (verhindert SMS-Fluten), und Alarme schließen sich automatisch, sobald die Überschreitung behoben ist.
• Live-Daten nur lesend: System aus server_status, DB aus infr_db_metric, Sicherheit aus den Erkennungstabellen von legacy_glory, Web aus einer Live-HTTP-Sonde. Der Ablauf von Web-Zertifikaten durchsucht infr_web_cert global.

Diese Seite verwaltet ausschließlich Richtlinien, Alarme und den Versandverlauf. Diagramme je Server finden Sie unter Server; die Web-Verfügbarkeit unter Service ▸ Web; die DB-Last unter Service ▸ Datenbank. Die Standardwerte der Schwellenwerte werden in der Betriebsrichtlinie definiert.

Wann Sie sie einsetzen

• Sie möchten sofort benachrichtigt werden, wenn der Lastdurchschnitt oder der freie Speicherplatz eines Servers eine Gefahrengrenze überschreitet.
• Sie möchten die Rufbereitschaft benachrichtigen, wenn eine Landing-URL ausgefallen ist (unerwarteter Status / keine Antwort) oder langsam antwortet.
• Sie möchten die fehlgeschlagene automatische TLS-Erneuerung registrierter Web-Dienste (Zertifikat läuft bald ab) dauerhaft überwachen.
• Sie möchten Alarme, wenn sich die Warteschlange einer registrierten DB staut oder die stündliche Zahl langsamer Abfragen sprunghaft ansteigt.
• Sie möchten Überschreitungssignale an das Team verteilen: IDS-Alarmfluten, Anstiege von KI-Anomalie-Sperrungen, Anstiege neu gesperrter IPs.

Aufbau

Raster der Richtlinienkarten

Jede Richtlinie wird als eine Karte dargestellt, die ihren Aktivierungsschalter, das Schweregrad-Abzeichen, die aktivierten Bereiche und die Anzahl der Empfänger zusammenfasst, mit diesen Aktionen:

Bearbeitungsmodal (Bereiche, Bedingungen, Kanäle, Empfänger)

• Allgemein: Name, Schweregrad (info/warn/crit), Unterdrückung erneuter Alarme (Minuten), aktiv, Notiz.
• Alarmbereiche: System / Web / DB / Sicherheit aktivieren (System standardmäßig ein).
• Bedingungen: je aktiviertem Bereich ein/aus + Schwellenwert-Faktor (siehe Bedingungskatalog weiter unten).
• Kanäle: SMS und E-Mail. Der tatsächliche Versand erfordert einen Anbieter unter Mail-Adapter/SMS-Adapter; die Karte warnt, wenn kein Anbieter konfiguriert ist.
• Empfänger (Wiederholfeld): Name, E-Mail, Telefon + Häkchen via_mail/via_sms. Der wirksame Kanal ist die Schnittmenge aus den Kanälen der Richtlinie ∩ den via_* des Empfängers.

Feed der jüngsten Alarme

Zeigt infr_alert absteigend nach last_seen sortiert, bis zu 60 Zeilen (Abfrage alle 30 s). Jede Zeile zeigt den beobachteten Wert, den Schwellenwert, den aggregierten count sowie erfolgreich/gesamt versandt (aus infr_alert_delivery), mit den Statusübergängen [Bestätigen] und [Schließen].

Vorgehen

1) Eine Richtlinie anlegen

1. [Neue Alarmgruppe] → Name, Schweregrad und Abkühlzeit eingeben.
2. Aktivieren Sie die Bereiche, die Sie überwachen möchten.
3. Aktivieren Sie je Bereich Bedingungen und passen Sie die Schwellenwert-Faktoren an. Die Standardwerte werden aus alertDefaults() der Betriebsrichtlinie vorbelegt.
4. Wählen Sie die Kanäle (SMS/Mail) und fügen Sie Empfänger hinzu.
5. Speichern.

2) Bedingungskatalog

System (server_status, seq-Fenster)

• Ziel sind standardmäßig alle Server (targets.system.all=true); Sie können auf ausgewählte Aliase eingrenzen (max. 200).
• Die Momentaufnahme liest nur das jüngste seq-Fenster (distinct seq desc limit 3), um langsame Abfragen zu vermeiden (von HealthService übernommen). Offline-Server oder Server ohne Daten werden nicht bewertet — ein Server muss in den letzten 2 Zyklen loadavg aufweisen, um als online zu gelten.
• Der freie Speicherplatz verwendet die knappste Partition unter df-, df-data und df-home (DfParse::availableGb).

Web (Live-HTTP-Sonde · infr_web_cert)

• Die Ziel-URLs stammen aus targets.web.urls[] (mit Beschriftungen, max. 30 je Richtlinie). Jeder Auswertungszyklus ruft sie direkt über Http::connectTimeout(4)->withoutVerifying()->get() ab. Ein vom Erwartungswert abweichender Status oder ein Verbindungsfehler bzw. Zeitüberschreitung gilt als ausgefallener Dienst (sofern die Statuscode-Bedingung aktiv ist).
• Der Zertifikatsablauf ist nur ein Schalter, der Suchlauf ist jedoch global: unabhängig von den Ziel-URLs der Richtlinie durchsucht er die infr_web_cert-Einträge aller Domains aller registrierten Web-Dienste und meldet für jede Domain, die innerhalb des Schwellenwerts (web_cert_hours, Standard 48 h) abläuft, eine Überschreitung — bis zu 50 je Auswertung. Die Zertifikate werden von WebProbeService in einer 6-Stunden-Rotation aktualisiert. So wird eine fehlgeschlagene automatische Erneuerung erkannt, bevor ein Ablauf jemanden überrascht.

Aktivieren Sie nur „Zertifikatsablauf steht bevor“, so wird das Zertifikat jeder Website überwacht. Die Bedingung wirkt nicht je Website — sie ist ein globaler Suchlauf über alle Domains.

Datenbank (jüngste Stichprobe aus infr_db_metric)

• Ziele sind targets.database.collectors[] (Collector-Schlüssel mit access=database). Ist kein Ziel ausgewählt, wird nichts ausgewertet.
• Es wird DbCollectorService::latest($collector) gelesen, bewertet werden jedoch nur Stichproben mit Status ok, die jünger als 10 Minuten sind (vermeidet Fehlalarme durch veraltete Daten). Registrierung und Erfassung erfolgen über DB-Collectors.

Sicherheit (Erkennungstabellen in legacy_glory · zusammengesetzt)

Das Auswertungsfenster ist sec_window_min (Standard 10 Min.). Überschreitet auch nur ein Signal seinen Schwellenwert, löst dies eine Überschreitung aus.

Verwandt: Bedrohungen · Erkennungen · Sperrliste.

3) Jetzt prüfen / Testen

• [Jetzt prüfen] (run): führt evaluate() → handle() sofort für genau diese eine Richtlinie aus und liefert eine Zusammenfassung zu Überschreitungen/Versand (breaches :b · sent :s) sowie den aktualisierten Feed zurück. Damit bestätigen Sie, dass eine Bedingung wirklich auslöst, ohne auf den Planer zu warten.
• [Testen] (test): sendet sofort eine Test-Mail/SMS an die aktiven Empfänger, um zu bestätigen, dass der Kanal funktioniert (unabhängig von jeder Überschreitung — eine Zustandsprüfung des Anbieters).

4) Automatische Auswertung (Zeitplan)

Aktive Richtlinien werden jede Minute automatisch ausgewertet und versendet.

Schedule::command('infr:eval-alerts --quiet-if-ok')
    ->everyMinute()
    ->withoutOverlapping(2)
    ->onOneServer()
    ->when($is_leader);

Manuelle Ausführung:

# Alle aktiven Richtlinien auswerten (Einmallauf, beendet sich danach — kein Daemon)
php artisan infr:eval-alerts

# Nur eine einzelne Richtlinie
php artisan infr:eval-alerts --policy=12

# Ausgabe unterdrücken, wenn keine Überschreitung vorliegt (Standard des Planers)
php artisan infr:eval-alerts --quiet-if-ok

infr:eval-alerts ist ein Einmalbefehl, der sich beendet (er durchläuft die Richtlinien und kehrt zurück). Machen Sie daraus niemals einen Daemon mit Endlosschleife — ein nie endender Daemon, der aus dem Planer gestartet wird, erschöpft die gemeinsam genutzten DB-Verbindungen (siehe die Lehre aus dem Verbindungsleck von pulse:check). Der Planer startet gefahrlos jede Minute eine frische Instanz.

Datenquellen

Schreibtabellen (neu, infr_)

Lesequellen (Legacy + neu, nur lesend)

• System: server_status (Verbindung legacy, part=loadavg/df-*).
• Web: Live-HTTP-GET (Ziel-URLs) + infr_web_cert (Zertifikatsablauf).
• DB: infr_db_metric (von Collectors mit access=database befüllt).
• Sicherheit: suricata_alert_ct, kitsune_detail_log, blacklist_info in legacy_glory.

Ablauf von Deduplizierung / Abkühlzeit / automatischem Schließen

1. AlertEvaluator::evaluate($policy) → Array der Überschreitungskandidaten je aktivem Bereich. Ausnahmen eines Bereichs bleiben isoliert (fällt ein Bereich aus, blockiert das die übrigen nicht).
2. AlertDispatcher::handle($policy, $breaches):
   • Jede Überschreitung wird über (policy_id, metric, entity_key, status=open) gesucht → wird sie gefunden, erfolgt eine Aktualisierung + count++; andernfalls wird neu eingefügt (first_seen, count=1, notified_at=null).
   • Benachrichtigungsfähig = neu ODER notified_at null ODER notified_at <= now - cooldown_min.
   • Automatisches Schließen: offene Alarme dieser Richtlinie, die in den Überschreitungen dieser Runde fehlen → status='closed'.
   • Sammelversand: benachrichtigungsfähige Alarme werden je Empfänger und Kanal zu einer Nachricht gebündelt (Textkörper max. 8 Zeilen, Überhang „+N more“; SMS auf 140 Zeichen begrenzt). Nach dem Versand gilt für jedes Ziel notified_at=now.
   • Eine Zeile infr_alert_delivery je (Empfänger, Kanal).

Zugriff

Stufenskala: demo=1 · staff=5 · admin=10. Lesevorgänge erfordern Stufe≥1; Schreibvorgänge und Versand erfordern Stufe≥2. Alle destruktiven Vorgänge und Versandvorgänge werden in infr_audit_log protokolliert (siehe Audit-Protokoll). Die Anbieter der Versandkanäle konfiguriert ein Administrator (Stufe≥10).

Fehlerbehebung und FAQ

F. Ich habe eine Bedingung aktiviert, aber es kommt kein Alarm an.

1. Prüfen Sie, ob die Richtlinie aktiv ist und der Planer (schedule:work / Produktions-Supervisor) läuft.
2. Kein Kanalanbieter — beachten Sie die Warnung auf der Karte und konfigurieren Sie einen Standardanbieter unter Mail-Adapter/SMS-Adapter.
3. Vergewissern Sie sich, dass die Schnittmenge aus via_mail/via_sms des Empfängers und den Kanälen der Richtlinie nicht leer ist und dass E-Mail bzw. Telefon ausgefüllt sind.
4. Während der Abkühlzeit wird der erneute Versand unterdrückt (cooldown_min, Standard 30 Min.). Mit [Jetzt prüfen] können Sie es sofort verifizieren, ein bereits benachrichtigter Alarm wird jedoch erst nach Ablauf der Abkühlzeit erneut versendet.

F. Meine DB-/Systembedingungen bleiben stumm.

• System: Der Zielserver muss online sein (loadavg in den letzten 2 seq-Zyklen), um bewertet zu werden. Offline bzw. ohne Daten wird übersprungen.
• DB: Die jüngste Stichprobe aus infr_db_metric muss ok und jünger als 10 Minuten sein. Prüfen Sie unter DB-Collectors, ob der Collector läuft.

F. Überwacht der Zertifikatsablauf nur eine bestimmte Website?

• Nein. web_cert_on ist ein globaler Suchlauf — er durchsucht infr_web_cert für alle Domains aller registrierten Web-Dienste, unabhängig von den Ziel-URLs der Richtlinie.

F. Stapelt sich dieselbe Überschreitung immer weiter?

• Nein. Sie wird auf einem offenen Alarm mit dem Schlüssel (policy_id, metric, entity_key) aggregiert (count++). Sobald die Überschreitung behoben ist, setzt die nächste Auswertung sie automatisch auf closed.

F. Verlangsamt die Web-Sonde die Auswertung?

• Die URLs sind auf 30 je Richtlinie begrenzt, mit 4 s Verbindungszeitlimit und einem kurzen, latenzbasierten Zeitlimit. Die System-Momentaufnahme liest nur das seq-Fenster, um langsame Abfragen zu vermeiden.

Verwandte Themen

• Betriebsrichtlinie — definiert die Standardwerte der Schwellenwerte (alertDefaults())
• Mail-Adapter · SMS-Adapter — Anbieter der Versandkanäle
• Service ▸ Web — Quelle für Zertifikat/Verfügbarkeit (infr_web_cert)
• DB-Collectors — Quelle der DB-Bedingung (infr_db_metric)
• Server · Zustand — Quelle der Systembedingung (server_status)
• Bedrohungen · Sperrliste — Quellen der Sicherheitsbedingungen