Ma petite mise à jour annuelle de Zabbix 🙂 . Comme d’habitude, l’OS qui fait tourner mon instance Zabbix est une Debian (ici une Bullseye, à jour). La mise à jour de Zabbix version 5.4.x vers la version 6.0.x se fera donc en utilisant les dépôts Debian mis à disposition par le projet Zabbix, et en suivant scrupuleusement la documentation.
Notes de mise à jour
Pour le passage de la branche 5.4.x vers la branche 6.0.x, le principal point d’attention relevé dans les notes de mise à jour sera la version minimale de la base de données. Pour ma part, j’utilise mariadb, et la version minimum requise 10.5.x. Ça tombe bien, la version de mariadb dans la Debian Bullseye est la 10.5.15.
Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 14658 Server version: 10.5.15-MariaDB-0+deb11u1 Debian 11 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]>
Il y a d’autres points notés, notamment sur le support des expressions régulières, des checks ODBC, des changements sur l’API ou encore sur les macros positionnelles, mais comme je ne me rappelle pas avoir customisé quoi que ce soit sur ces points, j’ai envie d’ignorer tout ça pour l’instant.
Mise à jour des fichiers de dépôt
# rm -f /etc/apt/sources.list.d/zabbix.list # wget https://repo.zabbix.com/zabbix/6.0/debian/pool/main/z/zabbix-release/zabbix-release_latest+debian11_all.deb # dpkg -i zabbix-release_latest+debian11_all.deb # apt update
Mise à jour des binaires
Arrêter zabbix et lancer la mise à jour: l’upgrade va me mettre à jour les paquets suivants :
zabbix-agent/zabbix 1:6.0.35-1+debian11 amd64 [pouvant être mis à jour depuis : 1:5.4.12-1+debian11]
zabbix-apache-conf/zabbix 1:6.0.35-1+debian11 all [pouvant être mis à jour depuis : 1:5.4.12-1+debian11]
zabbix-frontend-php/zabbix 1:6.0.35-1+debian11 all [pouvant être mis à jour depuis : 1:5.4.12-1+debian11]
zabbix-server-mysql/zabbix 1:6.0.35-1+debian11 amd64 [pouvant être mis à jour depuis : 1:5.4.12-1+debian11]
# systemctl stop zabbix-server # apt upgrade
J’ai répondu non à la question qui me demandait si je voulais remplacer mon fichier /etc/zabbix/zabbix_server.conf par celui fourni par la mise à jour, car je voulais conserver mes customisations.
Mise à jour des clés primaires dans toutes les tables concernées
C’est une des nouveautés, toutes les tables utilisent des clés primaires pour les nouvelles installations. Cette opération n’est pas comprise dans la mise à jour, aussi il faut procéder à la manip une fois celle-ci effectuée. La documentation indique la procédure à suivre, de deux manières différentes.
La méthode recommandée utilise l’utilitaire mysqlsh, mais celui-ci n’est pas installé dans mon instance, et je rechigne à installer un utilitaire pour une seule opération (même si je pourrais très bien le désinstaller après).
Les tables concernées par l’opération sont history, history_uint, history_str, history_log et history_text : ce sont des tables potentiellement volumineuses, aussi il faudra bien veiller à avoir de l’espace disque disponible car nous allons doubler la taille occupée par ces tables le temps de la migration.
ls -lh *.ibd | grep -e "^.* history.*\.ibd" -rw-rw---- 1 mysql mysql 2,0G 20 nov. 18:05 history.ibd -rw-rw---- 1 mysql mysql 64K 28 mars 2020 history_log.ibd -rw-rw---- 1 mysql mysql 128M 20 nov. 18:05 history_str.ibd -rw-rw---- 1 mysql mysql 24M 20 nov. 18:05 history_text.ibd -rw-rw---- 1 mysql mysql 12G 20 nov. 18:05 history_uint.ibd
Dans mon cas, il va donc falloir que j’ai une quinzaine de gigas disponibles dans ma partition /var/lib/mysql. Ça n’est pas le cas, il va donc falloir que j’augmente la taille du disque et de la partition, pour ensuite me retrouver avec autant de gigas non utilisés à la fin de la mise à jour. Ce qui me fait ronchonner, mais c’est relativement facile compte tenu que mon zabbix tourne dans une VM.
Mise à jour avec la méthode « without mysqlsh »
Vérifier que mariadb tourne en mode local_infile, ainsi qu’en mode log_bin_trust_function_creators: (honnêtement je ne connais pas la portée de ces paramètres, et je n’ai pas le temps ni l’envie d’approfondir le sujet)
MariaDB [(None)]> show variables like "%file%"; | local_infile | ON | MariaDB [(none)]> show variables like "%creators%"; | log_bin_trust_function_creators | OFF |
Ici le premier paramètre est bon , mais pas le deuxième; correction :
MariaDB [(none)]> SET GLOBAL log_bin_trust_function_creators = 1;
Pour préparer les tables, nous allons utiliser des scripts sql fournis par le paquet zabbix-sql-scripts :
# apt install zabbix-sql-scripts
Exécution du script /usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sql qui va renommer les tables d’historique actuelles qui sont concernées par l’ajout des PK, et les recréer avec les contraintes PK:
# mysql -u zabbix -p -D zabbix < /usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sql
Peupler les nouvelles tables avec les données des anciennes (ça risque d’être un peu long pour les grosses tables):
MariaDB [(none)]> SET GLOBAL max_statement_time=0; MariaDB [(none)]> use zabbix; MariaDB [zabbix]> INSERT IGNORE INTO history SELECT * FROM history_old; MariaDB [zabbix]> INSERT IGNORE INTO history_uint SELECT * FROM history_uint_old; MariaDB [zabbix]> INSERT IGNORE INTO history_str SELECT * FROM history_str_old; MariaDB [zabbix]> INSERT IGNORE INTO history_log SELECT * FROM history_log_old; MariaDB [zabbix]> INSERT IGNORE INTO history_text SELECT * FROM history_text_old;
Repasser le paramètre trust function creators machin truc à zéro:
MariaDB [(none)]> SET GLOBAL log_bin_trust_function_creators = 0;
Démarrer zabbix et contrôler la mise à jour du schéma de la base de données:
# systemctl start zabbix_server # tail -f /var/log/zabbix/zabbix_server.log 4173645:20241110:120232.048 Starting Zabbix Server. Zabbix 6.0.35 (revision 8a9017e52e7). 4173645:20241110:120232.048 ****** Enabled features ****** 4173645:20241110:120232.048 SNMP monitoring: YES 4173645:20241110:120232.048 IPMI monitoring: YES 4173645:20241110:120232.049 Web monitoring: YES 4173645:20241110:120232.049 VMware monitoring: YES 4173645:20241110:120232.050 SMTP authentication: YES 4173645:20241110:120232.050 ODBC: YES 4173645:20241110:120232.050 SSH support: YES 4173645:20241110:120232.051 IPv6 support: YES 4173645:20241110:120232.051 TLS support: YES 4173645:20241110:120232.051 ****************************** 4173645:20241110:120232.051 using configuration file: /etc/zabbix/zabbix_server.conf 4173645:20241110:120232.498 current database version (mandatory/optional): 05040000/05040001 4173645:20241110:120232.498 required mandatory version: 06000000 4173645:20241110:120232.498 optional patches were found 4173645:20241110:120232.498 starting automatic database upgrade 4173645:20241110:120232.543 completed 0% of database upgrade 4173645:20241110:120232.583 completed 1% of database upgrade 4173645:20241110:120232.597 completed 2% of database upgrade 4173645:20241110:120232.611 completed 3% of database upgrade 4173645:20241110:120232.668 completed 4% of database upgrade 4173645:20241110:120232.963 completed 5% of database upgrade 4173645:20241110:120233.018 completed 6% of database upgrade 4173645:20241110:120233.073 completed 7% of database upgrade 4173645:20241110:120233.080 completed 8% of database upgrade 4173645:20241110:120233.661 completed 9% of database upgrade 4173645:20241110:120233.666 completed 10% of database upgrade [...] 4173645:20241110:120237.936 completed 100% of database upgrade 4173645:20241110:120237.936 database upgrade fully completed
Supprimer les anciennes tables:
MariaDB [zabbix]> DROP TABLE history_old; MariaDB [zabbix]> DROP TABLE history_uint_old; MariaDB [zabbix]> DROP TABLE history_str_old; MariaDB [zabbix]> DROP TABLE history_log_old; MariaDB [zabbix]> DROP TABLE history_text_old;
Vérifier que tout va bien
Tout semble avoir correctement migré; toutefois, il y a quelques points à noter:
Perte de tous mes graphiques préférés
A priori on ne peut plus mettre de graphiques autre que ceux qui sont issus des latest data. Ça ne m’arrange pas car ce ne sont que des graphiques simples montrant la mesure d’un seul élément. Cependant on peut remplacer ça par un dashboard dans lequel rassembler un jeu de graphiques préférés, pour avoir une vue synthétique finalement meilleure qu’avec l’ancien système de graphiques préférés.
Mariadb à consommé beaucoup de cpu
Mais seulement la première 1/2 heure après la mise à jour : je ne sais pas si je suis tombé pendant une période d’housekeeping (mais je ne pense pas) ou si il y a eu autre chose. C’est retombé depuis.
Plus de macro $1 dans les noms des items
J’ai été négligeant sur ce point, mais c’était écrit noir sur blanc dans la documentation. J’aurais du être au courant dès ma mise à jour vers zabbix 4 que ces macros allaient finir par disparaître.
Pour faire un petit bilan des dégâts:
MariaDB [zabbix]> select count(name) from items where name like "%$1%"; +-------------+ | count(name) | +-------------+ | 1140 | +-------------+
1140 items ça représente un bout, mais je ne vais pas me les cogner un par un.
Pour corriger ça, il faut repasser sur les règles de découverte des items dans la rubrique discover de chaque template.Il s’agira de remplacer la macro « $1 » dans le nom de l’item par la macro utilisée dans le contexte, par exemple {#SNMPVALUE} ou {#FSNAME} ou bien encore {#IFNAME}.
C’est tout de même un boulot, une bonne vingtaine de templates que j’ai revus à la main. Je pense que j’en avais beaucoup car je me traîne de l’historique, mon installation initiale de zabbix étant ancienne et ayant subit beaucoup de mises à jour . Une fois que les règles auront été modifiées, les items devraient finir par se mettre à jour tout seuls.
Alerte sur le problème de locale
Ce message est apparu sur mon dashboard après la mise à jour:
J’ai corrigé avec:
# dpkg-reconfigure locales
En cochant en_GB.UTF-8 et en_US.UTF-8 (en plus de fr_FR.UTF-8 qui était déjà installé).
Puis un petit redémarrage d’apache:
# systemctl restart apache2
Fin
Mise à jour vers zabbix 6.0 terminée. Il me reste à présent à passer à zabbix 7.0 et mettre à jour mon OS vers debian 12, mais on verra ça plus tard.
o/