Vorgesehene Integrationswege

Die in der Oberfläche eingerichtete Qisutu-Anbindung verwendet die Ereignisschnittstelle des separaten Qisutu-Add-ons. Die Verbindung wird unter Meldungen mit ihrer Ereignisadresse und dem Schlüssel konfiguriert. Ereignisse werden als JSON über HTTPS übertragen; der Zugangsschlüssel wird als Bearer-Token verwendet. Der Verbindungstest ruft die Testadresse der gewählten Verbindung auf und legt kein Ticket an.

Verteilte Messsammler besitzen eine eigene HTTPS-Schnittstelle zur Zentrale. Sie werden unter Einstellungen → Verteilte Messsammler angelegt und anschließend beim Gerät unter Einrichten → Messsammler zugewiesen. Verwenden Sie dafür die Einrichtung der Messsammler; ein Agentenpasswort ersetzt deren Zugangsschlüssel nicht.

Schnittstelle	Zweck	Authentifizierung
GET /api/health am Monitoring-Server	Einfacher Erreichbarkeitstest des Webdienstes; Antwort enthält service: netzmonitor. Dies ist keine Aussage über jedes überwachte Gerät.	Keine Anmeldung erforderlich.
GET /collector/v1/config/{ID}	Zugewiesene Prüfkonfiguration für den Messsammler abrufen.	Bearer-Schlüssel dieses aktiven Messsammlers; HTTPS erforderlich.
POST /collector/v1/results/{ID}	Messergebnisse des Messsammlers übertragen.	Bearer-Schlüssel dieses aktiven Messsammlers; HTTPS erforderlich.
Qisutu-Ereignisadresse aus dem Add-on	Störungen und Entwarnungen vom Monitoring an Qisutu senden.	Bearer-Schlüssel der Qisutu-Verbindung.

Die übrigen /api/-Routen bedienen die angemeldete Monitoring-Oberfläche. Sie verwenden eine Sitzung; Änderungen benötigen zusätzlich den zugehörigen CSRF-Token. Sie werden nicht über den Qisutu-Verbindungsschlüssel freigegeben. In dieser Version gibt es in der Monitoring-Oberfläche keine konfigurierbare allgemeine Webhook-Adresse für andere Ticketsysteme und keine Maske für die Annahme beliebiger externer Monitoring-Ereignisse.