📍 Lecture connexe : Zabbix 7 LTS en 2026 : supervision open-source en production — pour la vue d’ensemble et les arbitrages.
Configurer manuellement chaque item, chaque trigger et chaque graphe pour 50 hôtes est intenable. Les templates et l’auto-discovery LLD (Low-Level Discovery) sont les deux mécanismes Zabbix qui transforment cette tâche manuelle en industrie. Un template définit une fois la supervision d’un type d’objet ; l’auto-discovery détecte dynamiquement les éléments variables (interfaces réseau, partitions disque, processus). Ce tutoriel construit un template métier complet pour une application interne, le teste sur deux hôtes, et démontre comment LLD adapte automatiquement la supervision à la réalité de chaque hôte.
Prérequis
- Une instance Zabbix 7 fonctionnelle avec au moins deux hôtes Linux supervisés via Zabbix Agent 2 (voir tutoriels précédents)
- Un serveur Linux avec une application qui crée plusieurs partitions ou points de montage (n’importe quel serveur de production fait l’affaire)
- Niveau attendu : intermédiaire — vous avez compris items et triggers de base
- Temps estimé : environ 90 minutes
Étape 1 — Créer un template métier
Dans le frontend, on va dans Configuration → Templates → Create template. Le template a besoin d’un nom (par exemple Application API métier), d’un Template group (créer un groupe « Métier » pour les templates customs), et d’une description. On valide pour créer le template vide.
À ce stade, le template existe mais ne contient rien. On lui ajoute progressivement items, triggers, dashboards, règles d’auto-discovery. La discipline professionnelle est de partir d’un template existant qui ressemble à ce qu’on veut faire, puis de le personnaliser. On peut cloner un template officiel via Configuration → Templates → cocher la case → Copy → choisir « Full clone ».
Étape 2 — Ajouter un item simple
Dans le template fraîchement créé, on va dans Items → Create item. Pour superviser le statut HTTP d’une API métier, on configure un item avec : Name API status, Type HTTP agent, Key api.status, URL {$API.URL}/health, Status codes 200, Update interval 30s, Type of information Numeric (unsigned).
L’usage de la macro {$API.URL} est ce qui permet de réutiliser ce template sur N hôtes différents : chaque hôte définira sa propre valeur de macro (par exemple http://localhost:8080 pour un déploiement local ou https://api.interne pour un autre). Sans macro, on serait obligé de cloner le template par environnement.
On ajoute la macro au niveau template : onglet Macros → Add → Macro {$API.URL} → Value vide (sera surchargée par hôte). On sauvegarde l’item.
Étape 3 — Ajouter un trigger sur cet item
Dans le template, onglet Triggers → Create trigger. On configure : Name API métier indisponible, Severity High, Expression last(/Application API métier/api.status)=0 or last(/Application API métier/api.status)<>200. La syntaxe /Template/key dans l’expression désigne un item du template courant ; cette syntaxe est introduite en 5.4 et stable depuis.
L’expression vérifie que la dernière valeur retournée par l’item HTTP est bien 200 ; toute autre valeur (404, 500, 0 si le check a échoué) déclenche le problème. On peut affiner : last(/.../api.status)<>200 and count(/.../api.status,3)>2 exige trois échecs consécutifs avant de considérer un problème, ce qui filtre les pics ponctuels de réseau.
Étape 4 — Tester le template sur un hôte
On va dans Configuration → Hosts → l’hôte de test → Templates → ajouter le template Application API métier → Update. On retourne ensuite dans Macros pour cet hôte précis et on définit {$API.URL} avec la vraie URL de l’API.
Après une à deux minutes, l’item API status apparaît dans Latest data avec une valeur (200 si l’API répond, autre sinon). On simule une panne en arrêtant l’API ; le trigger doit basculer en PROBLEM. On la relance ; le trigger se résout. Cette boucle valide qu’un template métier fonctionne aussi simplement qu’un template officiel.
Étape 5 — Comprendre la Low-Level Discovery (LLD)
Tous les serveurs n’ont pas les mêmes interfaces réseau, partitions disque, ou conteneurs Docker. La LLD résout ce problème en exécutant périodiquement une « règle de découverte » qui retourne une liste d’objets (avec leurs noms et propriétés), puis en générant automatiquement des items et triggers à partir d’un prototype.
Concrètement, le template Linux officiel inclut une règle LLD Block devices discovery qui retourne la liste des partitions du système. Pour chaque partition trouvée, Zabbix instancie automatiquement les items Filesystem [{#FSNAME}]: free space, … used space, … used percentage, et le trigger … critically low. La macro {#FSNAME} est remplacée par le nom de chaque partition découverte.
Sur un serveur avec 4 partitions, la LLD crée donc 4 items × 3 métriques = 12 items + 4 triggers, sans qu’on ait à les configurer manuellement. Sur un serveur avec 20 partitions, c’est 60 items + 20 triggers générés automatiquement. Et si on monte une nouvelle partition, le prochain run de la LLD la détecte et instancie les nouveaux items.
Étape 6 — Examiner une règle LLD existante
Dans le template Linux officiel, on va dans Discovery rules → Block devices discovery. La règle est de type Zabbix agent avec la clé vfs.fs.discovery. Cette clé fait que l’agent retourne un JSON listant les partitions :
[
{"{#FSNAME}":"/", "{#FSTYPE}":"ext4"},
{"{#FSNAME}":"/var", "{#FSTYPE}":"ext4"},
{"{#FSNAME}":"/var/log", "{#FSTYPE}":"ext4"},
{"{#FSNAME}":"/data", "{#FSTYPE}":"xfs"}
]Chaque entrée du tableau crée un objet découvert, et les macros {#FSNAME} et {#FSTYPE} sont disponibles dans les prototypes. L’onglet Item prototypes liste ce qui est généré pour chaque entrée. L’onglet Trigger prototypes pareil pour les triggers.
Étape 7 — Créer sa propre règle LLD
On crée une règle LLD personnalisée pour superviser les conteneurs Docker actifs sur un hôte. Dans le template, Discovery rules → Create discovery rule. Name Docker containers, Type Zabbix agent, Key docker.containers.discovery (ce key est exposé par le plugin Docker de l’agent 2), Update interval 2m.
Les Filters permettent d’exclure certains conteneurs détectés. Par exemple, on peut filtrer les conteneurs système en ajoutant un filtre sur la macro {#NAME} qui matche un regex. Cette capacité de filtrage transforme la LLD en outil de gouvernance : on supervise tout sauf ce qu’on liste explicitement comme « ignoré ».
Étape 8 — Définir les item prototypes
Dans la règle LLD Docker containers, on va dans Item prototypes → Create item prototype. On crée un item avec : Name Container [{#NAME}]: CPU usage, Type Zabbix agent, Key docker.container_stats[{#NAME}], suivi du parsing JSON pour extraire le pourcentage CPU. La macro {#NAME} sera remplacée pour chaque conteneur découvert.
On répète pour mémoire, réseau, statut healthcheck. Quatre prototypes suffisent pour avoir une supervision Docker complète. Une fois sauvegardés, à la prochaine exécution de la LLD, Zabbix instancie ces prototypes pour chaque conteneur trouvé.
Étape 9 — Définir les trigger prototypes
Les triggers sont créés de la même manière. Trigger prototypes → Create trigger prototype. Name Container [{#NAME}]: CPU saturé, Expression avg(/Application API métier/docker.container_stats[{#NAME}],5m) > 90, Severity Average.
L’expression utilise avg(...,5m) pour lisser : seul un usage CPU continu au-dessus de 90 % pendant 5 minutes déclenche, ce qui exclut les pics de démarrage. Cette discipline d’agrégation est ce qui rend les alertes Zabbix exploitables ; sans elle, on est inondé par des problèmes qui se résolvent seuls en 30 secondes.
Étape 10 — Tester la LLD en pratique
On lie le template à un hôte qui fait tourner Docker. Après le délai de Update interval (2 minutes ici), la LLD s’exécute et instancie les items et triggers pour chaque conteneur. On va dans Configuration → Hosts → host → Items → filtre Discovered pour voir les items générés ; on en compte autant que de conteneurs × 4 prototypes.
Si on lance un nouveau conteneur Docker, à la prochaine exécution LLD, ses items apparaissent automatiquement. Si on stop un conteneur, ses items entrent en mode lost ; après le délai de Lost resources period (par défaut 30 jours), ils sont automatiquement supprimés. Cette gestion du cycle de vie évite l’accumulation de données obsolètes.
Étape 11 — Réutiliser et imbriquer les templates
Un template peut hériter d’un autre. Quand on dit que le template Linux by Zabbix agent est « lié » à Linux generic by Zabbix agent, ça signifie que le premier importe automatiquement tout le contenu du second. On exploite ce mécanisme pour bâtir une hiérarchie : un template Base PME (les bases minimales que tout serveur doit avoir), un template Web Production qui hérite du base et ajoute Nginx + PHP-FPM, un template API Métier qui hérite de Web Production et ajoute la santé applicative spécifique.
Cette imbrication évite la duplication. Modifier la base se propage à toutes les couches dérivées. Pour ajouter un template parent à un template enfant, on va dans le template enfant → Linked templates → Link → choisir le parent → Update.
Étape 12 — Exporter et versionner les templates
Les templates sont exportables au format YAML, JSON ou XML. On va dans Configuration → Templates → cocher → Export. Le fichier obtenu peut être committé dans Git, ce qui donne un historique des changements et permet la revue par les pairs.
Pour l’import en sens inverse, Configuration → Templates → Import. L’option Update existing met à jour les éléments existants sans dupliquer. Combiné avec un script CI qui exporte automatiquement après modifications, on obtient un GitOps de la supervision : toute modification du template passe par une PR, est revue, mergée, et l’environnement de production se met à jour à partir du Git.
Étape 13 — Documenter et partager
Un template sans documentation est intransmissible. La meilleure pratique est de remplir le champ Description du template avec un README minimal : à quoi sert ce template, quels objets supervise-t-il, quelles macros doivent être définies par l’hôte, quels sont les seuils par défaut et comment les ajuster.
Pour des équipes qui maintiennent dix ou vingt templates personnalisés, la discipline est de tenir un registre interne (page Confluence, fichier Markdown dans le repo Git) qui liste chaque template avec son périmètre et ses dépendances. Sans ce registre, après un an de turnover personnel, plus personne ne sait à quoi sert quel template.
Étape 14 — Tester un template avant de le pousser en production
Modifier un template lié à 200 hôtes est une opération à risque : si la modification introduit un bug (item mal configuré, trigger qui flap, regex LLD incorrecte), les 200 hôtes sont impactés en quelques minutes. La discipline professionnelle est de toujours valider sur un environnement de test avant la production.
Le pattern courant : on maintient deux templates parallèles, API métier et API métier (test). Les modifications passent d’abord par la version test, on lie deux ou trois hôtes pilotes au template test, on observe quelques jours en conditions réelles. Une fois validé, on copie les modifications dans le template production via export YAML / import YAML, puis on supprime ou archive la version test. Cette ceinture-bretelles évite les régressions silencieuses qui réveillent l’astreinte un weekend.
Étape 15 — Versionnage et CI
Pour des équipes qui prennent le sujet au sérieux, le pipeline cible ressemble à : repo Git contenant les exports YAML de tous les templates, GitHub Action qui valide la syntaxe avec un linter dédié (Zabbix Template Linter open-source) et qui pousse vers une instance de staging. Validation en staging, merge sur main, propagation en production via API. Ce cycle GitOps appliqué aux templates Zabbix est ce qui transforme une supervision artisanale en pratique industrielle reproductible.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| LLD ne découvre rien malgré des objets visibles côté hôte | L’agent ne supporte pas la clé de découverte ou n’a pas les droits | Tester avec zabbix_get -s host -k vfs.fs.discovery et vérifier le JSON retourné |
| Trop d’items générés par la LLD (saturation NVPS) | Pas de filtre LLD, ou prototype d’item trop fréquent | Ajouter un filtre regex pour limiter les objets supervisés ; allonger l’Update interval |
| Items prototype en statut Unsupported | Macro {#FSNAME} contient des caractères spéciaux mal échappés |
Configurer le bon Macro context dans la clé de l’item prototype |
| Modification de template ne se propage pas | Action de Update plutôt que Sync recommandée | Cliquer Sync sur l’hôte pour forcer la propagation immédiate |
| Items lost qui ne disparaissent jamais | Lost resources period configuré à 0 | Configurer 30 days par défaut dans la règle LLD ou globalement |
Étape 16 — Erreurs de design à éviter
Quelques anti-patterns qu’on rencontre régulièrement dans des templates mal construits. Premier anti-pattern : un template qui contient à la fois la supervision Linux générique et la supervision applicative spécifique. Solution : séparer en deux templates et lier les deux à l’hôte. Deuxième anti-pattern : des items à intervalle 10 secondes pour des métriques qui ne bougent qu’à l’heure (espace disque par exemple). Solution : adapter l’intervalle à la fréquence réelle de variation. Troisième anti-pattern : des triggers en cascade qui se déclenchent les uns après les autres sans dépendances explicites. Solution : déclarer les dépendances pour que la perte d’un service masque les problèmes des composants en aval.