Alarme, gesendete Alarme und Logs

Die drei Ansichten Alarme, Gesendete Alarme und Logs sind Ihre wichtigsten Werkzeuge zur Nachverfolgung des Alarmflusses. Jede Ansicht zeigt einen anderen Blickwinkel auf die gleiche Kette.

Menüpunkt „Alarme"

Die Seite Alarme zeigt alle eingegangenen Alarm-Trigger – sowohl DIVERA-Webhooks als auch Pager-seitige Notruf-Ereignisse (MANDOWN, NOTRUF, TEAROFF).

Tabelle

Für jeden Eintrag sehen Sie:

Empfangen um – Zeitstempel der Einlieferung beim Broker
Quelle – „DIVERA" oder „Pager"
Titel – z.B. der Einsatzstichwort von DIVERA oder „NOTRUF"
Text – Alarmtext / Kurzbeschreibung
Adresse – Ort des Einsatzes (wenn verfügbar)
Instance – DIVERA-Instanz oder Pager-UID
Gerouted an – Anzahl der Pager, an die dieser Alarm weitergeleitet wurde

Filter

Oben finden Sie Filter nach:

Zeitraum (Start/Ende)
Quelle (DIVERA oder Pager)

Die Ansicht ist auf 500 Einträge je Abfrage begrenzt. Ältere Einträge bleiben in der Datenbank, werden aber nicht automatisch geladen.

Detail-Ansicht

Klicken Sie einen Alarm an, öffnet sich die Detail-Seite mit dem vollständigen JSON-Payload (bei DIVERA) und einer Liste aller Pager, an die dieser Alarm routed wurde. Pro Pager sehen Sie: Status (sent/failed/retry_pending), Zeitpunkt, RIC, eventuelle Fehlermeldung.

Menüpunkt „Gesendete Alarme"

Während Alarme das „Ein"-Kommen zeigt, ist Gesendete Alarme das „Aus"-Gehen zu den Pagern. Jede einzelne Pager-Nachricht erzeugt genau einen Eintrag hier.

Tabelle

Erstellt / Gesendet – Erstellungszeit in der Queue und tatsächliche Versandzeit
Pager – Seriennummer und Bezeichnung
RIC – Ziel-RIC (oder leer bei Nur-Text)
Status – queued, sent, failed, retry_pending, cancelled
Retry-Zähler – wie viele Versuche bereits unternommen wurden (0 bis 60)
Fehler – die letzte Fehlermeldung (wenn failed oder retry_pending)

Status-Bedeutungen

queued
Frisch in der Queue, noch nicht versendet. Normalerweise sehr kurz (unter einer Sekunde).

sent
Erfolgreich an den Pager übergeben. Bei TCP: TCP-Ack vom Pager erhalten. Bei MQTT: Mosquitto hat den Publish bestätigt – der Pager war zu dem Zeitpunkt online.

retry_pending
Die Zustellung ist beim aktuellen Versuch fehlgeschlagen. In next_retry_at steht, wann der nächste Versuch gemacht wird (meist in 1 Minute). retry_count wird hochgezählt.

failed
Nach 60 erfolglosen Versuchen (also ca. 1 Stunde lang) wurde endgültig aufgegeben. last_error enthält den Grund des letzten Fehlschlags.

cancelled
Der Alarm wurde manuell abgebrochen. Kommt selten vor.

Filter und Suche

Sie können filtern nach:

Zusätzlich gibt es ein freies Suchfeld, das über alle Textfelder läuft.

Warum „sent" nicht automatisch „angekommen" bedeutet

Eine subtile, aber wichtige Eigenheit: Bei MQTT-Pagern bestätigt der Mosquitto-Broker den Publish, sobald die Nachricht bei ihm liegt. Ob der Pager sie dann tatsächlich empfängt, hängt davon ab, ob er online war. Der Broker hat deshalb eine Zusatzprüfung eingebaut: Bevor er eine MQTT-Nachricht versendet, prüft er pager.last_seen_mqtt. Ist diese älter als 15 Minuten, wird der Versand zurückgestellt (retry_pending mit Fehler „pager_offline_mqtt"). Nur wenn der Pager tatsächlich online ist, wird der Publish ausgeführt.

Bei TCP ist das einfacher: Eine tote TCP-Verbindung erkennt der Kernel schnell (TCP Keep-Alive alle 30 s), und der Broker setzt den Status entsprechend.

Menüpunkt „Logs"

Die Logs-Seite zeigt das Rohprotokoll aller Pager-Kommunikation in Ihrem Mandanten – eingehend und ausgehend, TCP und MQTT.

Ansichten

Im oberen Bereich können Sie zwischen vier Ansichten umschalten:

Eingehend (Inbound)
Alle vom Pager empfangenen Nachrichten (Keep-Alives, Status-Rückmeldungen, Notrufe).

Ausgehend (Outbound)
Alle an Pager gesendeten Nachrichten (Alarme).

DIVERA
Alle DIVERA-API-Aufrufe (Outbound-Status-Meldungen).

System
Anwendungs-Logs des Brokers (nur der Anteil, der Ihren Mandanten betrifft).

Spalten

Pro Eintrag sehen Sie:

Datum / Uhrzeit
Pager-UID (wenn zutreffend)
Befehl (cmd_num und Beschreibung)
Payload (Rohdaten oder JSON)
Verbindungstyp (TCP/MQTT)
Remote-Adresse (IP des Pagers bei TCP)

Auto-Refresh

Oben befindet sich ein Toggle Auto-Refresh mit einstellbarem Intervall (1–30 Sekunden). Aktiviert lädt die Tabelle regelmäßig neu. Das ist nützlich, wenn Sie eine laufende Kommunikation beobachten möchten.

Zeitraum-Filter

Beschränken Sie die Ansicht auf einen Zeitraum, um historische Vorgänge nachzuvollziehen.

Suche und Filter

Gemeinsame Detail-Ansicht

In allen drei Ansichten können Sie einen Eintrag anklicken, um die Detail-Ansicht zu öffnen. Dort sehen Sie:

Vollständigen Rohdaten-Dump (hex, base64 oder JSON)
Details zur Pager-Registrierung
Zeitstempel in verschiedenen Formaten
Verlinkung zu verwandten Einträgen (z.B. von „Gesendeter Alarm" zum auslösenden DIVERA-Alarm)

Praktische Use-Cases

Einen konkreten Einsatz verfolgen
Notieren Sie die DIVERA-Alarm-ID. Öffnen Sie Alarme, filtern Sie nach dieser ID. Klicken Sie den Eintrag an – Sie sehen alle Pager, an die gerouted wurde. Klicken Sie auf einen Pager – Sie landen in Gesendete Alarme und sehen, wie es dort ausging. Von dort können Sie in Logs springen und die tatsächliche Pager-Nachricht sehen.

Problem mit einem konkreten Pager
Öffnen Sie Logs, filtern Sie nach der UID des Pagers. Schalten Sie auf „Eingehend" – sehen Sie, ob der Pager überhaupt Keep-Alives sendet. Schalten Sie auf „Ausgehend" – sehen Sie, welche Alarme in letzter Zeit geschickt wurden und welchen Status sie haben.

Ausfallzeit rekonstruieren
Suchen Sie in Logs → „System" nach Einträgen wie „PANIC", „FATAL", „Connection lost". Das hilft bei der Diagnose, warum zu einer bestimmten Zeit Alarme nicht durchkamen.

Export

Aktuell gibt es keine direkte Export-Funktion in der Mandanten-GUI. Sie können Listen per Copy&Paste aus der Browser-Ansicht entnehmen. Für umfangreichere Exporte (CSV, JSON) wenden Sie sich an den Super-Admin, der Datenbank-Abfragen direkt ausführen kann.

Retention

Einträge in den Log-Tabellen werden aktuell nicht automatisch gelöscht. Die Datenbank wächst also mit der Zeit. Wenn Sie eine dezidierte Aufbewahrungs-Policy benötigen (z.B. „alle Keep-Alives älter als 30 Tage löschen"), sprechen Sie Ihren Super-Admin an. Der Broker unterstützt solche Policies prinzipiell, aber sie sind nicht pro Mandant einstellbar.