NexTool Solutions

Zabbix wird zum proaktiven Monitoring, wenn der Alarm keine E-Mail mehr ist, die niemand liest, sondern ein Ticket im GLPI mit Verantwortlichem, Priorität und Kontext. Bei NexTool läuft Zabbix nicht isoliert: Es steht neben dem GLPI, das wir für den Kunden bereits betreiben, und jeder relevante Trigger ist von Anfang an mit einem Reaktionsablauf verknüpft. Dieser Beitrag zeigt, wie wir dieses Duo einführen und betreiben - von der Architektur über den echten Trigger bis zur Integration mit dem Modul Automations von NexTool.

Architektur: Zabbix neben GLPI, nicht in Konkurrenz dazu

Der klassische Fehler ist, Zabbix und GLPI als getrennte Welten zu behandeln: Zabbix schlägt Alarm, jemand sieht es und erstellt das Ticket von Hand. Das fügt zwischen Erkennung und Aktion Minuten (oder Stunden) hinzu und setzt voraus, dass ein Mensch gerade auf das Dashboard schaut. In unserer Implementierung läuft der Zabbix Server als Container neben dem Stack des Kunden, mit dem Zabbix Agent 2 auf den überwachten Hosts. Der Integrationspunkt ist der Webhook-Media Type von Zabbix, der einen POST an den zustandslosen Endpoint des Moduls Automations von NexTool auslöst - und Automations erstellt das Ticket im GLPI, mit HMAC-SHA-256-Authentifizierung pro Ablauf.

Diese Rollentrennung ist wichtig: Zabbix entscheidet, was ein Signal ist, das eine Aktion verdient (der Trigger); Automations entscheidet, wie daraus Arbeit im Service Desk wird (Kategorie, Einheit, Dringlichkeit, Techniker). Das eine auszutauschen, ohne das andere anzufassen, wird trivial.

Trigger, die zählen: Zeitfenster und Recovery statt isolierter Spitzen

Im Betrieb ist die Hauptursache dafür, dass „alle Zabbix stummschalten“, das Flapping: Eine CPU-Spitze von 2 Sekunden löst den Alarm aus und hebt ihn dutzende Male pro Stunde wieder auf. Die Abwehr ist zweifach - über ein Zeitfenster auswerten und eine separate Recovery-Expression (Hysterese) verwenden, damit das Problem erst geschlossen wird, wenn es sich wirklich stabilisiert hat. Ein Trigger für eine volllaufende Festplatte, der den Ausfall vorhersagen soll, bevor er eintritt, sieht so aus:

# Trigger: filesystem raiz vai encher nas proximas 24h (previsao, nao reacao)
# name: "Disco {HOST.NAME}: previsao de saturacao de / em 24h"
timeleft(/Linux by Zabbix agent/vfs.fs.size[/,pfree],1h,0)<24h
  and
last(/Linux by Zabbix agent/vfs.fs.size[/,pused])>80

# Trigger com histerese (recovery diferente do problema) para evitar flapping de CPU
# Problem  expression:
avg(/Linux by Zabbix agent/system.cpu.util,5m)>90
# Recovery expression (so limpa quando cair de verdade):
avg(/Linux by Zabbix agent/system.cpu.util,5m)<70

Die Funktion timeleft() ist das Herzstück des „Proaktiven“: Sie projiziert anhand des Trends, wie viel Zeit bleibt, bis die Festplatte voll ist - und alarmiert, solange noch gehandelt werden kann, nicht erst, wenn der Dienst bereits ausgefallen ist. Der häufige Fehler ist hier, last() auf einen Wert von 95 % Belegung anzuwenden und das proaktiv zu nennen; das ist es nicht, sondern reaktiv mit einem großzügigeren Schwellenwert.

Templates und Makros: Konsistenz zwischen Hosts

Wir standardisieren Server, Netzwerk und Anwendungen über verknüpfte Templates, wobei die Schwellenwerte als Makros bereitgestellt werden ({$CPU.UTIL.CRIT}, {$VFS.FS.PUSED.MAX.CRIT}). So erhält ein Host, der berechtigterweise mit hoher Auslastung lebt (zum Beispiel eine Datenbank), einen Override des Makros direkt am Host, ohne den Trigger zu duplizieren oder den Standard der übrigen 200 Hosts zu brechen. Das beschleunigt das Onboarding neuer Hosts und verhindert die schleichende Abweichung, die jedes ausgereifte Monitoring zersetzt.

Integration mit GLPI: der Webhook, der zum Ticket wird

Der Webhook-Media Type von Zabbix ist ein JavaScript-Skript, das die Payload zusammenstellt und den POST ausführt. Was wir an Automations senden, enthält genug, damit das Ticket mit Kontext entsteht - Schweregrad, Host, Item, Wert und die {EVENT.ID}, die wir als Idempotenzschlüssel verwenden, damit für dasselbe Ereignis nicht zwei Tickets erstellt werden:

// Zabbix media type (webhook) -> Automacoes NexTool -> GLPI
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
req.addHeader('X-Signature: ' + hmacSha256(params.payload, params.secret));

var payload = JSON.stringify({
  evento_id:  '{EVENT.ID}',        // chave de idempotencia
  severidade: '{EVENT.SEVERITY}',  // mapeada para urgencia GLPI
  host:       '{HOST.NAME}',
  gatilho:    '{TRIGGER.NAME}',
  valor:      '{ITEM.VALUE}',
  status:     '{EVENT.VALUE}'      // 1=problema, 0=recuperado
});

var resp = req.post('https://glpi.cliente.com/automacoes/hook/zabbix', payload);
return JSON.stringify({ tags: [{ tag: '__glpi_ticket', value: resp }] });

Auf der GLPI-Seite ordnet der Ablauf in Automations den Schweregrad von Zabbix der Dringlichkeit des Tickets zu, wählt die richtige Kategorie und Einheit und weist das Ticket der zuständigen Technikergruppe zu. Wenn sich das Ereignis erholt (status: 0), kann derselbe Ablauf eine Folgeaktion „automatisch gelöst“ hinzufügen oder das Ticket schließen - und damit den Zyklus Erkennung -> Aktion -> Lösung ohne manuelles Eingreifen schließen.

Reaktiv vs. proaktiv in der Praxis

Häufige Fehler, die wir im Betrieb korrigieren

• Keine Recovery-Expression: Problem und Erholung verwenden dieselbe Bedingung, der Alarm blinkt. Definieren Sie bei volatilen Metriken (CPU, Latenz) immer eine Hysterese.
• Schweregrad ohne Zuordnung: Alles kommt im GLPI als „mittel“ an. Ordnen Sie Disaster/High einer hohen Dringlichkeit zu und lassen Sie Information nur im Dashboard, ohne Ticket.
• Keine Idempotenz: Wiederholungsversuche des Webhooks erzeugen doppelte Tickets. Die Verwendung von {EVENT.ID} als Schlüssel löst das.
• Alarm ohne Verantwortlichen: Ein Trigger, der auf keine Gruppe und keinen Techniker verweist, ist Rauschen. Jeder handlungsrelevante Alarm braucht einen Zuweisungsweg im Ablauf von Automations.

Wenn Sie bereits GLPI haben und möchten, dass Zabbix keine ignorierten E-Mails mehr erzeugt, sondern Tickets mit Verantwortlichem und Kontext, dann ist genau diese Einführungs- und Betriebsarbeit das, was NexTool liefert - vom Template bis zum Integrationsablauf. Sprechen Sie mit uns über Support und Betrieb Ihrer Umgebung aus GLPI + Monitoring.

Geprüft vom Team von NexTool Solutions.