Skip to content

Zabbix Docker : monitoring complet de ton infrastructure

Brandon Visca
Date de publication:

💡 TL;DR

  • Zabbix est la solution de monitoring open-source la plus complète : métriques, logs, alerting, cartes réseau, tout y est
  • Un stack Docker Compose (Serveur + Frontend + Agent + Base de données) te fait tourner le bazar en 10 minutes
  • Les templates intégrés te font gagner des heures de config pour Docker, Linux, MySQL, nginx et j’en passe
  • Comparatif inclus : Zabbix reste le roi de la supervision “clé en main”, Prometheus brille plus sur le cloud-native pur

Table des matières

Table des matières

Pourquoi choisir Zabbix Docker plutôt qu’un script maison ?

On a tous été là. Tu as un serveur qui tourne tranquille, puis un matin tu te réveilles et ton site est KO. Pas d’alerte, pas de mail, rien. Juste un beau downtime de 6 heures que tu découvres parce que ta mère t’a envoyé un SMS : “Ton truc marche plus ?”

Le monitoring, c’est pas un luxe. C’est aussi vital que les sauvegardes. Et si tu as déjà lu mon guide sur Beszel, tu sais qu’il y a des solutions légères pour commencer. Mais Zabbix, c’est la version premium open-source. Celui qui ne se contente pas de te dire “ta RAM est à 90%”, il te trace une carte réseau, il t’envoie une alerte Telegram, il te loggue l’erreur MySQL, et si tu lui demandes gentiment, il te prévient avant que le disque soit plein.

Zabbix existe depuis 1998. C’est pas un petit nouveau sorti de nulle part. Il est mature, il a une communauté massive, et surtout : il sait tout faire. Métriques système (CPU, RAM, disque, réseau), supervision applicative (MySQL, PostgreSQL, nginx, Apache), monitoring réseau (SNMP, ping, discovery automatique), alerting multi-canal (email, Slack, Telegram, webhook), cartes réseau visuelles, tableaux de bord personnalisés… Tu veux un graphique de la température de ton NAS ? Il le fait. Tu veux une alerte si ton conteneur Docker redémarre trop souvent ? Il le fait aussi.

Et le meilleur dans tout ça : on peut le déployer en quelques minutes avec Docker. Fini les installations à base de apt install zabbix-server-mysql qui te pourrissent ta distro avec des dépendances à la pelle.

Ce qu’il te faut pour commencer

L’architecture Zabbix en bref

Avant de balancer le docker-compose.yml, comprenons ce qu’on déploie. Zabbix, c’est un écosystème, pas un simple binaire.

Le tout communique via des ports bien définis. Le Server écoute sur le 10051 pour les agents. Le Frontend est sur le 8080 (qu’on exposera via reverse proxy si besoin). La DB reste en interne, pas besoin de l’exposer sur Internet.

Et oui, si tu as déjà mis en place un pare-feu avec nftables, n’oublie pas d’ouvrir les ports nécessaires pour que tes agents puissent pousser leurs métriques.

Zabbix Docker : le Docker Compose complet

Crée un répertoire zabbix quelque part sur ton serveur, et jette ce docker-compose.yml dedans :

version: '3.8'

services:
  zabbix-mysql:
    image: mysql:8.0
    container_name: zabbix-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword_tres_fort
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbixpassword_tres_fort
    volumes:
      - zabbix-mysql-data:/var/lib/mysql
    networks:
      - zabbix-net
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_bin

  zabbix-server:
    image: zabbix/zabbix-server-mysql:ubuntu-7.0-latest
    container_name: zabbix-server
    restart: unless-stopped
    environment:
      DB_SERVER_HOST: zabbix-mysql
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbixpassword_tres_fort
      MYSQL_ROOT_PASSWORD: rootpassword_tres_fort
      ZBX_STARTVMWARECOLLECTORS: 0
      ZBX_VMWAREPERFREQUENCY: 0
    ports:
      - "10051:10051"
    volumes:
      - zabbix-server-data:/var/lib/zabbix
      - zabbix-server-alertscripts:/usr/lib/zabbix/alertscripts
      - zabbix-server-externalscripts:/usr/lib/zabbix/externalscripts
    networks:
      - zabbix-net
    depends_on:
      - zabbix-mysql

  zabbix-web:
    image: zabbix/zabbix-web-nginx-mysql:ubuntu-7.0-latest
    container_name: zabbix-web
    restart: unless-stopped
    environment:
      ZBX_SERVER_HOST: zabbix-server
      DB_SERVER_HOST: zabbix-mysql
      MYSQL_DATABASE: zabbix
      MYSQL_USER: zabbix
      MYSQL_PASSWORD: zabbixpassword_tres_fort
      PHP_TZ: Europe/Paris
    ports:
      - "8080:8080"
    networks:
      - zabbix-net
    depends_on:
      - zabbix-mysql
      - zabbix-server

  zabbix-agent:
    image: zabbix/zabbix-agent2:ubuntu-7.0-latest
    container_name: zabbix-agent
    restart: unless-stopped
    environment:
      ZBX_HOSTNAME: "Zabbix server"
      ZBX_SERVER_HOST: zabbix-server
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/hostfs:ro
    networks:
      - zabbix-net
    pid: host
    depends_on:
      - zabbix-server

volumes:
  zabbix-mysql-data:
  zabbix-server-data:
  zabbix-server-alertscripts:
  zabbix-server-externalscripts:

networks:
  zabbix-net:
    driver: bridge

Quelques explications pour les curieux :

Pour démarrer le bazar :

cd /chemin/vers/zabbix
docker compose up -d

Attends 30 à 60 secondes que MySQL initialise la base (premier démarrage), puis ouvre http://IP_DU_SERVEUR:8080 dans ton navigateur. Les identifiants par défaut sont Admin / zabbix.

Premiers pas dans l’interface

Une fois connecté, tu vas voir une interface austère. Ne panique pas, c’est normal. Zabbix a un design qui date un peu, mais il est efficace.

Monitoring > Hosts : C’est la liste des machines supervisées. Par défaut, il y a juste “Zabbix server”, qui est l’agent qu’on a déployé dans le compose.

Configuration > Hosts : C’est là que tu ajoutes des hôtes, que tu attaches des templates, que tu configures les interfaces. C’est le cœur de la configuration.

Monitoring > Latest data : Les données brutes remontées par les agents. CPU, mémoire, espace disque… Tout y est.

Monitoring > Dashboard : Le tableau de bord principal. Tu peux le personnaliser à mort avec des widgets, des graphiques, des cartes réseau.

Ton premier réflexe devrait être de changer le mot de passe Admin. Va dans Administration > Users > Admin > Change password. Fais-le maintenant, je t’attends.

Superviser Docker avec Zabbix en temps réel

Le gros avantage de l’agent 2, c’est qu’il a un plugin Docker natif. Grâce au montage du socket Docker (/var/run/docker.sock:/var/run/docker.sock:ro), Zabbix peut remonter automatiquement :

Pour activer ça, rien de plus simple. Va dans Configuration > Hosts, clique sur “Zabbix server”, puis dans l’onglet Templates. Ajoute le template “Docker by Zabbix agent 2” (c’est un template officiel livré avec Zabbix 6.0+). Attends une minute, et dans Monitoring > Latest data, tu verras apparaître des items liés à Docker.

Si tu veux monitorer d’autres conteneurs sur d’autres machines, il te suffit d’installer l’agent Zabbix 2 sur ces machines (aussi en Docker ou en binaire natif) et de lier le même template. C’est aussi simple que ça.

Les templates : ton meilleur ami

Zabbix livre des centaines de templates prêts à l’emploi. C’est une des raisons pour lesquelles il écrase la concurrence sur le terrain de la facilité de déploiement.

Attacher un template, c’est deux clics. Clique sur l’hôte, onglet Templates, “Link new templates”, sélectionne, “Update”. C’est fait. Tu viens de gagner 2 heures de configuration manuelle.

Et si un template ne te convient pas, tu peux le cloner et le modifier. C’est entièrement personnalisable. Tu veux une alerte si ton conteneur Chrony redémarre ? Tu crées un trigger personnalisé basé sur l’item Docker.

L’alerting dans Zabbix Docker : ne rate plus jamais une panne

Un monitoring sans alerting, c’est comme une Ferrari sans essence. Ça fait joli, mais ça ne sert à rien.

Zabbix gère l’alerting de manière très granulaire. Tu peux configurer :

Pour configurer Telegram (parce que c’est pratique et que tout le monde a Telegram sur son téléphone), va dans Administration > Media types > Telegram. Tu auras besoin de créer un bot via @BotFather sur Telegram, de récupérer le token, et de coller ton chat ID. Teste la connexion. Si ça marche, va dans Administration > Users, sélectionne ton utilisateur, onglet Media, et ajoute Telegram avec le chat ID.

Pour les triggers, Zabbix en a déjà pas mal de créés par les templates. Mais tu peux en ajouter. Par exemple, un trigger personnalisé qui vérifie si un conteneur spécifique est down :

last(/Zabbix server/docker.containers[up,"mon_conteneur"])=0

Sévérité : High. Et hop, tu reçois un message Telegram dès que ton conteneur tombe.

Zabbix Docker vs Prometheus : le match

Ce comparatif est inévitable. Prometheus est partout dans l’écosystème cloud-native. Alors lequel choisir ?

Zabbix est la solution “tout-en-un”. Il fait du pull et du push (les agents peuvent pousser les données, ou le serveur peut les récupérer). Il a une base de données relationnelle structurée. Il gère nativement le SNMP, le JMX, l’IPMI. Il a un frontend web complet avec gestion des utilisateurs, cartes réseau, rapports. C’est la solution idéale si tu veux un monitoring clé en main sans passer 3 semaines à écrire des règles d’alerting en YAML.

Prometheus est un pull-only time-series database ultra-optimisé pour le scraping HTTP. Il brille dans les environnements Kubernetes, les microservices, et les stacks cloud-native. Il est très rapide, très scalable, et s’intègre parfaitement avec Grafana pour la visualisation. Mais il demande beaucoup plus de boulot pour arriver au même résultat : il faut configurer chaque exporter, écrire les règles d’alerting en PromQL, configurer Alertmanager séparément, et monter Grafana pour avoir une interface utilisable.

Mon avis ? Si tu as un homelab traditionnel avec des VMs, des serveurs physiques, des switches SNMP, et que tu veux quelque chose qui marche tout de suite : Zabbix. Si tu fais du Kubernetes à grande échelle et que tu aimes bricoler : Prometheus + Grafana.

La bonne nouvelle : tu peux même faire cohabiter les deux. Zabbix pour la supervision système traditionnelle, Prometheus pour le monitoring applicatif Kubernetes, et Grafana pour centraliser les dashboards. Le meilleur des deux mondes.

Astuces pour ne pas te planter

Les mots de passe par défaut : On en a déjà parlé, mais c’est important. Admin / zabbix, c’est le premier couple testé par les bots. Change-le immédiatement.

La rétention des données : Par défaut, Zabbix garde l’historique des items pendant 90 jours et les tendances pendant 365 jours. Sur un petit VPS, ça peut faire grossir la base MySQL à plusieurs gigas. Va dans Administration > General > Housekeeping pour ajuster selon tes besoins. Tu peux aussi activer la compression de tables si tu es sur MySQL 8.

Les triggers trop sensibles : Un trigger qui s’enclenche à chaque pic de CPU de 5 secondes, c’est un trigger inutile. Utilise les fonctions comme avg() ou min() sur une fenêtre de temps pour éviter le bruit. Par exemple : avg(/Linux server/system.cpu.util[,user])>90 sur 5 minutes, c’est bien plus fiable qu’un last() brut.

Le reverse proxy : Exposer Zabbix sur le port 8080 en direct, c’est moche. Mets un reverse proxy nginx ou Caddy devant avec HTTPS. Le frontend Zabbix fonctionne très bien derrière un reverse proxy, il suffit de bien configurer les en-têtes X-Forwarded-For et X-Forwarded-Proto.

Les sauvegardes : La base MySQL contient TOUTES tes configurations, templates, hôtes, triggers, historiques. Sauvegarde-la régulièrement. Un simple mysqldump quotidien vers un répertoire qui est sync vers ton NAS ou S3, et tu dors tranquille.

FAQ

Quelle différence entre Zabbix agent et Zabbix agent 2 ? Zabbix agent 2 est réécrit en Go, il est plus rapide, plus léger, et supporte nativement des plugins comme Docker, MySQL ou PostgreSQL sans configuration complexe. Pour un déploiement Zabbix Docker moderne, c’est clairement l’agent à choisir.

Zabbix Docker consomme-t-il beaucoup de ressources ? Le stack complet (serveur + frontend + agent + MySQL) demande environ 1,5 à 2 Go de RAM au repos. C’est raisonnable pour une solution qui supervise ton infrastructure complète. Sur un petit VPS, limite la rétention des données dans Housekeeping pour économiser l’espace disque.

Peut-on superviser des conteneurs Docker avec Zabbix ? Oui, et c’est un des gros atouts de l’agent 2. En montant le socket Docker dans le conteneur agent, Zabbix remonte automatiquement le statut, le CPU, la RAM et les événements de chaque conteneur sans configuration supplémentaire.

Zabbix ou Prometheus pour un homelab ? Zabbix est plus simple à mettre en route et plus complet pour la supervision système traditionnelle (SNMP, agents natifs). Prometheus brille dans les environnements Kubernetes cloud-native. Pour un homelab classique, Zabbix Docker reste mon premier choix.

Conclusion

Zabbix sur Docker, c’est la combinaison gagnante pour qui veut un monitoring professionnel sans la complexité d’une installation native. En 10 minutes, tu as un serveur qui surveille ton CPU, ta RAM, tes conteneurs, ta base de données, et qui te prévient par Telegram si quelque chose dérape.

Le vrai pouvoir de Zabbix ne réside pas dans l’installation. Il réside dans la granularité de ses templates, la richesse de son alerting, et la maturité de son écosystème. Que tu gères un petit homelab ou une infrastructure de 200 serveurs, Zabbix scale avec toi.

Alors oui, l’interface manque de modernité. Oui, la courbe d’apprentissage est un peu plus raide que Beszel. Mais une fois que tu as goûté à un monitoring qui anticipe les problèmes plutôt que de constater les pannes, tu ne reviendras jamais en arrière.

Un serveur non monitoré est un serveur qui va tomber un jour. Un serveur monitoré avec Zabbix, c’est un serveur dont tu maîtrises le destin.

Next
GLPI Docker : ITSM complet auto-hébergé