Zabbix est une solution de supervision open source de niveau entreprise. Un premier déploiement réussi tient à trois décisions : une VM Linux pour le serveur, le bon agent sur chaque hôte, et les templates officiels plutôt qu’une configuration à la main. Le reste du parcours en découle.
Comment Zabbix s’organise
Un serveur Zabbix de base comprend trois éléments : le serveur Zabbix lui-même, l’interface web et une base de données qui stocke l’ensemble des informations. Autour de ce noyau gravitent des agents installés sur les machines à surveiller. Les agents collectent les données, le serveur les centralise, l’interface web sert à les consulter et à configurer. Quand l’infrastructure s’étend ou que la latence devient un sujet, des proxys peuvent s’intercaler, mais ce n’est pas un sujet de départ.
Une contrainte structure tout le reste : le serveur Zabbix ne s’installe pas sous Windows. Si votre parc est surtout Windows, il vous faut quand même une machine ou une VM Linux pour héberger le serveur. Vos serveurs Windows sont supervisés depuis ce serveur Linux, via l’agent installé sur chacun d’eux. C’est le modèle normal, pas un contournement.
Choisir la version et la distribution
En octobre 2025, trois versions sont actives : la 7.4.3 (1er octobre), la 7.2.13 (30 septembre) et la 7.0.19 LTS (29 septembre). Pour un premier déploiement destiné à durer, la branche LTS (7.0) est le choix prudent : elle est conçue pour un support plus long et des changements moins fréquents côté serveur. Les versions standard (7.2, 7.4) suivent un rythme plus rapide. Les numéros évoluent régulièrement : vérifiez la page des versions sur le site de Zabbix avant d’installer.
Le parcours de référence repose sur Debian 12 pour le serveur. Une autre distribution Linux fonctionne, mais les commandes et les noms de paquets peuvent différer : suivez alors la documentation officielle correspondant à votre distribution et à votre version de Zabbix. Côté licence, Zabbix est sous AGPLv3 depuis la 7.0 (juin 2024) ; les versions antérieures étaient sous GPLv2. Cela ne change rien à un déploiement interne ordinaire.
Agent classique ou agent 2 : le choix à faire avant tout
Deux agents existent. L’agent original, écrit en C, tourne sur Linux, Unix, Windows et macOS et collecte les métriques système de base : CPU, mémoire, disque, réseau. L’agent 2 est écrit en Go, gère des plugins natifs et offre de meilleures performances que l’agent classique. Pour un parc récent, l’agent 2 est le choix par défaut, et c’est lui que le parcours de référence installe sur Linux (zabbix-agent2).
Ce qui peut vous forcer la main, c’est la version de Windows de vos hôtes :
- Windows 10 et Windows Server 2016 et suivants : l’agent 2 est supporté, l’agent classique aussi.
- Windows plus anciens, jusqu’à XP et Server 2003 : seul l’agent classique est utilisable.
Faites donc l’inventaire des versions de Windows avant de choisir. Si vous ne l’avez pas, un audit du parc à l’aide de PowerShell, comme celui décrit pour la compatibilité Windows 11 d’un parc informatique, remonte les versions d’OS en quelques minutes. Rien n’interdit de mélanger : agent 2 sur les hôtes récents, agent classique sur les vieux systèmes qu’on ne peut pas encore retirer.
L’ordre de mise en route
La séquence qui limite les erreurs suit le sens des dépendances :
- Préparer la VM Linux du serveur. Le parcours de référence utilise Debian 12. Une VM de test Windows (le parcours type emploie une VM Windows 11) permet de valider la partie Windows avant de toucher à la production.
- Installer le serveur Zabbix avec ses trois éléments : le serveur, l’interface web et la base de données. Suivez la procédure officielle de la version choisie pour votre distribution.
- Déployer les agents Linux d’abord. Le cas est le plus simple, et vous validez que la chaîne agent, serveur, interface fonctionne.
- Déployer les agents Windows ensuite, avec l’agent adapté à la version de l’OS, comme vu plus haut.
- Rattacher les hôtes dans l’interface web et leur appliquer un template.
Un point de réseau à anticiper : les flux entre hôtes et serveur dépendent du mode de collecte. En mode passif, le serveur interroge l’agent. En mode actif, l’agent contacte lui-même le serveur. Les règles de pare-feu à ouvrir ne sont pas les mêmes dans les deux cas, et ce choix détermine aussi le template Windows à utiliser (voir plus bas). Notez le mode retenu avant de configurer les pare-feu, pas après.
Les templates officiels plutôt que des items faits main
Un template Zabbix regroupe des items (ce qui est collecté), des triggers (les conditions d’alerte), des graphes et des règles de découverte, applicables d’un coup à un ou plusieurs hôtes. Au début, c’est le raccourci à prendre : créer ses items un par un est long, et on ne sait pas encore ce qui mérite d’être mesuré.
Deux templates officiels suffisent pour démarrer :
- Linux by Zabbix agent : CPU, mémoire, disque, réseau et processus.
- Windows by Zabbix agent active : services Windows, Event Log et compteurs de performance.
Selon la source qui sert de base à ce parcours, ces deux templates couvriraient environ 95 % des métriques nécessaires sans configuration manuelle des items. C’est une estimation de la source, non mesurée : retenez simplement que le socle est large, et que vous ne partez pas d’une page blanche. Notez que le template Windows cité est la variante agent actif : si vous préférez le mode passif, cherchez dans la liste des templates la variante correspondante plutôt que d’adapter celui-ci à la main.
Une fois vos premiers hôtes remontés, vous saurez ce qui manque vraiment, et vous pourrez alors ajouter des items ciblés. Dans une démarche plus large d’industrialisation du parc, la supervision rejoint d’ailleurs les questions d’automatisation informatique : déploiement des agents, configuration, mises à jour.
Des alertes qui servent
Une supervision qui alerte sur tout finit ignorée. Les templates arrivent avec leurs triggers par défaut ; l’idée, au démarrage, est d’être sobre : ne garder que ce qui appelle une action, et ne pas multiplier les notifications pour des événements que personne ne traitera. Les seuils exacts dépendent de vos machines et de vos usages : observez d’abord quelques jours de données collectées, puis ajustez les triggers à ce que vous constatez, au lieu d’appliquer des valeurs recopiées ailleurs.
Côté notification, le parcours de référence couvre deux canaux : l’e-mail et Slack. L’e-mail est le plus simple à mettre en place ; Slack convient si votre équipe y réagit déjà au quotidien. Choisissez celui que quelqu’un lira réellement, et testez-le en provoquant une alerte volontaire avant de considérer la chaîne comme opérationnelle.
Après le socle : maintenance et SLA
Une fois les hôtes remontés et les alertes calibrées, deux fonctions méritent votre attention. Les fenêtres de maintenance évitent de recevoir des alertes pendant une opération planifiée, comme un redémarrage après mise à jour. Le suivi de SLA permet de mesurer la disponibilité des services supervisés dans le temps. Le parcours de référence les traite en dernier, et c’est le bon ordre : inutile d’y toucher tant que la collecte et les alertes de base ne sont pas stables.
Si votre environnement de test mêle Linux et Windows sur un même poste, par exemple pour préparer vos scripts de déploiement, la page sur WSL2 avec VS Code montre comment faire cohabiter les deux mondes côté poste d’administration. Le serveur Zabbix, lui, reste sur une vraie VM Linux.