Migrer de Zabbix 7.0 vers 8.0

01Quand migrer

Zabbix 7.0 reste une version de support long, il n'y a donc aucune urgence. Notre calendrier type pour une plateforme de production :

• à la sortie de la 8.0.0 : plateforme de recette montée en 8.0, avec une copie de la base de production ;
• à la 8.0.1 ou 8.0.2 : migration de la production, une fois les premiers correctifs publiés et les retours de terrain lus ;
• dans l'année : migration achevée partout, pour ne pas laisser coexister deux générations trop longtemps.

La montée directe de 7.0 vers 8.0 est prise en charge, sans passer par 7.2 et 7.4. Il faut en revanche lire les notes de montée des trois versions, 7.2, 7.4 et 8.0 : les changements des versions intermédiaires s'appliquent aussi.

02Les prérequis qui bloquent

La 8.0 relève les versions minimales de base de données et de PHP. C'est souvent là que se trouve le vrai chantier, parce que monter Zabbix revient alors à monter d'abord le moteur qui porte tout l'historique.

sudo -u postgres psql -tc "SELECT version();"
sudo -u postgres psql zabbix -tc "SELECT extversion FROM pg_extension WHERE extname='timescaledb';"
php -v | head -1
zabbix_server -V | head -1

03Les macros supprimées

La 8.0 abandonne une série de macros anciennes, dépréciées depuis longtemps mais encore très présentes dans les messages d'alerte écrits il y a des années. Une macro abandonnée n'est pas une erreur : elle s'affiche telle quelle dans la notification. Le message part, mais il devient illisible.

sudo -u postgres psql zabbix <<'SQL'
-- messages des operations d'actions
SELECT 'operation' AS ou, operationid AS id, subject
  FROM opmessage
 WHERE subject ~ '\{(HOSTNAME|IPADDRESS)[1-9]?\}|\{(TRIGGER\.COMMENT|TRIGGER\.KEY|STATUS|USER\.ALIAS|ACK\.[A-Z]+|EVENT\.ACK\.HISTORY)\}|\{PROFILE\.'
    OR message ~ '\{(HOSTNAME|IPADDRESS)[1-9]?\}|\{(TRIGGER\.COMMENT|TRIGGER\.KEY|STATUS|USER\.ALIAS|ACK\.[A-Z]+|EVENT\.ACK\.HISTORY)\}|\{PROFILE\.';

-- modeles de messages des types de medias
SELECT 'media' AS ou, mediatypeid AS id, subject
  FROM media_type_message
 WHERE subject ~ '\{(HOSTNAME|IPADDRESS)[1-9]?\}|\{(TRIGGER\.COMMENT|TRIGGER\.KEY|STATUS|USER\.ALIAS|ACK\.[A-Z]+|EVENT\.ACK\.HISTORY)\}|\{PROFILE\.'
    OR message ~ '\{(HOSTNAME|IPADDRESS)[1-9]?\}|\{(TRIGGER\.COMMENT|TRIGGER\.KEY|STATUS|USER\.ALIAS|ACK\.[A-Z]+|EVENT\.ACK\.HISTORY)\}|\{PROFILE\.';
SQL

Corrigez ce que la requête trouve avant la montée, sur la 7.0 : les macros de remplacement y fonctionnent déjà. Pensez aussi aux scripts globaux, aux paramètres des webhooks et aux noms de déclencheurs, que la requête ne couvre pas et qui se vérifient par l'interface.

04Agents, greffons et proxies

• Les agents n'ont pas besoin d'être montés en même temps que le serveur : un serveur 8.0 accepte les agents des versions précédentes. Montez-les ensuite, à votre rythme.
• Le greffon Ceph de l'agent 2 devient un paquet séparé. Sur chaque hôte qui supervise Ceph, installez zabbix-agent2-plugin-ceph en même temps que l'agent 8.0, et passez en mode natif si Ceph est en version 20 (chapitre 03).
• Les paramètres utilisateur : le caractère pourcent rejoint la liste des caractères refusés dans les valeurs transmises. Un paramètre qui recevait un pourcent cesse de fonctionner.
• Les proxies se montent juste après le serveur. Un proxy 7.0 est encore accepté par un serveur 8.0, puisqu'il appartient à la version de support long précédente, mais en mode dégradé : ne le laissez pas dans cet état plus de quelques jours.

05La procédure

Pour un serveur unique. Le cas de la grappe suit.

systemctl stop zabbix-server

# sauvegarde de la base, format personnalise, restaurable en parallele
sudo -u postgres pg_dump -Fc -f /srv/sauvegardes/zabbix-avant-8.0.dump zabbix

# configuration et fichiers du frontal
tar czf /srv/sauvegardes/zabbix-conf-avant-8.0.tar.gz \
  /etc/zabbix /usr/share/zabbix/conf/zabbix.conf.php /usr/lib/zabbix

# et un instantane de la machine virtuelle, si elle tourne sur Proxmox VE

# remplacer le paquet de depot 7.0 par celui de la 8.0
wget https://repo.zabbix.com/zabbix/8.0/release/debian/pool/main/z/zabbix-release/zabbix-release_latest_8.0+debian13_all.deb
dpkg -i zabbix-release_latest_8.0+debian13_all.deb
apt update

apt install --only-upgrade zabbix-server-pgsql zabbix-frontend-php \
  zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2

systemctl start zabbix-server

# la conversion de la base s'execute au premier demarrage
tail -f /var/log/zabbix/zabbix_server.log | grep -i -E 'database|upgrade|error'

Une fois la conversion terminée, videz le cache du navigateur avant de vous connecter au frontal : l'interface de la 8.0 a été largement revue, et un ancien fichier en cache suffit à produire des pages incohérentes.

06Le cas de la grappe

Une grappe de serveurs Zabbix ne se monte pas en roulement : deux versions différentes ne peuvent pas partager la même base. L'ordre est donc :

1. arrêter tous les noeuds de la grappe ;
2. sauvegarder comme ci-dessus ;
3. monter les paquets sur tous les noeuds ;
4. démarrer un seul noeud, qui convertit la base ;
5. une fois la conversion terminée et le noeud actif, démarrer les autres.

zabbix_server -R ha_status

07Le plan de retour arrière

La conversion de base est irréversible : il n'existe pas de chemin de la 8.0 vers la 7.0. Le retour arrière passe donc par la restauration, et il se prépare avant de commencer.

systemctl stop zabbix-server

# soit l'instantane de la machine virtuelle, le plus rapide
# soit la restauration de la base et le retour aux paquets 7.0 :
sudo -u postgres dropdb zabbix
sudo -u postgres createdb -O zabbix zabbix
sudo -u postgres pg_restore -j 4 -d zabbix /srv/sauvegardes/zabbix-avant-8.0.dump

# reinstaller le paquet de depot 7.0, puis les paquets en version 7.0
apt install --allow-downgrades zabbix-server-pgsql=1:7.0.* zabbix-frontend-php=1:7.0.*

08Liste de contrôle