Zabbix Telegram-Benachrichtigung einrichten: Alarm aufs Handy in 15 Minuten

Monitoring ohne Benachrichtigung ist ein Dashboard, das niemand anschaut. Der Server aus Teil 2 weiß jetzt, wenn eine Platte voll läuft, aber er sagt es niemandem. Das ändern wir. Telegram ist dafür der angenehmste Weg: kostenlos, sofort auf dem Handy, und in Zabbix mit Bordmitteln eingebaut.

Wie Benachrichtigungen in Zabbix funktionieren

Drei Bausteine, und man muss alle drei kennen, sonst versteht man nicht, warum nichts ankommt:

1. Media Type ist der Kanal: E-Mail, Telegram, Slack, ein Skript. Hier steht das Wie.
2. User Media ist die Adresse eines Benutzers auf diesem Kanal: die Telegram-Chat-ID, die Mailadresse. Hier steht das Wohin.
3. Action ist die Regel: Wenn ein Problem mit Schweregrad X auftritt, schicke eine Nachricht über Kanal Y an Benutzer Z. Hier steht das Wann.

Fehlt einer der drei, passiert nichts. Und zwar still, ohne Fehlermeldung.

Schritt 1: Telegram-Bot anlegen

In Telegram den Kontakt @BotFather öffnen und /newbot schreiben. Er fragt nach einem Anzeigenamen und einem Benutzernamen, der auf bot enden muss. Am Ende bekommt man einen Token in der Form 123456789:AAH.... Den Token sicher aufbewahren, er ist das Passwort des Bots.

Dem neuen Bot einmal eine Nachricht schreiben, irgendwas, damit er den Chat kennt. Dann die Chat-ID ermitteln:

curl -s https://api.telegram.org/bot<TOKEN>/getUpdates | python3 -m json.tool | grep -A2 '"chat"'

Die Zahl hinter "id" ist die Chat-ID. Für eine Gruppe den Bot in die Gruppe einladen, dort schreiben, und die ID beginnt mit einem Minus.

Ich nutze einen Bot, den ich schon für andere Benachrichtigungen hatte. Ein Bot kann beliebig viele Dienste bedienen, man muss nur mit den Chat-IDs unterscheiden.

Schritt 2: Media Type konfigurieren

Zabbix liefert den Telegram-Webhook fertig mit. Unter Alerts → Media types den Eintrag „Telegram“ öffnen.

Zwei Parameter anpassen:

• api_token: der Token vom BotFather
• api_parse_mode: leer lassen oder Markdown

Dann oben „Enabled“ setzen. Die anderen Parameter bleiben auf ihren Standardwerten, sie werden von Zabbix beim Versand gefüllt.

Jetzt die Falle, in die ich selbst getappt bin, weil ich die Parameter per API gesetzt habe und mich an ältere Anleitungen gehalten habe: In Zabbix 7.4 heißen die Parameter api_token, api_chat_id, api_parse_mode, alert_message und alert_subject. In älteren Versionen hießen sie Token, To, ParseMode, Message, Subject. Wer die alten Namen setzt, bekommt keinen Fehler, aber auch keine Nachricht. Das Webhook-Skript liest einfach leere Werte. Wer im Frontend klickt, sieht die richtigen Namen und ist auf der sicheren Seite.

Ein Klick auf „Test“ neben dem Media Type schickt eine Probenachricht. Dort die Chat-ID als Empfänger eintragen. Kommt sie an, ist der schwierigste Teil erledigt.

Schritt 3: Medium beim Benutzer hinterlegen

Users → Users → Admin → Reiter Media → Add:

• Type: Telegram
• Send to: die Chat-ID
• When active: 1-7,00:00-24:00
• Use if severity: hier kann man schon filtern, ich lasse alles an und filtere in der Action

Wer mehrere Leute benachrichtigen will, legt pro Person ein Medium an oder eine Gruppe mit einer gemeinsamen Chat-ID.

Schritt 4: Action anlegen

Alerts → Actions → Trigger actions → Create action.

Conditions: Ich hatte zuerst „Trigger severity is greater than or equals Warning“ eingestellt. Danach wurde ich von Meldungen regelrecht überflutet, jedes Mal, wenn irgendwo der RAM bei 80 bis 90 Prozent lag. Deshalb habe ich es auf High gesetzt. Warnungen sehe ich im Dashboard, aufs Handy kommt nur, was wirklich wichtig ist: Host down, Dienst tot, Website nicht erreichbar, Zertifikat läuft in einer Woche ab. Das ist die wichtigste Entscheidung in diesem ganzen Artikel. Wer zu viel schickt, ignoriert nach einer Woche alles.

Operations: Send message to users → Admin, via Telegram. Ich nutze die Standardnachricht, sie enthält Host, Problem, Schweregrad und Zeit.

Recovery operations: Dieselbe Nachricht. Man will wissen, wenn es vorbei ist.

Update operations: Ebenfalls. Wenn jemand das Problem im Frontend bestätigt, kommt eine Nachricht. In einem Team wichtig, allein eher nicht.

Speichern. Fertig ist die Grundkonfiguration.

Schritt 5: Ein echter Test

Der Test-Button im Media Type prüft nur den Kanal, nicht die Action. Ein echter Test braucht ein echtes Problem. Der schnellste Weg: Auf irgendeinem Host den Agent stoppen.

sudo systemctl stop zabbix-agent2

Das Linux-Template hat einen Trigger „Zabbix agent is not available (for 3m)“ mit Schweregrad Average. Mit meiner High-Einstellung käme der nicht an, also für den Test die Action vorübergehend auf Average stellen. Nach drei Minuten kommt die Nachricht. Agent wieder starten, nach einer weiteren Minute kommt die Entwarnung.

Bei mir sah das so aus:

Problem: Linux: Zabbix agent is not available (for 3m)
Problem started at 10:58:26 on 2026.10.13
Host: Zabbix server
Severity: Average

Und zwei Minuten später:

Resolved in 2m 0s: Linux: Zabbix agent is not available (for 3m)

Unter Reports → Action log sieht man jede versendete Nachricht mit Status. Steht dort „Failed“, liegt der Fehlertext daneben. Meistens ist es eine falsche Chat-ID oder der Bot wurde noch nie angeschrieben.

Eskalation: Erst Telegram, dann Mail, dann Anruf

Die Action kann mehrere Stufen haben. Unter Operations das Feld „Steps“ nutzen:

• Schritt 1, sofort: Telegram
• Schritt 2, nach 30 Minuten ohne Bestätigung: E-Mail an eine zweite Adresse
• Schritt 3, nach 2 Stunden: ein Anruf über einen SMS-Dienst oder PagerDuty

Die Zeit zwischen den Schritten steuert „Default operation step duration“ oben in der Action. Wer das Problem im Frontend bestätigt (Acknowledge), stoppt die Eskalation. Für ein Homelab reicht meistens Schritt 1, aber die Möglichkeit ist da.

Wartungsfenster

Wer nachts Updates einspielt, will keine zehn Nachrichten über neu gestartete Dienste. Unter Data collection → Maintenance ein Wartungsfenster für die betroffenen Hosts anlegen, mit „No data collection“ oder nur „With data collection, no alerts“. Während des Fensters sind die Trigger stumm.

Rauschen reduzieren

Nach der ersten Woche mit Zabbix hat man ein Gefühl dafür, was zu oft meldet. Meine Liste:

• „Zabbix agent2 has been restarted“ nach jedem Agent-Update. Severity Information, stört nur im Dashboard.
• „Number of installed packages has been changed“ nach jedem apt upgrade. Kann man im Template deaktivieren.
• „High memory utilization“ auf Proxmox-Hosts. Dort ist RAM-Auslastung von 90 Prozent normal, wenn ZFS den ARC füllt. Makro {$MEMORY.UTIL.MAX} pro Host hochsetzen oder prüfen, ob die VMs wirklich überbucht sind. Bei mir war es wirklich überbucht.
• „High error rate“ auf WLAN-Interfaces von Access Points. WLAN hat Fehler, das ist normal. Makro {$IF.ERRORS.WARN} auf einen hohen Wert setzen.
• Bind-Mounts in Docker-Containern als „Space is low“. Siehe Agent-Artikel.

Die Regel: Jede Meldung, die man dreimal weggeklickt hat, ohne etwas zu tun, muss weg. Entweder Schwellwert anpassen, Trigger deaktivieren oder Schweregrad senken, damit sie nicht mehr auf dem Handy landet.

Alternative Kanäle

Alles, was oben steht, funktioniert genauso mit Signal (über signal-cli als Skript), Slack, Discord, Mattermost, Pushover oder E-Mail. Die Webhooks sind bei Zabbix mitgeliefert, man braucht nur die jeweiligen Zugangsdaten. E-Mail würde ich zusätzlich einrichten, falls Telegram einmal nicht erreichbar ist.

Und ein letzter Punkt, den jedes Monitoring hat: Wenn Zabbix selbst stirbt, schickt es keine Nachricht. Dafür braucht man einen Totmann-Schalter von außen. Ein Uptime Kuma auf einer anderen Maschine, das https://zabbix.example.de prüft, oder ein Dienst wie healthchecks.io, den Zabbix alle paar Minuten anpingt. Bleibt der Ping aus, meldet der Dienst sich. Das kommt in einem späteren Teil.

Weiter geht es

Benachrichtigungen laufen. Jetzt wird es sichtbar: Im nächsten Teil bauen wir ein Dashboard, das alle Standorte, Server, Netzwerkgeräte und Websites auf einer Seite zeigt.