Installer Zabbix 7 sur Debian 12 ou Ubuntu 24.04 pas-à-pas

📍 Lecture connexe : Zabbix 7 LTS en 2026 : supervision open-source en production — pour la vue d’ensemble et les arbitrages.

Une instance Zabbix bien posée dès la première installation économise des heures de debug par la suite. Cette série commence par la pierre angulaire : monter un serveur Zabbix 7 LTS de zéro sur Debian 12 ou Ubuntu 24.04, avec PostgreSQL + TimescaleDB pour la base, Nginx pour le frontend, et un agent Zabbix 2 pour superviser le serveur lui-même. À la fin du tutoriel, vous aurez une instance fonctionnelle accessible en HTTPS et prête à recevoir vos premiers hôtes supervisés.

Prérequis

• Une machine Debian 12 (Bookworm) ou Ubuntu 24.04 LTS (Noble) avec accès root ou sudo, vérifier avec lsb_release -a
• 4 Go de RAM minimum, 2 vCPU, 20 Go de disque pour démarrer
• Une IP publique ou un nom DNS résolvable si vous voulez accéder au frontend depuis l’extérieur
• Niveau attendu : intermédiaire — vous savez utiliser apt, systemd, et éditer un fichier de configuration
• Temps estimé : environ 60 minutes

Étape 1 — Préparer l’OS et ajouter le dépôt officiel Zabbix

On commence par mettre à jour le système et installer les utilitaires nécessaires. Travailler sur un OS à jour évite la moitié des problèmes de paquets manquants ou de conflits de version. La commande apt update suivie de apt full-upgrade rapatrie les derniers correctifs de sécurité avant qu’on installe quoi que ce soit de nouveau.

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y wget gnupg ca-certificates lsb-release

L’étape suivante consiste à installer le paquet de configuration du dépôt Zabbix. Zabbix publie un paquet .deb qui ajoute la clé GPG du dépôt et le fichier /etc/apt/sources.list.d/zabbix.list. Pour Debian 12, l’URL pointe vers le canal 7.0 LTS ; pour Ubuntu 24.04, on adapte le nom du paquet.

# Debian 12
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
sudo dpkg -i zabbix-release_latest_7.0+debian12_all.deb

# Ubuntu 24.04 (alternative)
# wget https://repo.zabbix.com/zabbix/7.0/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
# sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb

sudo apt update

La commande apt update finale doit afficher le dépôt Zabbix dans sa liste de sources sans erreur GPG. Si elle se plaint d’une signature, c’est généralement que le paquet zabbix-release n’a pas été installé correctement ; on relance le dpkg -i et on vérifie qu’il termine en succès.

Étape 2 — Installer PostgreSQL et TimescaleDB

PostgreSQL 16 est dans les dépôts standard de Debian 12 et Ubuntu 24.04. TimescaleDB n’y est pas, on ajoute son dépôt officiel pour récupérer la dernière version stable. Cette étape n’est pas obligatoire mais fortement recommandée pour tout déploiement durable : les gains de compression et de performance compensent largement les cinq minutes d’installation supplémentaires.

# Dépôt PostgreSQL officiel (PGDG)
sudo install -d /usr/share/postgresql-common/pgdg
sudo curl -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc \
  --fail https://www.postgresql.org/media/keys/ACCC4CF8.asc
echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] \
https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | \
  sudo tee /etc/apt/sources.list.d/pgdg.list

# Dépôt TimescaleDB
curl -fsSL https://packagecloud.io/timescale/timescaledb/gpgkey | \
  sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/timescaledb.gpg
echo "deb https://packagecloud.io/timescale/timescaledb/$(. /etc/os-release; echo $ID)/ \
  $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/timescaledb.list

sudo apt update
sudo apt install -y postgresql-16 timescaledb-2-postgresql-16

Une fois PostgreSQL installé, le service démarre automatiquement. On vérifie son statut avec systemctl status postgresql ; il doit afficher active (running). À ce stade, la base écoute sur le socket Unix local et accepte uniquement les connexions peer, ce qui est ce qu’on veut pour un déploiement où Zabbix tourne sur la même machine.

Étape 3 — Installer les paquets Zabbix

On installe les composants côté serveur en une seule commande. Le paquet zabbix-server-pgsql contient le binaire serveur compilé contre PostgreSQL ; zabbix-frontend-php contient le frontend PHP ; zabbix-nginx-conf le vhost Nginx prêt à l’emploi ; zabbix-sql-scripts les scripts SQL d’initialisation ; zabbix-agent2 l’agent moderne pour superviser ce serveur lui-même.

sudo apt install -y \
  zabbix-server-pgsql \
  zabbix-frontend-php \
  zabbix-nginx-conf \
  zabbix-sql-scripts \
  zabbix-agent2 \
  zabbix-agent2-plugin-postgresql

L’installation crée plusieurs services systemd : zabbix-server, zabbix-agent2, nginx, php8.2-fpm. Aucun n’est démarré pour l’instant — la base de données n’existe pas encore, le démarrage prématuré générerait des erreurs dans les logs.

Étape 4 — Créer la base de données et l’utilisateur

Zabbix a besoin d’une base PostgreSQL dédiée et d’un utilisateur pour s’y connecter. On bascule en utilisateur postgres pour exécuter les commandes administratives.

sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix

La première commande crée l’utilisateur PostgreSQL zabbix et demande un mot de passe en interactif. On le note précieusement — il sera demandé à l’étape de configuration. La deuxième commande crée la base zabbix avec ce nouvel utilisateur comme propriétaire.

On charge ensuite le schéma initial de Zabbix. Le script SQL d’initialisation est gzippé dans /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz ; on le pipe directement vers psql via la commande zcat.

zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
  sudo -u zabbix psql zabbix

Le chargement prend quelques secondes à quelques dizaines de secondes selon le disque. Une fois terminé, la base contient quelques centaines de tables vides prêtes à recevoir la configuration et les métriques. Si le script s’arrête avec une erreur, le plus probable est un mot de passe absent dans ~/.pgpass ou un manque de droits ; on relance après diagnostic.

Étape 5 — Activer TimescaleDB sur les tables history

TimescaleDB transforme certaines tables PostgreSQL en hypertables partitionnées par temps, avec compression et purge automatiques. Zabbix livre depuis la 6.0 un script SQL qui active TimescaleDB sur les bonnes tables ; on l’exécute en post-installation.

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | \
  sudo -u postgres psql zabbix

cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | \
  sudo -u zabbix psql zabbix

L’activation de l’extension demande un redémarrage de PostgreSQL pour charger la bibliothèque dynamique. Si vous voyez un message d’avertissement à ce sujet, faire sudo systemctl restart postgresql avant de poursuivre. Le second script convertit les tables d’historique en hypertables et active la compression différée ; il doit s’exécuter sans erreur sur une base fraîche.

Étape 6 — Configurer le serveur Zabbix

Le fichier de configuration principal est /etc/zabbix/zabbix_server.conf. On édite trois directives : DBName (nom de la base), DBUser (utilisateur), DBPassword (le mot de passe créé à l’étape 4).

sudo sed -i 's/^# DBPassword=.*/DBPassword=mot_de_passe_choisi/' \
  /etc/zabbix/zabbix_server.conf

# Vérifier les directives
grep -E "^(DBName|DBUser|DBPassword)" /etc/zabbix/zabbix_server.conf

Sur Debian 12 et Ubuntu 24.04, les valeurs par défaut DBName=zabbix et DBUser=zabbix sont correctes ; on ne modifie que DBPassword. On vérifie que le mot de passe ne contient pas de caractères spéciaux problématiques pour bash (sinon échapper avec quotes).

Étape 7 — Configurer le frontend Nginx

Le paquet zabbix-nginx-conf a déposé /etc/zabbix/nginx.conf avec un vhost prêt. On édite deux lignes : listen pour ouvrir le port souhaité et server_name pour le nom DNS public.

sudo sed -i 's/^#\s*listen\s*8080;/listen 80;/' /etc/zabbix/nginx.conf
sudo sed -i 's/^#\s*server_name.*/server_name zabbix.example.com;/' /etc/zabbix/nginx.conf

Pour la production, on bascule en HTTPS via Certbot après avoir vérifié que le serveur répond en HTTP simple, mais cette étape sort du périmètre de ce tutoriel. Le vhost Nginx pointe automatiquement vers php8.2-fpm, qui est démarré par Nginx via socket Unix.

Étape 8 — Démarrer les services et vérifier

Tous les composants sont en place. On démarre les services et on les active au boot.

sudo systemctl restart zabbix-server zabbix-agent2 nginx php8.2-fpm
sudo systemctl enable zabbix-server zabbix-agent2 nginx php8.2-fpm

# Vérifier que tout tourne
systemctl status zabbix-server | head -5

Le statut doit afficher active (running). On contrôle ensuite les logs du serveur Zabbix : sudo tail -f /var/log/zabbix/zabbix_server.log. Au démarrage propre, on voit la ligne « Zabbix Server started » suivie de plusieurs « starting [housekeeper / configuration syncer / etc.] ». Aucune ligne ERROR ne doit apparaître. Si l’utilitaire zabbix_server se plaint d’une connexion base impossible, c’est presque toujours un problème de mot de passe dans zabbix_server.conf ou de permission pg_hba.conf.

Étape 9 — Première connexion au frontend

On ouvre http://zabbix.example.com (ou http://IP_PUBLIQUE si pas de DNS). Le wizard d’installation s’affiche. On clique « Next step », on confirme les vérifications de prérequis (PHP 8.2, extensions, timezone), on saisit les informations de connexion à la base, on définit le nom de l’instance, et on valide.

Le wizard génère un fichier /etc/zabbix/web/zabbix.conf.php avec la configuration du frontend. Si le fichier existe déjà avec des valeurs incorrectes, le wizard refuse d’écrire ; on le supprime ou le corrige à la main.

Après validation, on tombe sur l’écran de login. Les identifiants par défaut sont Admin avec mot de passe zabbix. On change ce mot de passe immédiatement via Users → Admin → Change password. Garder le mot de passe par défaut sur une instance accessible publiquement est une vulnérabilité critique.

Étape 10 — Vérifier que le serveur se supervise lui-même

L’agent Zabbix 2 installé à l’étape 3 supervise par défaut le serveur lui-même. On vérifie depuis le frontend : Configuration → Hosts → l’hôte Zabbix server doit être présent et son statut affiche Enabled avec un voyant ZBX vert. Si le voyant est rouge, c’est que l’agent ne répond pas sur 127.0.0.1:10050 ; on vérifie systemctl status zabbix-agent2 et le firewall local.

Dans Monitoring → Hosts, après une à deux minutes, des métriques commencent à apparaître : utilisation CPU, mémoire, espace disque, processus Zabbix Server lui-même (queue, cache, etc.). Cette première supervision en mode local valide que la chaîne complète (agent → serveur → base → frontend) fonctionne de bout en bout.

Étape 11 — Sécuriser l’instance avant production

Avant d’ouvrir le frontend à des utilisateurs autres que vous, plusieurs actions sont incompressibles. Activer HTTPS via Let’s Encrypt et Certbot — la configuration Nginx fournie supporte SSL en deux lignes ajoutées dans le bloc server. Configurer le pare-feu du serveur pour limiter les ports ouverts : 22 SSH (idéalement restreint à votre IP de bastion), 443 HTTPS, et rien d’autre côté Internet ; le 10050 (agent) et 10051 (serveur) restent en LAN. Activer la 2FA sur le compte administrateur depuis Users → Admin → Multi-factor authentication ; Zabbix 7 supporte TOTP en natif et l’opération prend deux minutes avec une application comme Aegis ou andOTP. Forcer enfin une politique de mots de passe robuste pour les utilisateurs locaux via Administration → Authentication → Password policy : longueur minimale 12 caractères, complexité activée, vérification contre la liste de mots de passe connus.

Sur des instances exposées au public, on ajoute idéalement un WAF léger (mod_security ou un filtrage Cloudflare en frontal), et on désactive le compte guest de Zabbix qui existe par défaut et permet une lecture anonyme — la case à décocher est dans Administration → Authentication.

Étape 12 — Mettre en place une sauvegarde quotidienne

Une instance Zabbix sans sauvegarde est une bombe à retardement. Toute la configuration (hôtes, templates, utilisateurs, dashboards) vit dans la base PostgreSQL ; perdre la base sans dump c’est repartir de zéro et reconstruire des semaines de travail. Le dump quotidien automatisé est non négociable.

sudo install -d -o postgres -g postgres /var/backups/zabbix
cat <<'EOF' | sudo tee /etc/cron.daily/zabbix-pgdump
#!/bin/bash
DATE=$(date +%Y%m%d)
sudo -u postgres pg_dump -Fc zabbix > /var/backups/zabbix/zabbix-$DATE.dump
find /var/backups/zabbix -name 'zabbix-*.dump' -mtime +14 -delete
EOF
sudo chmod +x /etc/cron.daily/zabbix-pgdump

Le format -Fc (custom) produit un dump compressé restaurable sélectivement avec pg_restore. La rétention de 14 jours sur disque est un minimum ; pour la production, on pousse les dumps vers un bucket S3-compatible avec versioning activé via un second cron, ce qui garantit qu’une corruption récente ne se propage pas à toutes les copies.

Tester la restauration au moins une fois après le premier dump est essentiel : on monte une seconde instance Zabbix sur une VM jetable, on charge le dump avec pg_restore -d zabbix dump_file, on démarre le serveur, et on vérifie que le frontend s’ouvre avec les mêmes hôtes et templates. Cette répétition d’incident donne la certitude que la procédure de restauration fonctionne le jour où ça compte.

Étape 13 — Préparer le plan de mise à jour

Zabbix livre des correctifs de version mineure (7.0.x) toutes les six à huit semaines, avec correctifs de sécurité et bugs. La discipline opérationnelle est de les appliquer en moins de 30 jours après leur sortie. Le mécanisme est trivial : apt update && apt upgrade zabbix-server-pgsql zabbix-frontend-php zabbix-agent2, suivi de systemctl restart zabbix-server zabbix-agent2 nginx. Le schéma de base évolue rarement entre point releases ; quand il évolue, le serveur Zabbix applique automatiquement les migrations au démarrage.

Pour le passage à la prochaine LTS (8.0 prévue mi-2027), la procédure est différente : on lit attentivement les notes de migration officielles, on teste en environnement de staging avec une copie de la base, on planifie une fenêtre de maintenance d’une heure ou deux selon la taille de la base. La migration LTS-vers-LTS reste plus simple qu’un changement de produit, mais demande un plan documenté.

Erreurs fréquentes

Étape 14 — Vérifier la configuration sécurité de la base

Une dernière passe de durcissement avant de considérer l’instance prête : la base PostgreSQL ne doit accepter de connexions que depuis le serveur Zabbix lui-même, jamais depuis le réseau public. La directive listen_addresses dans postgresql.conf doit rester à localhost ; si on a séparé la base sur une autre VM, on la met à l’IP privée correspondante et on filtre via le firewall ainsi que pg_hba.conf. Vérifier également que fsync, full_page_writes et synchronous_commit sont à on (valeurs par défaut) — les désactiver pour gagner en performance brute compromet l’intégrité de la base en cas de crash, ce qu’on évite absolument sur une supervision qui doit redémarrer fiablement après tout incident.

Ressources

• Documentation Zabbix — installation Debian/Ubuntu
• Dépôt officiel des paquets Zabbix
• Installation TimescaleDB sur Debian
• Exigences matérielles selon la taille cible
• Article connexe : Premier hôte supervisé : items, triggers, dashboards
• Article connexe : Zabbix Agent 2 et plugins natifs