Zabbix: Trigger, Benachrichtigungen und Microsoft Teams

Aus maxTechCorner
(Weitergeleitet von Zabbix Benachrichtigung)

Auf einen Blick

Gilt fürZabbix 7.0 LTS bzw. 7.4; Trigger, Abhängigkeiten, Aktionen mit Eskalation, Medientypen E-Mail (7.4 auch mit OAuth 2.0 für Microsoft 365) und „MS Teams Workflows“, Wartungszeiten
BereichServer-Software
DauerGrundeinrichtung ca. 1–2 Stunden
RechteZabbix-Administrator bzw. Superadministrator; in Microsoft Teams Recht zum Anlegen von Workflows
StandOktober 2026

Trigger und Benachrichtigungen in Zabbix entscheiden, ob das Monitoring im Alltag hilft oder nur Lärm erzeugt: Trigger bewerten Messwerte und erzeugen Probleme mit Schweregrad, Aktionen schicken Nachrichten an die richtigen Personen und eskalieren, wenn niemand reagiert. Diese Anleitung erklärt Trigger-Ausdrücke, Schweregrade und Abhängigkeiten, die Einrichtung von E-Mail und Microsoft Teams, Eskalationsstufen, Wartungszeiten und Regeln gegen Alarmflut.

Benachrichtigungen in Zabbix: Item liefert Werte, Trigger mit Ausdruck wie avg über 5 Minuten größer 90 erzeugt Problem mit Schweregrad Information, Warnung, Durchschnitt, Hoch oder Katastrophe; Abhängigkeiten unterdrücken Folgealarme hinter einem ausgefallenen Router; Trigger-Aktion mit Bedingungen (Hostgruppe, Schweregrad, Tags) und Eskalation: sofort Teams-Kanal, nach 30 Minuten E-Mail an Bereitschaft, nach 2 Stunden Leitung; Medientypen E-Mail (OAuth für Microsoft 365 ab 7.4) und MS Teams Workflows; Bestätigen, Unterdrücken, Wartungszeiten für geplante Arbeiten.

Zabbix-Trigger verstehen

Ein Trigger prüft einen Ausdruck über Item-Werte und wechselt zwischen OK und Problem. Beispiele (Syntax seit Zabbix 5.4):

CPU dauerhaft hoch:     avg(/srv-web01/system.cpu.util,15m)>90
Platz unter 10 %:       last(/srv-file01/vfs.fs.dependent.size[/,pused])>90
Agent meldet sich nicht: nodata(/srv-web01/agent.ping,5m)=1
Dienst gestoppt:        last(/dc01/service.info["DNS",state])<>0
  • Die mitgelieferten Vorlagen enthalten fertige Trigger; Schwellen über Makros anpassen statt die Trigger zu ändern.
  • Erholungsausdruck (Recovery expression): Problem erst beenden, wenn ein zweiter Wert unterschritten ist – verhindert Flattern.
  • Schweregrade: Not classified, Information, Warning, Average, High, Disaster. Für das Unternehmen festlegen, was welche Stufe bedeutet, z. B. Disaster = Ausfall eines geschäftskritischen Dienstes.
  • Tags an Triggern (z. B. team:netzwerk, dienst:erp) steuern später die Zustellung.

Abhängigkeiten gegen Folgealarme

Fällt der Router einer Außenstelle aus, melden sonst alle Geräte dahinter einen Ausfall. Mit Trigger-Abhängigkeiten („hängt ab von: Router Hamburg nicht erreichbar“) zeigt Zabbix nur das Ursprungsproblem. Abhängigkeiten am besten in Vorlagen bzw. per Massenänderung für ganze Hostgruppen setzen.

Schritt 1: Medientypen einrichten

Alerts › Media types:

  • E-Mail: SMTP-Server, Absender, Verschlüsselung (STARTTLS, Port 587). Seit Zabbix 7.4 unterstützt der E-Mail-Medientyp OAuth 2.0 mit vereinfachter Einrichtung für Office365 und Gmail – wichtig, weil Microsoft die Anmeldung mit Benutzername und Passwort für SMTP abschaltet. Unter 7.0 einen internen Mail-Relay bzw. SMTP-Dienst nutzen.
  • MS Teams Workflows (vorkonfigurierter Webhook):
    1. In Teams im gewünschten Kanal einen Workflow aus der Vorlage „Post to a channel when a webhook request is received“ anlegen und die URL kopieren.
    2. Den Medientyp MS Teams Workflows aktivieren, Parameter wie zabbix_url setzen und bei den Benutzern bzw. einem eigenen Benachrichtigungsbenutzer die Workflow-URL als Send to eintragen.
    3. Mit Test prüfen. Die älteren Office-365-Connectors in Teams werden von Microsoft nicht mehr unterstützt.
  • Weitere fertige Webhooks: Telegram, Slack, Mattermost, Jira, GLPI, Zammad, OTRS, TOPdesk, ServiceNow, PagerDuty, Opsgenie, SIGNL4 u. a.
  • Frontend-URL unter Administration › General › Other setzen – sonst fehlen Links in den Nachrichten.

Schritt 2: Medien bei Benutzern

Unter Users › Users › Media bzw. in den eigenen Benutzereinstellungen: Ziel (Mailadresse, Teams-URL), Zeitraum (z. B. Werktage 7–18 Uhr) und Schweregrade, für die das Medium gilt. Für Teams-Kanäle einen eigenen technischen Benutzer „Teams IT-Alarme“ mit Leserechten auf die betreffenden Hostgruppen anlegen. Seit 7.4 dürfen alle Benutzer ihre eigenen Medien standardmäßig verwalten; die Berechtigung lässt sich über Rollen steuern.

Schritt 3: Aktion mit Eskalation

Alerts › Actions › Trigger actions › Create action:

  • Bedingungen: z. B. Host group = Server, Trigger severity ≥ Average, Problem is suppressed = no.
  • Operationen mit Eskalationsstufen (Standarddauer z. B. 30 Minuten):
Stufe Zeitpunkt Empfänger
1 sofort Teams-Kanal „IT-Alarme“ (Benutzer „Teams IT-Alarme“)
2 nach 30 Minuten, falls nicht bestätigt E-Mail an Gruppe Bereitschaft
3 nach 2 Stunden E-Mail an IT-Leitung
  • Wiederherstellungs-Operationen melden, wenn das Problem behoben ist; Aktualisierungs-Operationen, wenn jemand bestätigt oder kommentiert.
  • Mit Pause operations for suppressed problems bzw. der Bedingung „nur unbestätigte Probleme“ stoppt die Eskalation, sobald jemand das Problem bestätigt (Acknowledge).
  • Nachrichtentexte nutzen Makros wie {HOST.NAME}, {EVENT.NAME}, {EVENT.SEVERITY}, {EVENT.TAGS}.

Schritt 4: Wartungszeiten

Data collection › Maintenance: geplante Arbeiten (Patchday, Umbau) für Hosts oder Hostgruppen eintragen – einmalig oder wiederkehrend.

  • With data collection: Daten werden weiter erfasst, Benachrichtigungen unterdrückt.
  • No data collection: keine Erfassung (z. B. bei Abschaltung).
  • Spontan lassen sich einzelne Probleme auch unterdrücken (Suppress) – mit Ablaufzeit.

Regeln gegen Alarmflut

  • Nur handlungsrelevante Probleme benachrichtigen: Information und Warnung meist nur im Dashboard, ab Average bzw. High benachrichtigen.
  • Abhängigkeiten pflegen – besonders für Standorte hinter einem Router oder VPN.
  • Vorlagen gezielt kürzen: nicht genutzte Discovery-Regeln deaktivieren, Schwellen per Makro anpassen.
  • Regelmäßige Auswertung: Reports › Top 100 triggers zeigt die häufigsten Auslöser – Kandidaten zum Anpassen.
  • Zabbix selbst überwachen: Ein externer Dienst bzw. ein zweites System prüft, ob Zabbix läuft und Nachrichten verschicken kann.

Hinweise

  • Ereigniskorrelation: Globale Korrelationsregeln können zusammengehörige Ereignisse schließen; Zabbix 8.0 LTS soll eine erweiterte Korrelation mitbringen.
  • Grafana: Wer Alarme zentral in Grafana verwalten will, siehe Grafana: Alerting mit E-Mail, Microsoft Teams und Webhooks; meist ist es sinnvoller, die Alarmierung in Zabbix zu belassen.
  • Bei Alarmierungskonzepten, Bereitschaft und überwachtem Betrieb unterstützt Sie das Managed SIEM von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen