Unser Juli-Update bringt neue Funktionen für die E-Mail- und WebHook-APIs. Sie können jetzt Alerts in SIGNL4 schließen, wenn das Problem in Ihrem Backend-System gelöst wurde.

Anwendungsbeispiel

Ein typischer Anwendungsfall ist das IT-Monitoring und die automatische Wiederherstellung. Stellen Sie sich vor, Sie erhalten mitten in der Nacht einen Alarm wegen eines IT-Problems. Ein Dienst ist ausgefallen. Sie haben jedoch einen automatischen Wiederherstellungs-Mechanismus konfiguriert und der Server wird automatisch neu gestartet. Nach einer Weile erkennt das Monitoring-Tool, dass das Problem gelöst ist. Sie können diese Informationen nun einfach und automatisch per E-Mail oder Webhook an SIGNL4 weiterleiten, um den Alert in der App zu schließen. Wenn Sie sich also die SIGNL4-App ansehen, sehen Sie, dass das Problem bereits durch das Backend-System gelöst wurde und Sie können Ihren Schlaf fortsetzen.

Wie funktioniert es?

Der neue X-S4-Status Parameter

Benutzerdefinierte Parameter

Manchmal sind die Backend-Systeme begrenzt und erlauben es nicht, den Alarm-Text zu ändern. In diesem Fall können Sie festlegen, wo Sie die „Externe ID“ und den „Status“ als Teil Ihrer Webhook-URL finden.

In diesem Fall ist es nicht notwendig, den Code in Ihrem Backend-System zu ändern. Sie müssen nur die Webhook-URL anpassen.

Für die Webhook-URL sieht dies wie folgt aus:

https://connect.signl4.com/webhook/<team-secret>?ExtIDParam=Trigger_Id&ExtStatusParam=Trigger_Status&ResolvedStatus=RESOLVED

Wie Sie sehen, gibt es einige zusätzliche Parameter:

ExtIDParam: Der Name einer eindeutigen ID Ihres Alarms.

ExtStatusParam: Der Name des Status-Parameters.

ResolvedStatus: Der Wert, der angibt, dass ein Alarm geschlossen wurde.

NewStatus: Optionaler Wert, für den ein neuer Alert geöffnet werden soll. Wenn dieser gesetzt ist und der Wert von ExtStatusParam weder der in NewStatus noch der in ResolvedStatus angegebene ist, wird das Ereignis verworfen. Dies ist nützlich, wenn es Updates gibt, die Sie ignorieren möchten.