# Alarme, gesendete Alarme und Logs

# 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:

- Zeitraum
- Pager (Seriennummer)
- Status
- RIC

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

- **Pager-UID** (14 Ziffern)
- **Remote-IP**
- **Befehl** (z.B. nur Keep-Alives oder nur Notrufe filtern)

## 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.