Kapitel 19 Compliance, Storage & Betrieb Admin: #pAlerts

Betriebs-Dashboard, Alarme und Live-Telemetrie

Das Betriebs-Dashboard (#pOps) zeigt live und als 24-Stunden-Verlauf: Mails pro Minute ein und aus, zurückgestellte und unzustellbare Mails, Spam-Quote, Anmeldefehler, Warteschlange und Alter der ältesten Mail, aktive Verbindungen je Protokoll, CPU, Arbeitsspeicher, freien Speicherplatz, Datenbankgröße, Zertifikatslaufzeit und Cluster-Knoten. Alarme (#pAlerts) melden Überschreitungen per E-Mail, Webhook, SMS, Telegram, Signal oder WhatsApp. Externe Werkzeuge lesen denselben Datenstrom über /metrics (Prometheus), OpenTelemetry oder den Live-Ereignisstrom (Server-Sent Events).

Praxis-Tipp & Architektur-Hinweis

Beim ersten Start legt nextxch fünf Regeln ohne Ziel an (Warteschlange hängt, Speicher fast voll, Zertifikat läuft ab, viele Anmeldefehler, viele Bounces). Sie erscheinen im Verlauf; damit sie benachrichtigen, unter Ziele eine E-Mail-Adresse oder einen Webhook anlegen und in der Regel anhaken. Der Verlauf bleibt über Neustarts erhalten (Ops:PersistHistory = false schaltet das ab).

Live-Ereignisstrom für Monitoring-Werkzeuge

Authentifizierung wie die Admin-API (API-Key eines Admins per X-Api-Key, Bearer oder Basic). Mandanten-Admins sehen nur ihren Mandanten. Filter: types, direction, status, q; maxRate begrenzt Ereignisse pro Sekunde (Standard 20, max. 200), Überzähliges meldet ein dropped-Ereignis.

Referenz / Konfiguration

curl -N -H "X-Api-Key: $NEXTXCH_KEY" \
  "https://mail.firma.de/api/admin/telemetry/stream?types=delivery,rejection,auth-failure&maxRate=50"

event: delivery
data: {"at":"2026-11-02T08:15:01Z","direction":"Outbound","status":"Delivered","from":"rechnung@firma.de","to":"kunde@example.com","code":250,...}

event: auth-failure
data: {"account":"info@firma.de","protocol":"IMAP","remoteIp":"203.0.113.7","reason":"invalid password"}

# Typen: delivery, rejection, auth-failure, filter, alert, queue

Einstellungen, Standardwerte & Best Practices

Einstellung / Ort	Funktion	Standardwert	Best Practice im Betrieb
`Alarmregel`	Messwert, Bedingung (>, >=, <, <=), Schwelle und Dauer in Minuten. Erst wenn die Bedingung so lange ununterbrochen gilt, löst der Alarm aus.	`5 min`	Kurze Spitzen ignorieren: bei Raten (pro Minute) mindestens 5 Minuten, bei Zertifikatslaufzeit 0 Minuten.
`Abklingzeit, Wiederholung, Entwarnung`	Die Abklingzeit ist der Mindestabstand zwischen zwei Meldungen derselben Regel; Wiederholen erinnert, solange der Alarm aktiv bleibt; die Entwarnung meldet das Ende.	`60 min / aus / an`	Abklingzeit nicht unter 30 Minuten, damit ein schwankender Wert nicht ständig meldet.
`Ziele`	E-Mail (Absender ist der Admin, der die Einstellungen gespeichert hat), Webhook (JSON mit type nextxch.alert, signiert mit X-Nextxch-Signature: sha256=...), SMS, Telegram, Signal, WhatsApp über die Kanäle unter Benachrichtigungen.	`-`	Mindestens ein Ziel außerhalb des eigenen Mailservers (SMS, Messenger oder Webhook) anlegen: fällt die Zustellung aus, kommt eine Alarm-Mail nicht an.
`Messwerte in Prometheus und OpenTelemetry`	Jeder Dashboard-Wert steht unter /metrics: nextxch_mail_inbound_total, nextxch_mail_outbound_total, nextxch_mail_deferred_total, nextxch_mail_bounced_total, nextxch_mail_rejected_total, nextxch_mail_spam_total, nextxch_auth_failures_total, nextxch_mail_spam_rate_percent, nextxch_queue_messages, nextxch_queue_deferred_messages, nextxch_queue_oldest_age_minutes, nextxch_connections_active{protocol}, nextxch_process_cpu_percent, nextxch_process_working_set_bytes, nextxch_disk_free_percent, nextxch_disk_free_bytes, nextxch_database_size_bytes, nextxch_tls_certificate_min_expiry_days, nextxch_tls_certificate_expiry_days{domain}, nextxch_cluster_nodes_active, nextxch_alerts_firing, nextxch_smtp_filter_verdicts_total{type,verdict}, nextxch_smtp_filter_failures_total.	`aktiv`	Über OTLP heißen die Instrumente gleich mit Punkten statt Unterstrichen (nextxch.mail.inbound); die Umwandlung nach Prometheus ergibt wieder dieselben Namen.