📍 Lecture connexe : Zabbix 7 LTS en 2026 : supervision open-source en production — pour la vue d’ensemble et les arbitrages.
Une supervision sans notifications est un journal de bord muet. Ce qui transforme Zabbix en outil opérationnel, c’est la chaîne complète qui va du trigger à l’astreinte qui reçoit le bon message au bon moment. Ce tutoriel construit cette chaîne : configurer un media type email + Telegram, attacher des utilisateurs à ces médias, créer une action avec étapes d’escalade, et tester chaque chemin avec une alerte volontaire. À la fin, vous saurez aussi éviter le piège classique de l’inondation d’alertes la nuit.
Prérequis
- Une instance Zabbix 7 fonctionnelle avec au moins un hôte supervisé
- Accès à un serveur SMTP relais (Gmail, Mailjet, Sendgrid, Postal self-hosted) ou un compte qui peut envoyer en SMTPS
- Un bot Telegram créé via BotFather et son token (gratuit)
- Niveau attendu : intermédiaire
- Temps estimé : environ 75 minutes
Étape 1 — Comprendre la chaîne notification Zabbix
Quatre objets Zabbix interviennent dans une notification. Le media type définit comment envoyer (SMTP, webhook, script). Le media est l’instance de media type pour un utilisateur (« mon adresse email », « mon ID Telegram »). L’action est la règle qui décide qui notifier sur quel événement. Les opérations de l’action sont les étapes successives (envoyer immédiatement, escalader après 30 min, exécuter un script).
Dans cet ordre : on configure d’abord le media type (le « comment »), puis on attache des médias aux utilisateurs (« à qui »), puis on crée l’action qui orchestre (« quand »).
Étape 2 — Configurer le media type Email
Dans Administration → Media types → Email. Zabbix livre un media type Email préconfiguré ; on l’édite. Type SMTP, SMTP server smtp.gmail.com (ou ton fournisseur), SMTP server port 587, SMTP helo localhost, SMTP email alerting@example.com, Connection security STARTTLS, Authentication Username and password, Username = email d’envoi, Password = mot de passe d’application.
Pour Gmail, il faut activer la 2FA et créer un App Password dédié à Zabbix. Le mot de passe principal du compte ne fonctionne pas en SMTP depuis 2022. Pour un service transactionnel sérieux, on préfère un fournisseur dédié comme Mailjet, Sendgrid ou Postmark, qui offrent un quota gratuit et des taux de délivrabilité bien meilleurs que les comptes Gmail standard.
L’onglet Message templates contient les templates utilisés selon l’événement (Problem, Recovery, Update). Les templates par défaut sont solides, mais on peut les personnaliser pour ajouter des liens cliquables vers Zabbix, des graphes, ou des informations de contexte métier.
Étape 3 — Tester le media type Email
Toujours dans Administration → Media types, on clique sur Test à côté du media type Email. On saisit une adresse de destination, on valide. Zabbix envoie un email de test ; le résultat s’affiche en succès ou en erreur avec le message complet. Cette étape de test est non négociable : 80 % des problèmes de notification se résolvent ici.
Si le test échoue avec « connection refused », c’est le firewall ou les credentials. Si le test passe mais que les vraies alertes n’arrivent pas, c’est probablement que le media n’est pas attaché au bon utilisateur ou que l’action ne le sélectionne pas comme cible.
Étape 4 — Configurer le media type Telegram
Le media type Telegram est livré comme webhook préconfiguré dans Zabbix 7. On va dans Administration → Media types → Telegram. La configuration demande un seul paramètre : le Token du bot Telegram. On colle le token fourni par BotFather (format 123456789:ABCdef…).
Le webhook Telegram parse automatiquement les notifications et les formate en Markdown. La cible (chat ID utilisateur ou groupe) est définie au niveau du media de chaque utilisateur, pas du media type. Cela permet à plusieurs personnes d’utiliser le même bot avec leurs propres chat IDs.
Pour récupérer son chat ID, on envoie un message au bot, puis on consulte l’API : curl https://api.telegram.org/bot<TOKEN>/getUpdates. Le JSON retourné contient un champ chat.id à conserver.
Étape 5 — Attacher des médias aux utilisateurs
Dans Users → Users → l’utilisateur cible → Media → Add. On choisit le media type Email, on saisit l’adresse, on définit la When active (par défaut 24/7) et la Use if severity (cocher toutes pour démarrer ; on affinera). On répète pour Telegram avec le chat ID comme « Send to ».
Pour une équipe de 5 personnes, chacun configure ses propres médias. C’est ce qui permet ensuite à l’action d’envoyer à tout le groupe sans dupliquer la configuration des destinataires dans l’action.
Étape 6 — Créer une action de notification
Dans Configuration → Actions → Trigger actions → Create action. On nomme l’action Alerter astreinte production. Dans Conditions, on définit ce qui déclenche : Trigger severity is greater than or equals Average, Host group equals Production. Plus on est spécifique, mieux c’est : une action qui notifie sur tous les triggers de tous les hôtes inonde l’astreinte.
Dans Operations, on crée la première étape : Send to user groups Astreinte L1 via Email, Step duration 0 (immédiat). C’est la notification de niveau 1, qui part dès le déclenchement.
Étape 7 — Configurer l’escalade
L’escalade est ce qui rend une chaîne robuste. Si personne n’a acquitté l’incident en 30 minutes, on monte d’un cran. On ajoute une seconde opération : Steps from 2 to 2, Step duration 1800 (30 minutes), Operation type Send message, Send to user groups Astreinte L2 via Telegram, Conditions Step 2 + Event acknowledgment status not Acknowledged.
La condition « not acknowledged » est cruciale : si quelqu’un a déjà acquitté l’incident en L1, on n’escalade pas inutilement. C’est ce qui distingue une chaîne mature d’une chaîne qui spamme tout le monde dès qu’un disque déborde.
On peut aller plus loin : étape 3 à 60 minutes vers le manager d’astreinte, étape 4 à 90 minutes qui exécute un script de remédiation automatique. Trois ou quatre niveaux suffisent en général ; au-delà c’est de la sur-ingénierie.
Étape 8 — Configurer le message de récupération
Une bonne pratique est de notifier aussi quand l’incident se résout. Dans Operations → Recovery operations, on ajoute Send message to Astreinte L1 via Email + Telegram. Le message Recovery utilise par défaut un template différent qui dit « Resolved: … » avec la durée de l’incident.
Sans cette notification de récupération, un opérateur réveillé à 3h ne sait pas si la situation s’est rétablie tant qu’il ne se connecte pas. La notification automatique permet de se rendormir plus vite, ce qui est mesurable en santé d’équipe.
Étape 9 — Tester la chaîne complète
On simule un incident en provoquant un trigger. Le test idéal : arrêter volontairement un service supervisé sur un hôte de test. Au bout de quelques minutes, le trigger bascule en PROBLEM, l’action s’exécute, l’email part. On vérifie qu’il arrive dans la boîte aux lettres et que son contenu est lisible.
Sans acquitter, on attend 30 minutes ; le second mail Telegram doit arriver. On acquitte alors l’événement depuis Monitoring → Problems → l’incident → Acknowledge ; on vérifie qu’aucune nouvelle notification ne part. On rétablit le service ; le mail Recovery doit arriver.
Cette répétition complète est la seule façon de garantir que la chaîne fonctionnera en production. Faire ce test avant le premier vrai incident.
Étape 10 — Lisser les triggers pour éviter le flapping
Un trigger qui change d’état toutes les 30 secondes (« flap ») envoie une notification à chaque bascule. Au bout d’une heure, l’astreinte a reçu 100 mails et n’écoute plus. La parade côté Zabbix tient en trois leviers.
Premier levier : utiliser des fonctions agrégées dans l’expression de trigger (avg(...,5m) > 80 au lieu de last(...) > 80). Une moyenne sur 5 minutes ne flap pas. Deuxième levier : configurer dans le trigger une Recovery expression distincte de l’expression principale, avec un seuil plus bas. C’est l’hystérésis : on déclenche à 90 %, on résout à 80 %, ce qui crée une bande morte qui empêche le flap. Troisième levier : utiliser la fonctionnalité Trigger dependencies pour qu’un trigger « hôte indisponible » masque tous les triggers fils ; quand un serveur tombe, on reçoit une seule notification au lieu de 50.
Étape 11 — Mettre en place des fenêtres de maintenance
Quand on patche un serveur ou qu’on fait une intervention planifiée, on ne veut pas que l’astreinte soit notifiée. Configuration → Maintenance → Create maintenance permet de définir une fenêtre temporelle pendant laquelle aucune notification ne part pour les hôtes ou groupes ciblés.
L’usage en discipline d’équipe : avant toute intervention non triviale, on crée une maintenance. À la fin, on la supprime ou on la laisse expirer. Coupler cette discipline à un workflow de change management (ticket Jira → maintenance Zabbix automatique via API) industrialise l’opération.
Étape 12 — Webhooks vers WhatsApp Business
Pour notifier sur WhatsApp, Zabbix n’a pas de media type officiel WhatsApp en 2026. La voie pragmatique passe par un webhook custom qui appelle l’API WhatsApp Business via un middleware (Twilio, MessageBird, ou un n8n self-hosté qui sert de relais).
On crée un media type de type Webhook avec un script JavaScript qui formate le payload et l’envoie au middleware. La documentation officielle webhook media types détaille la syntaxe. Cette voie demande quelques heures d’effort la première fois, puis devient un canal de notification de plus.
Étape 13 — Limiter le bruit en heures non ouvrées
Un défaut classique : recevoir des alertes Average à 3h du matin pour un disque à 85 % qu’on traitera demain. Deux mécanismes Zabbix limitent le bruit nocturne. Côté media : la propriété When active permet de définir des plages horaires (par exemple « lundi-vendredi 08:00-20:00 ») pendant lesquelles seul ce media est utilisé. Hors plage, le média est silencieux. Côté action : la condition Time period peut limiter l’action elle-même à certaines plages.
L’astreinte n’est généralement notifiée que pour des sévérités élevées (High, Disaster) la nuit, et pour toutes sévérités en heures ouvrées. Cette discrimination par sévérité × plage horaire fait la différence entre une astreinte tenable et un burn-out d’équipe.
Étape 14 — Tester la rotation des astreintes
Une équipe d’astreinte tournante a besoin que les notifications suivent automatiquement la rotation. Zabbix supporte ce besoin via les user groups : on crée un groupe Astreinte L1, on y ajoute la personne d’astreinte de la semaine courante. Chaque lundi matin, le manager d’équipe (ou un script) modifie l’appartenance du groupe pour basculer sur la personne suivante.
Le pattern industrialisé : un script Python qui lit un calendrier d’astreinte (Google Calendar, Confluence, ou un simple fichier YAML), et qui modifie l’appartenance du groupe via l’API Zabbix chaque jour à 8h. Les notifications suivent automatiquement, sans intervention humaine récurrente. La même approche s’applique aux astreintes L2 et au manager de garde.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Email de test passe mais alertes réelles n’arrivent pas | Action sans condition correspondante, ou aucun media attaché à l’utilisateur | Vérifier conditions de l’action et médias de l’utilisateur cible |
| Telegram bot ne répond pas | Token incorrect ou bot non démarré par l’utilisateur | Tester avec curl sur l’API Telegram, vérifier que l’utilisateur a envoyé /start au bot |
| Inondation d’alertes lors d’une panne réseau | Pas de trigger dependency configuré entre l’hôte et ses sous-services | Configurer dans chaque trigger fils une dépendance vers le trigger « host unreachable » |
| Mail Recovery jamais reçu | Recovery operations non configuré sur l’action | Onglet Operations → Recovery operations → Add |
| Notifications Telegram en double | Plusieurs actions matchent le même événement | Affiner les conditions, ou utiliser Pause operations while in maintenance |
Étape 15 — Audit des notifications envoyées
Une fois la chaîne en route, on contrôle régulièrement ce qui a été envoyé. Reports → Audit log → Filter sur Action Send message liste les notifications expédiées par Zabbix : qui, quand, sur quel événement, avec quel résultat (succès, échec). Ce journal sert deux usages. D’abord en post-mortem : après un incident, retracer si l’astreinte a bien été notifiée et combien de temps a pris l’escalade. Ensuite en analyse continue : un volume anormal de notifications sur un hôte signale un problème de seuil mal calibré qu’il faut affiner.