Quand j’ai pris en charge l’infrastructure Zabbix de notre organisation il y a deux ans, je n’imaginais pas que je passerais autant de temps à réfléchir aux templates. Le contexte : une dizaine de sites distants supervisés depuis un serveur central, avec un proxy Zabbix par site.

L’annonce de Zabbix 7 est arrivée à un moment où nos installations en 6.0 LTS commençaient à montrer des signes de fatigue. Le frontend en particulier était devenu douloureusement lent dès qu’on chargeait plus de 500 hôtes dans une vue. Le moment était venu de migrer.

Contexte : Cette migration concernait 10 proxies Zabbix répartis sur 10 sites, supervisant environ 12 000 hôtes au total. Le défi : zéro downtime sur la supervision, parce que dans un environnement où la disponibilité est critique, perdre la visibilité 5 minutes c’est déjà 5 minutes de trop.

Avant de plonger dans les détails techniques, voici un rappel visuel de l’architecture Zabbix qu’on a migrée. C’est une supervision multi-sites typique : un serveur central avec sa base de données et son frontend web, et un proxy Zabbix déployé dans chaque site distant pour collecter localement les données auprès des agents et des équipements SNMP. Clique sur les composants pour voir leur rôle exact.

React Flow

La phase de préparation

Avant même de toucher à la production, j’ai monté une réplique complète du serveur central sur mon homelab. Proxmox, deux LXC (un pour la base, un pour Zabbix), un dump anonymisé de la prod, et trois semaines de tests à exécuter chaque scénario que j’imaginais possible.

L’audit des templates a été la partie la plus longue. Sur 847 templates custom accumulés au fil des années, j’en ai trouvé une centaine qui dépendaient de fonctions dépréciées ou de macros user qui changeaient de comportement en 7. Le script d’audit que j’ai écrit à cette occasion mérite probablement un article dédié.

Audit des templates

Pour chaque template, je validais trois choses :

  • Les items : la syntaxe des keys n’a pas changé, mais certaines fonctions de preprocessing oui (notamment regex qui devient plus stricte sur les caractères d’échappement).
  • Les triggers : les expressions sont compatibles, sauf pour celles qui utilisaient l’ancien moteur d’expression (avant Zabbix 5.4) — ces triggers ont été silencieusement convertis mais pas tous correctement.
  • Les macros : surtout les {$MACRO:context} qui ont gagné en flexibilité mais perdu en rétrocompatibilité dans certains cas tordus.

Le basculement

Le jour J, j’avais un runbook de 47 étapes. La règle d’or : jamais d’action irréversible sans validation explicite. Chaque étape avait son rollback documenté.

Le piège qu’on n’avait pas vu venir : Zabbix 7 a changé le comportement par défaut de HostnameItem. Si ton proxy avait des hôtes avec des noms contenant des points (comme des FQDN), ils peuvent perdre leur association après migration. Solution : éditer manuellement la table hosts avant la bascule.

Plan de rollback

Pour ce genre d’opération, le plan de rollback est aussi important que le plan principal. Le mien tenait en trois commandes :

#!/bin/bash
# À lancer uniquement si la migration échoue
systemctl stop zabbix-server
qm rollback 100 pre-migration
systemctl start zabbix-server
echo "Rollback terminé. Vérifiez les logs."

Ce que j’aurais voulu savoir avant

Avec le recul, voici ce qui aurait pu m’éviter quelques sueurs froides :

  • Lire la breaking-changes complète, pas juste le résumé. Les changements sur l’API REST sont mentionnés en passant mais ils cassent réellement les intégrations existantes.
  • Tester sur la vraie volumétrie. Mon homelab tournait avec 200 hôtes ; certains comportements n’apparaissent qu’à partir de plusieurs milliers.
  • Préparer les widgets dashboards à la main. Ils ne sont pas migrés automatiquement et il faudra les refaire — autant savoir lesquels sont importants avant.

Conclusion

Migration finalement réussie en 4h, dont 30 minutes effectives de basculement et le reste en validation. Aucun downtime sur la supervision active. Le nouveau frontend est significativement plus rapide et l’expérience générale est largement meilleure que la 6.0.

Le code complet de mes scripts d’audit et de migration est disponible sur GitHub sous licence MIT. N’hésite pas à m’envoyer tes retours par mail si tu tombes sur quelque chose qui mérite discussion.