Zabbix 7.0 est la première ligne LTS depuis la 6.0, et elle apporte le changement le plus visible depuis des années : un frontend reconstruit, un moteur de collecte plus efficace et un système de SLA natif. Chez imaxe, nous avons reconditionné tout cela dans une AMI prête pour la production sur Ubuntu 24.04, avec notre lecteur SQS réécrit pour tirer parti des nouvelles APIs.
Si vous exploitez déjà l'une de nos AMIs de Zabbix 6.0, ce guide vous explique ce que votre équipe gagne en mettant à jour et comment le faire sans perdre le moindre point d'historique.
L'AMI Zabbix 7.0 LTS est déjà disponible sur AWS Marketplace dans les 7 régions commerciales habituelles. La 6.0 LTS reste maintenue jusqu'à 2027-02, il n'y a donc pas d'urgence à migrer.
Un frontend qui se sent enfin moderne #
Le changement le plus visible dès l'entrée. Les tableaux de bord admettent désormais des widgets multipages avec rotation automatique, idéaux pour les écrans de NOC, et la navigation a été aplatie : moins de clics pour atteindre un problème précis.
- Widgets de top hosts, jauge et camembert redessinés, avec des seuils de couleur configurables.
- Mode kiosque amélioré pour les panneaux muraux, avec rafraîchissement indépendant par widget.
- Filtres enregistrés par utilisateur qui persistent entre les sessions.
SLA natif, sans jonglage #
Jusqu'à présent, calculer un SLA correct dans Zabbix impliquait des triggers auxiliaires et des calculs manuels. La 7.0 introduit un service de SLA de première classe : vous définissez l'objectif, les fenêtres de service et les périodes d'inactivité planifiée, et Zabbix fait le reste.
Nous sommes passés de la maintenance d'une feuille de calcul parallèle à avoir la conformité SLA sur le même tableau de bord que le reste des métriques. Cela seul justifie déjà la mise à jour.
Exclure les fenêtres de maintenance
Le calcul respecte les périodes de maintenance, de sorte qu'un redémarrage planifié ne pénalise pas votre disponibilité. Il se configure une fois et s'applique à tous les services associés.
Les triggers auxiliaires que vous utilisiez pour le SLA en 6.0 ne se convertissent pas tout seuls. Notez vos objectifs actuels pour les reconstruire avec le nouveau service.
Lecteur SQS réécrit #
Notre intégration d'auto-scaling lit les événements d'Auto Scaling depuis une file SQS pour retirer les instances qui disparaissent. Dans la 7.0, nous l'avons réécrite pour utiliser le client asynchrone et traiter des lots, réduisant la latence de retrait de minutes à secondes.
La configuration ne change pas : elle vit toujours dans /etc/zabbix/zabbix_ami.yml. Si vous venez de la 6.0, votre fichier est compatible tel quel.
$ imaxe status zabbix-sqs-reader
→ version 3.0.1 (async) · file connectée
→ dernier lot : 4 messages en 0.8s
$ journalctl -u zabbix-sqs-reader -n 20 --no-pagerComment migrer depuis la 6.0 #
Nous recommandons de migrer en lançant une nouvelle instance avec l'AMI 7.0 et en transférant les données, plutôt que de mettre à jour sur place. C'est plus sûr et cela vous laisse un chemin de retour.
- Lancez l'AMI Zabbix 7.0 LTS dans la même région et un type d'instance équivalent.
- Exportez la base de données de l'instance 6.0 et restaurez-la sur la nouvelle — le schéma se met à jour au premier démarrage.
- Copiez
/etc/zabbix/zabbix_ami.ymlet vos modèles personnalisés. - Vérifiez agents et alertes en parallèle pendant 24-48 h avant de déplacer l'EIP.
L'outil imaxe-zabbix-migrate inclus automatise le dump, le chargement et la vérification du schéma. Nous le documentons pas à pas dans la fiche de l'AMI.
Est-ce que ça en vaut la peine ? #
Si vous vivez dans les tableaux de bord ou avez besoin de reporter du SLA, la 7.0 est un saut évident. Si votre 6.0 fonctionne et que vous n'utilisez pas le SLA, il n'y a pas d'urgence : nous la maintiendrons patchée et auditée jusqu'à 2027. Dans tous les cas, la nouvelle AMI est prête quand vous l'êtes.