NexTool Solutions

Ein Alarm, der nur per E-Mail ankommt, ist eine Störung ohne Verantwortlichen. Die Integration zwischen Zabbix und GLPI dient dazu, jedes erkannte Problem in ein nachverfolgbares Ticket zu verwandeln, mit Nummer, Verantwortlichem, Kategorie, Priorität und SLA, und es selbstständig zu schließen, wenn Zabbix die Wiederherstellung bestätigt. Ein Geheimnis liegt nicht darin, „ein Ticket zu erstellen“, sondern darin, keine vierzig zu erstellen.

Was die Integration leisten muss

Eine Brücke von Zabbix zu GLPI, die in Produktion trägt, braucht vier Garantien, nicht nur „ein Ticket posten“:

• Idempotenz: Ein Problem erzeugt ein Ticket, nicht eines pro Eskalationsschritt.
• Korrelation von Problem und Wiederherstellung: Ein Recovery-Ereignis muss genau jenes Ticket finden und schließen, welches eröffnet wurde.
• Zuordnung der Schweregrade: Der Schweregrad aus Zabbix wird einheitlich zur Priorität in GLPI, ohne dem Ermessen jedes Analysten überlassen zu sein.
• Ausreichender Kontext: Host, IP, Trigger, Uhrzeit und Meldung im Text, damit ein Analyst handeln kann, ohne Zabbix öffnen zu müssen.

Architektur: wo der Webhook zum Ticket wird

Zabbix löst über eine Action aus; die Action führt eine Medienoperation vom Typ Webhook aus; der Webhook ist ein natives JavaScript-Skript von Zabbix, welches einen POST an einen Endpunkt auf der Seite von GLPI sendet. Auf der Seite von GLPI verwenden wir den Receiver des Moduls Automations, der die HMAC-Signatur prüft, die Feldzuordnung anwendet und ein Ticket erstellt (oder schließt). Wir vermeiden es, die REST-API von GLPI direkt aus Zabbix aufzurufen, weil jeder Aufruf ein Paar aus app-token/user-token und ein Paar initSession/killSession erfordern würde; bei einem Alarmsturm hämmert dies auf die API ein und erschöpft zudem die Sitzungen.

Artefakt: Webhook-Media-Type von Zabbix

Die Parameter bilden Makros des Ereignisses ab; ein Skript baut den Payload und behandelt den HTTP-Code. Problem und Wiederherstellung verwenden denselben Media Type; Feld event_value unterscheidet sie (1 = Problem, 0 = Wiederherstellung):

// Zabbix -> Media type -> Webhook -> Parameters
// endpoint     = https://glpi.customer.com/plugins/nextool/automations/webhook/zabbix
// event_id     = {EVENT.ID}        // stable across the problem/recovery pair
// event_value  = {EVENT.VALUE}     // 1 = problem, 0 = recovery
// host_name    = {HOST.NAME}
// host_ip      = {HOST.IP}
// trigger_name = {TRIGGER.NAME}
// severity     = {TRIGGER.SEVERITY}
// occurred     = {EVENT.DATE} {EVENT.TIME}
// message      = {ALERT.MESSAGE}
// hmac         = {$NEXTOOL_HMAC}    // secret macro, never in the alert body

var p = JSON.parse(value);
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
req.addHeader('X-Nextool-Signature: ' + p.hmac);

var payload = JSON.stringify({
    event_id: p.event_id,
    recovery: p.event_value === '0',
    host:     p.host_name,
    host_ip:  p.host_ip,
    trigger:  p.trigger_name,
    severity: p.severity,
    occurred: p.occurred,
    message:  p.message
});

var resp = req.post(p.endpoint, payload);
var code = req.getStatus();
if (code < 200 || code >= 300) {
    Zabbix.log(3, '[nextool] HTTP failure ' + code + ': ' + resp);
    throw 'Send to GLPI failed: HTTP ' + code;
}
return resp;

Zuordnung der Schweregrade von Zabbix zur Priorität in GLPI

Zabbix hat sechs Schweregrade, GLPI fünf Prioritäten. Wir legen die Zuordnung im Receiver fest, um sie nicht dem Ermessen jedes Analysten zu überlassen:

Deduplizierung und automatisches Schließen

An diesem Punkt trennt sich eine Spielzeug-Integration von einer, die Produktion aushält. Beim Erstellen eines Tickets speichert der Receiver die tickets_id aus GLPI als Tag des Ereignisses in Zabbix (oder in einer nach event_id indizierten Korrelationstabelle). Wenn Zabbix das Recovery mit derselben event_id sendet, findet der Receiver jenes Ticket und fügt eine Folgeaktion zur Wiederherstellung hinzu oder schließt es, je nach Richtlinie des Kunden. Ohne diesen Schlüssel weiß ein Recovery nicht, welches Ticket es schließen soll, und es sammeln sich offene Tickets zu bereits gelösten Problemen an.

Häufige Fehler, die wir im Betrieb korrigieren

Im Betrieb ist die häufigste Störung nicht der Alarm, der nicht zum Ticket wird, sondern der Alarm, der zu vierzig wird. Eine flappende Schnittstelle um 3 Uhr morgens erzeugte Dutzende identische Tickets, weil die Action bei jedem Eskalationsschritt auslöste und der Receiver nicht deduplizierte. Die Korrektur hat zwei Seiten: in Zabbix Trigger-Abhängigkeit, Hysterese im Recovery-Ausdruck und eine Medienoperation nur im ersten Schritt; in GLPI Idempotenz per event_id. Zwei weitere wiederkehrende Fehler: die Kategorie eines Tickets als Freitext zu senden (GLPI erwartet eine numerische itilcategories_id; ein neuer Text passt nicht, und ein Ticket landet ohne Kategorie) und ein HMAC-Secret in den Text des Alarms zu schreiben statt in ein geschütztes Makro wie {$NEXTOOL_HMAC}.

Integrationsmethoden im Vergleich

Wenn Ihr Betrieb bereits Zabbix nutzt, die Alarme aber in einem Postfach versanden, welches niemand liest, setzt NexTool diese Brücke mit Modul Automations um und hält die Regeln im Betrieb fein abgestimmt: Trigger, Zuordnung der Schweregrade und Richtlinie für das Schließen. Lernen Sie das Modul Automations kennen.

Geprüft vom Team von NexTool Solutions.