Sommaire

Problèmes connus

Voir aussi : Problèmes de compilation.

Mise à niveau

Paramètre SQL mode pour une mise à niveau réussie

Le paramètre sql_mode dans MySQL/MariaDB doit avoir le mode « STRICT_TRANS_TABLES » défini. S’il est absent, la mise à niveau de la base de données Zabbix échouera (voir aussi ZBX-19435).

Mise à niveau avec MariaDB 10.2.1 et versions antérieures

La mise à niveau de Zabbix peut échouer si les tables de la base de données ont été créées avec MariaDB 10.2.1 ou une version antérieure, car dans ces versions, le format de ligne par défaut est compact. Ce problème peut être corrigé en modifiant le format de ligne en dynamic (voir aussi ZBX-17690).

Modèles

Compatibilité des modèles dans les environnements double pile (IPv4/IPv6)

Dans les environnements double pile (systèmes configurés pour prendre en charge à la fois IPv4 et IPv6), le nom d’hôte localhost est généralement résolu à la fois en adresses IPv4 et IPv6. En raison de la priorisation courante d’IPv6 par rapport à IPv4 par de nombreux systèmes d’exploitation et résolveurs DNS, les modèles Zabbix peuvent ne pas fonctionner correctement si le service surveillé est configuré pour écouter uniquement sur IPv4.

Les services qui ne sont pas configurés pour écouter sur des adresses IPv6 peuvent devenir inaccessibles, entraînant des échecs de supervision. Les utilisateurs peuvent configurer l’accès correctement pour IPv4, mais rencontrer malgré tout des problèmes de connectivité en raison du comportement par défaut qui privilégie IPv6.

Une solution de contournement consiste à s’assurer que les services (Nginx, Apache, PostgreSQL, etc.) sont configurés pour écouter à la fois sur des adresses IPv4 et IPv6, et que l’accès au serveur/agent Zabbix via IPv6 est autorisé. De plus, dans les modèles et configurations Zabbix, utilisez explicitement localhost au lieu de 127.0.0.1 afin d’assurer la compatibilité avec IPv4 et IPv6.

Par exemple, lors de la supervision de PostgreSQL avec le modèle PostgreSQL by Zabbix agent 2, vous devrez peut-être modifier le fichier pg_hba.conf pour autoriser les connexions de l’utilisateur zbx_monitor. Si l’environnement double pile privilégie IPv6 (le système résout localhost en ::1) et que vous configurez localhost mais n’ajoutez qu’une entrée IPv4 (127.0.0.1/32), la connexion échouera car aucune entrée IPv6 correspondante n’existe.

L’exemple suivant de fichier pg_hba.conf garantit que l’utilisateur zbx_monitor peut se connecter à n’importe quelle base de données depuis la machine locale en utilisant à la fois des adresses IPv4 et IPv6 avec différentes méthodes d’authentification :

# TYPE     DATABASE     USER            ADDRESS          METHOD
  host     all          zbx_monitor     localhost        trust
  host     all          zbx_monitor     127.0.0.1/32     md5
  host     all          zbx_monitor     ::1/128          scram-sha-256

Si nécessaire, vous pouvez également utiliser directement l’adresse IPv4 (127.0.0.1) lors de la configuration de la macro du modèle PostgreSQL by Zabbix agent 2 pour la chaîne de connexion.

Installation accidentelle des paquets Zabbix d’EPEL

Si le dépôt EPEL est installé et activé, l’installation des paquets Zabbix peut récupérer les versions EPEL au lieu des paquets Zabbix officiels. Pour résoudre ce problème :

1. Supprimez tous les paquets Zabbix installés depuis EPEL :

dnf remove zabbix-server-mysql

2. Excluez les paquets Zabbix d’EPEL en ajoutant la ligne suivante au fichier /etc/yum.repos.d/epel.repo :

[epel]
...
excludepkgs=zabbix*

3.\ Réinstallez le paquet officiel du serveur Zabbix :

dnf install zabbix-server-mysql

Pendant l’installation, les paquets Zabbix officiels incluent le mot release dans leur chaîne de version (par exemple, 7.0.0-release1.el8), ce qui permet de les distinguer des paquets EPEL.

Paquets Zabbix pour RHEL dans des environnements Red Hat UBI

Lors de l’installation de Zabbix à partir de paquets Red Hat Enterprise Linux dans des environnements Red Hat Universal Base Image, assurez-vous d’avoir accès aux dépôts et dépendances requis. Les paquets Zabbix dépendent des bibliothèques libOpenIPMI.so et libOpenIPMIposix.so, qui ne sont fournies par aucun paquet dans les dépôts par défaut du gestionnaire de paquets activés sur les systèmes UBI, ce qui entraînera des échecs d’installation.

Les bibliothèques libOpenIPMI.so et libOpenIPMIposix.so sont disponibles dans le paquet OpenIPMI-libs, fourni par le dépôt redhat-#-for-<arch>-appstream-rpms. L’accès à ce dépôt est géré par les abonnements qui, dans le cas des environnements UBI, sont propagés en montant les répertoires de configuration des dépôts et des secrets de l’hôte RHEL dans l’espace de noms du système de fichiers du conteneur.

Pour plus d’informations, consultez ZBX-24291.

Clé de signature expirée pour les paquets RHEL

Lors de la mise à niveau de Zabbix sur Red Hat Enterprise Linux ou ses dérivés, vous pouvez rencontrer un problème de clé de signature expirée pour les paquets du dépôt Zabbix. Lorsqu’une clé de signature expire, les tentatives de vérification des signatures des paquets entraînent une erreur indiquant que le certificat ou la clé n’est plus valide. Par exemple :

error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
  1. Certificate 19F2475308EFA7DD invalid: certificate is not alive
      because: The primary key is not live
      because: Expired on 2024-07-04T11:41:23Z
  2. Key 19F2475308EFA7DD invalid: key is not alive
      because: The primary key is not live
      because: Expired on 2024-07-04T11:41:23Z

Pour résoudre ce type de problème, réinstallez manuellement le dernier paquet zabbix-release correspondant à votre variante spécifique de RHEL (remplacez le lien ci-dessous par le bon lien depuis le dépôt Zabbix).

Par exemple, sur RHEL 10, exécutez :

rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/10/noarch/zabbix-release-latest.el10.noarch.rpm

Ensuite, mettez à jour les informations du dépôt :

dnf update

Pour plus d’informations, consultez ZBX-24761.

Timescale DB : utilisation élevée de la mémoire avec un grand nombre de partitions

Les versions 9.6 à 12 de PostgreSQL utilisent trop de mémoire lors de la mise à jour de tables comportant un grand nombre de partitions. Ce problème se manifeste lorsque Zabbix met à jour les tendances sur des systèmes avec TimescaleDB si les tendances sont divisées en segments relativement petits (par exemple, 1 jour). Cela entraîne la présence de centaines de segments dans les tables de tendances avec les paramètres de housekeeping par défaut, une situation dans laquelle PostgreSQL risque fortement de manquer de mémoire.

Le problème a été résolu à partir de Zabbix 5.0.1 pour les nouvelles installations avec TimescaleDB, mais si TimescaleDB a été configuré avec Zabbix avant cela, veuillez consulter ZBX-16347 pour les notes de migration.

Timescale DB 2.5.0 : la politique de compression peut échouer sur les tables contenant des entiers

Ce problème se manifeste lorsque TimescaleDB 2.5.0/2.5.1 est utilisé. Il a été résolu à partir de TimescaleDB 2.5.2.

Pour plus d'informations, veuillez consulter TimescaleDB Issue #3773.

Connexion TLS à la base de données avec MariaDB

La connexion TLS à la base de données n'est pas prise en charge avec l'option 'verify_ca' pour le paramètre DBTLSConnect si MariaDB est utilisée.

Interblocages possibles avec MySQL/MariaDB

Lors d’une exécution sous forte charge, et avec plus d’un worker LLD impliqué, il est possible de rencontrer un interblocage causé par une erreur InnoDB liée à la stratégie de verrouillage des lignes (voir le bug en amont). L’erreur a été corrigée dans MySQL à partir de la version 8.0.29, mais pas dans MariaDB. Pour plus de détails, voir ZBX-21506.

Corrélation globale des événements

Les événements peuvent ne pas être corrélés correctement si l’intervalle de temps entre le premier et le deuxième événement est très court, c’est-à-dire d’une demi-seconde ou moins.

NetBSD 8.0 et versions ultérieures

Divers processus Zabbix peuvent se fermer inopinément au démarrage sur les versions 8.X et 9.X de NetBSD. Cela est dû à une taille de pile par défaut trop faible (4MB), qui doit être augmentée en exécutant :

ulimit -s 10240

Pour plus d’informations, veuillez consulter le rapport de problème associé : ZBX-18275.

Limitations des expressions régulières dans Zabbix agent 2

Zabbix agent 2 ne prend pas en charge les assertions anticipées (lookaheads) ni les assertions rétroactives (lookbehinds) dans les expressions régulières en raison des limitations de la bibliothèque standard regexp de Go.

Vérifications IPMI

Les vérifications IPMI ne fonctionneront pas avec le paquet standard de la bibliothèque OpenIPMI sur Debian antérieur à 9 (stretch) et Ubuntu antérieur à 16.04 (xenial). Pour corriger cela, recompilez la bibliothèque OpenIPMI avec OpenSSL activé, comme indiqué dans ZBX-6139.

IPMI — des hôtes non fiables peuvent faire planter OpenIPMI

Il existe un bogue dans la bibliothèque OpenIPMI utilisée par Zabbix pour interroger les données IPMI, qui peut être déclenché par des réponses spécialement conçues provenant d’un périphérique non fiable.
Un périphérique IPMI non fiable peut envoyer des données malveillantes provoquant le plantage de la bibliothèque OpenIPMI, ce qui peut à son tour entraîner l’arrêt du processus Zabbix server chargé de l’interrogation IPMI.

Vérifications SSH

  • Certaines distributions Linux comme Debian et Ubuntu ne prennent pas en charge les clés privées chiffrées (avec phrase de passe) si la bibliothèque libssh2 est installée à partir de paquets. Veuillez consulter ZBX-4850 pour plus de détails.
  • Lors de l'utilisation de libssh 0.9.x sur certaines distributions Linux avec OpenSSH 8, les vérifications SSH peuvent occasionnellement signaler « Cannot read data from SSH server ». Cela est dû à un problème de libssh (rapport plus détaillé). L'erreur est censée avoir été corrigée dans la version stable libssh 0.9.5. Voir également ZBX-17756 pour plus de détails.
  • L'utilisation du caractère de tube "|" dans le script SSH peut entraîner une erreur « Cannot read data from SSH server ». Dans ce cas, il est recommandé de mettre à niveau la version de la bibliothèque libssh. Voir également ZBX-21337 pour plus de détails.

Vérifications ODBC

  • Le pilote MySQL unixODBC ne doit pas être utilisé avec Zabbix server ou Zabbix proxy compilé avec la bibliothèque de connecteur MariaDB, et inversement ; si possible, il est également préférable d’éviter d’utiliser le même connecteur que le pilote en raison d’un bogue en amont. Configuration recommandée :

Connecteur PostgreSQL, SQLite ou Oracle → pilote MariaDB ou MySQL unixODBC Connecteur MariaDB → pilote MariaDB unixODBC Connecteur MySQL → pilote MySQL unixODBC

Consultez ZBX-7665 pour plus d’informations et les solutions de contournement disponibles.

  • Les données XML interrogées depuis Microsoft SQL Server peuvent être tronquées de différentes manières sur les systèmes Linux et UNIX.

  • Il a été observé que l’utilisation des vérifications ODBC pour surveiller des bases de données Oracle avec différentes versions d’Oracle Instant Client pour Linux provoque le plantage de Zabbix server.\ Voir aussi : ZBX-18402, ZBX-20803.

  • Si vous utilisez le pilote FreeTDS UnixODBC, vous devez faire précéder une requête SQL de l’instruction 'SET NOCOUNT ON' (par exemple, SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). Sinon, l’élément de surveillance de base de données dans Zabbix ne parviendra pas à récupérer les informations et renverra l’erreur "SQL query returned empty result".
    Consultez ZBX-19917 pour plus d’informations.

Paramètre de méthode de requête incorrect dans les éléments

Le paramètre de méthode de requête, utilisé uniquement dans les vérifications HTTP, peut être incorrectement défini sur « 1 », une valeur non par défaut pour tous les éléments à la suite d’une mise à niveau depuis une version de Zabbix antérieure à 4.0. Pour plus de détails sur la façon de corriger cette situation, consultez ZBX-19308.

Surveillance Web et agent HTTP

Le serveur Zabbix présente une fuite de mémoire sur certaines distributions Linux en raison d’un bogue amont lorsque « SSL verify peer » est activé dans les scénarios Web ou l’agent HTTP. Veuillez consulter ZBX-10486 pour plus d’informations et les solutions de contournement disponibles.

Vérifications simples

Il existe un bogue dans les versions de fping antérieures à la v3.10 qui gère incorrectement les paquets de réponse d’écho dupliqués. Cela peut entraîner des résultats inattendus pour les éléments icmpping, icmppingloss, icmppingsec. Il est recommandé d’utiliser la dernière version de fping. Veuillez consulter ZBX-11726 pour plus de détails.

Erreurs lors de l’exécution de fping dans des conteneurs rootless

Lorsque des conteneurs s’exécutent en mode rootless ou dans un environnement avec des restrictions spécifiques, vous pouvez rencontrer des erreurs liées à l’exécution de fping lors des vérifications ICMP, telles que fping: Operation not permitted ou la perte de tous les paquets vers toutes les ressources.

Pour corriger ce problème, ajoutez --cap-add=net_raw aux commandes "docker run" ou "podman run".

De plus, l’exécution de fping dans des environnements non root peut nécessiter une modification de sysctl, par exemple : 

sudo sysctl -w "net.ipv4.ping_group_range=0 1995"

où "1995" correspond au GID de zabbix. Pour plus de détails, consultez ZBX-22833.

Vérifications SNMP

Si le système d’exploitation OpenBSD est utilisé, un bogue de type use-after-free dans la bibliothèque Net-SNMP jusqu’à la version 5.7.3 peut provoquer un plantage du serveur Zabbix si le paramètre SourceIP est défini dans le fichier de configuration du serveur Zabbix. Comme solution de contournement, veuillez ne pas définir le paramètre SourceIP. Le même problème s’applique également à Linux, mais il n’entraîne pas l’arrêt du serveur Zabbix. Un correctif local pour le paquet net-snmp sur OpenBSD a été appliqué et sera publié avec OpenBSD 6.3.

Pics de données SNMP

Des pics dans les données SNMP ont été observés et peuvent être liés à certains facteurs physiques, comme des surtensions sur le réseau électrique. Voir ZBX-14318 pour plus de détails.

Traps SNMP

Le paquet « net-snmp-perl », nécessaire pour les traps SNMP, a été supprimé dans RHEL 8.0-8.2 ; il a été réintroduit dans RHEL 8.3.

Ainsi, si vous utilisez RHEL 8.0-8.2, la meilleure solution est de passer à RHEL 8.3.

Veuillez également consulter ZBX-17192 pour plus d’informations.

Plantage du processus d’alerte dans RHEL 7

Des cas de plantage d’un processus d’alerte du serveur Zabbix ont été constatés dans RHEL 7. Veuillez consulter ZBX-10461 pour plus de détails.

Mise à niveau de Zabbix agent 2 (6.0.5 ou version antérieure)

Lors de la mise à niveau de Zabbix agent 2 (version 6.0.5 ou antérieure) à partir de paquets, une erreur de conflit de fichiers liée à un plugin peut se produire. Pour corriger cette erreur, sauvegardez la configuration de votre agent 2 (si nécessaire), désinstallez agent 2, puis réinstallez-le.

Sur les systèmes basés sur RHEL, exécutez :

dnf remove zabbix-agent2
dnf install zabbix-agent2

Sur les systèmes basés sur Debian, exécutez :

apt remove zabbix-agent2
apt install zabbix-agent2

Pour plus d’informations, consultez ZBX-23250.

Changement aléatoire des paramètres régionaux du frontend

Il a été observé que les paramètres régionaux du frontend peuvent changer sans logique apparente, c.-à-d. que certaines pages (ou parties de pages) s’affichent dans une langue, tandis que d’autres pages (ou parties de pages) s’affichent dans une autre langue. En général, le problème peut apparaître lorsqu’il y a plusieurs utilisateurs, dont certains utilisent un paramètre régional, tandis que d’autres en utilisent un autre.

Une solution de contournement connue consiste à désactiver le multithreading dans PHP et Apache.

Le problème est lié à la manière dont le paramètre régional est défini dans PHP : les informations de paramètre régional sont conservées par processus, et non par thread. Ainsi, dans un environnement multithread, lorsque plusieurs projets sont exécutés par le même processus Apache, il est possible que le paramètre régional soit modifié dans un autre thread, ce qui change la manière dont les données peuvent être traitées dans le thread Zabbix.

Pour plus d’informations, veuillez consulter les rapports de problème associés :

  • ZBX-10911 (Problème de changement aléatoire des paramètres régionaux du frontend)
  • ZBX-16297 (Problème de traitement des nombres dans les graphiques utilisant la fonction bcdiv des fonctions BC Math)

Graphiques

Heure d’été

Les changements liés à l’heure d’été (DST) entraînent des irrégularités lors de l’affichage des libellés de l’axe X (duplication de dates, dates manquantes, etc.).

Agrégation par somme

Lors de l’utilisation de l’agrégation par somme dans un graphique pour une période inférieure à une heure, les graphiques affichent des valeurs incorrectes (multipliées) lorsque les données proviennent des tendances.

Chevauchement du texte

Pour certaines langues de l’interface web (par exemple, le japonais), les polices locales peuvent provoquer un chevauchement du texte dans la légende du graphique. Pour éviter cela, utilisez la version 2.3.0 (ou ultérieure) de l’extension PHP GD.

Surveillance des fichiers journaux

Les éléments log[] et logrt[] relisent de manière répétée le fichier journal depuis le début si le système de fichiers est plein à 100 % et que des données sont ajoutées au fichier journal (voir ZBX-10884 pour plus d’informations).

Requêtes MySQL lentes

Le serveur Zabbix génère des requêtes SELECT lentes en cas d'absence de valeurs pour les éléments. Ce problème est connu pour se produire dans les versions MySQL 5.6/5.7 (pour une discussion plus approfondie, voir ZBX-10652) et, dans certains cas spécifiques, peut également se produire dans des versions ultérieures de MySQL. Une solution de contournement consiste à désactiver l'optimiseur index_condition_pushdown ou prefer_ordering_index dans MySQL. Notez toutefois que cette solution de contournement peut ne pas résoudre tous les problèmes liés aux requêtes lentes.

Paramètres de filtre persistants à partir des liens

Lors de l’ouverture d’un lien vers une page du frontend Zabbix contenant des paramètres de filtre, y compris le sélecteur de temps, le filtre est automatiquement enregistré dans la base de données pour l’utilisateur, en remplaçant le filtre précédemment enregistré et/ou les paramètres du sélecteur de temps pour cette page. Ces paramètres restent actifs jusqu’à ce que l’utilisateur les mette à jour ou les réinitialise manuellement.

Problème d’adresse IPv6 dans les traps SNMPv3

En raison d’un bug de net-snmp, l’adresse IPv6 peut ne pas s’afficher correctement lors de l’utilisation de SNMPv3 dans les traps SNMP. Pour plus de détails et une solution de contournement possible, consultez ZBX-14541.

Adresse IP IPv6 longue tronquée dans les informations de connexion échouée

Un message de tentative de connexion échouée n’affichera que les 39 premiers caractères d’une adresse IP stockée, car il s’agit de la limite de caractères du champ dans la base de données. Cela signifie que les adresses IP IPv6 de plus de 39 caractères seront affichées de manière incomplète.

Vérifications de l'agent Zabbix sous Windows

Des entrées DNS inexistantes dans un paramètre Server du fichier de configuration de l'agent Zabbix (zabbix_agentd.conf) peuvent augmenter le temps de réponse de l'agent Zabbix sous Windows. Cela se produit parce que le service de mise en cache DNS de Windows ne met pas en cache les réponses négatives pour les adresses IPv4. En revanche, pour les adresses IPv6, les réponses négatives sont mises en cache ; une solution de contournement possible consiste donc à désactiver IPv4 sur l'hôte.

Export/import YAML

Il existe quelques problèmes connus avec l’export/import YAML :

  • Les messages d’erreur ne sont pas traduisibles ;
  • Un JSON valide avec une extension de fichier .yaml ne peut parfois pas être importé ;
  • Les dates lisibles par l’homme non entre guillemets sont automatiquement converties en horodatages Unix.

Assistant de configuration sur SUSE avec NGINX et php-fpm

L’assistant de configuration du frontend ne peut pas enregistrer le fichier de configuration sur SUSE avec NGINX + php-fpm.
Cela est dû à un paramètre dans l’unité /usr/lib/systemd/system/php-fpm.service, qui empêche Zabbix d’écrire dans /etc. (introduit dans PHP 7.4).

Deux solutions de contournement sont disponibles :

  • Définissez l’option ProtectSystem sur 'true' au lieu de 'full' dans l’unité systemd de php-fpm.
  • Enregistrez manuellement le fichier /etc/zabbix/web/zabbix.conf.php.

Transfert de l’en-tête Authorization

Dans certains cas, Apache ou NGINX peuvent empêcher l’en-tête Authorization des requêtes API d’atteindre Zabbix. Cela peut entraîner des problèmes d’authentification lors de l’utilisation de l’API Zabbix ou de services d’authentification unique (SSO), tels que SAML avec Okta.

Pour résoudre ce problème, mettez à jour la configuration de votre serveur web.

Pour Apache, si vous l’utilisez comme proxy inverse (configuration non CGI), ajoutez la directive suivante à /etc/httpd/conf/httpd.conf (sur les systèmes basés sur RHEL) ou à /etc/apache2/apache2.conf (sur Debian/Ubuntu) :

SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

Si Apache exécute directement des scripts pour traiter les requêtes (par exemple, en utilisant mod_cgi), ajoutez plutôt la directive suivante :

CGIPassAuth On

En revanche, NGINX gère automatiquement l’en-tête Authorization. Cependant, si NGINX agit comme proxy inverse, vous pouvez transférer explicitement l’en-tête Authorization en ajoutant les directives suivantes à /etc/nginx/nginx.conf (pour l’emplacement de votre interface Zabbix) :

...
location / {
...
    proxy_set_header Authorization $http_authorization;
    proxy_pass http://backend_server;
...
}

Après avoir mis à jour la configuration, redémarrez votre serveur web.

Pour plus de détails, voir :

Chromium pour le service web Zabbix sur Ubuntu 20

Bien que, dans la plupart des cas, le service web Zabbix puisse fonctionner avec Chromium, sur Ubuntu 20.04, l’utilisation de Chromium provoque l’erreur suivante :

Cannot fetch data: chrome failed to start:cmd_run.go:994:
WARNING: cannot create user data directory: cannot create 
"/var/lib/zabbix/snap/chromium/1564": mkdir /var/lib/zabbix: permission denied
Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.

Cette erreur se produit parce que /var/lib/zabbix est utilisé comme répertoire personnel de l’utilisateur « zabbix ».

Codes d’erreur MySQL personnalisés

Lorsque Zabbix détecte que la base de données backend est inaccessible, il envoie une notification et continue à tenter de se connecter. Pour certains moteurs de base de données, des codes d’erreur spécifiques sont reconnus. Dans MySQL, ces codes d’erreur reconnus incluent :

  • CR_CONN_HOST_ERROR
  • CR_SERVER_GONE_ERROR
  • CR_CONNECTION_ERROR
  • CR_SERVER_LOST
  • CR_UNKNOWN_HOST
  • ER_SERVER_SHUTDOWN
  • ER_ACCESS_DENIED_ERROR
  • ER_ILLEGAL_GRANT_FOR_TABLE
  • ER_TABLEACCESS_DENIED_ERROR
  • ER_UNKNOWN_ERROR

De plus, lors de l’utilisation de Zabbix avec une installation MySQL sur Azure, le message d’erreur générique [9002] Some errors occurred peut apparaître dans les journaux Zabbix. Ce message est envoyé par la base de données au serveur ou au proxy Zabbix. Pour déterminer la cause de l’erreur, veuillez consulter les journaux Azure.

Expressions régulières invalides après le passage à PCRE2

Dans Zabbix 6.0, la prise en charge de PCRE2 a été ajoutée. Même si PCRE est toujours pris en charge, les paquets d'installation de Zabbix pour RHEL 7 et versions ultérieures, SLES (toutes les versions), Debian 9 et versions ultérieures, Ubuntu 16.04 et versions ultérieures ont été mis à jour pour utiliser PCRE2. Bien qu'il offre de nombreux avantages, le passage à PCRE2 peut rendre certains motifs regexp PCRE existants invalides ou les faire se comporter différemment. Cela affecte en particulier le motif \^[\w-\.]. Afin de rendre à nouveau cette regexp valide sans en modifier la sémantique, remplacez l'expression par \^[-\w\.] . Cela est dû au fait que PCRE2 traite le tiret comme un délimiteur, créant une plage à l'intérieur d'une classe de caractères.

Erreur du widget Geomap

Les cartes du widget Geomap peuvent ne pas se charger correctement si vous avez effectué une mise à niveau depuis une ancienne version de Zabbix avec NGINX et que vous n’avez pas basculé vers le nouveau fichier de configuration NGINX pendant la mise à niveau.

Pour corriger le problème, vous pouvez supprimer l’ancien fichier de configuration, utiliser le fichier de configuration du paquet de la version actuelle et le reconfigurer comme décrit dans les instructions de téléchargement, dans la section e. Configurer PHP pour l’interface web Zabbix.

Vous pouvez également modifier manuellement un fichier de configuration NGINX existant (généralement, /etc/zabbix/nginx.conf). Pour ce faire, ouvrez le fichier et localisez le bloc suivant : 

location ~ /(api\/|conf[^\.]|include|locale|vendor) {
        deny            all;
        return          404;
}

Ensuite, remplacez ce bloc par : 

location ~ /(api\/|conf[^\.]|include|locale) {
        deny            all;
        return          404;
}

location /vendor {
        deny            all;
        return          404;
}

Prétraitement — les variables globales sont non sécurisées

Le JavaScript de prétraitement s’exécute à chaque requête, mais les affectations à des identifiants non déclarés (par exemple secret = value) créent des variables globales implicites qui peuvent persister au-delà de l’exécution en cours. Le stockage de données sensibles (jetons, mots de passe, etc.) dans des variables globales implicites augmente le risque d’exposition accidentelle ou de réutilisation lors d’exécutions de prétraitement ultérieures ou par d’autres intégrations s’exécutant dans le même environnement.

Ne vous appuyez pas sur des variables globales implicites. Déclarez toujours les variables avec var ou const, et évitez d’attacher des secrets à des objets globaux (par exemple globalThis ou window). Il n’existe aucun moyen pris en charge de remplacer les objets globaux intégrés depuis le prétraitement.

Exemple sécurisé :

var apiToken = payload.token;
var count = 1;
return JSON.stringify({ token: apiToken, calls: count });

Groupes de processeurs sous Windows

La documentation de Microsoft indique que les systèmes disposant de moins de 64 processeurs logiques n'ont toujours qu'un seul groupe de processeurs, le groupe 0. Cependant, des utilisateurs de Zabbix ont signalé un bogue rare ZBX-20260, lorsque deux groupes de processeurs sont présents sur des systèmes ayant 64 processeurs logiques ou moins. Cela a eu pour conséquence que les compteurs de performance "\Processor(n)" n'étaient disponibles que pour un seul des deux groupes de processeurs. La cause racine exacte de ce bogue n'est pas connue. Cependant, un cas similaire a été décrit sur stackoverflow.com, où la cause racine était liée à l'interopérabilité entre le BIOS et Windows.

Limites du filtrage avec les interclassements utf8mb4

Les filtres (par exemple, dans Collecte de données > Maintenance) peuvent ne pas fonctionner correctement lorsqu’ils sont appliqués à des entités contenant certains caractères Unicode (par exemple, ȼ, ɇ). Ce problème est dû à la manière dont l’interclassement utf8mb4_bin par défaut des bases de données MySQL ou MariaDB gère le tri et la comparaison des caractères Unicode.

Pour remédier à cette limitation, les utilisateurs peuvent modifier l’interclassement des colonnes de la base de données vers des alternatives telles que utf8mb4_0900_bin, utf8mb4_0900_ai_ci ou utf8mb4_unicode_520_ci. Notez toutefois que la modification de l’interclassement peut entraîner un comportement inattendu dans la gestion des espaces vides, ainsi que dans le tri et le filtrage d’autres caractères.

Pour plus d’informations sur la modification des interclassements, consultez la documentation MySQL ou la documentation MariaDB. Pour plus de détails sur les différences entre interclassements, consultez Jeux de caractères Unicode dans la documentation MySQL.

Accès aux éléments de l’interface utilisateur avec MariaDB 10.5.1–10.5.9

L’accès à l’interface web de Zabbix avec un rôle autre que Super Admin peut entraîner l’affichage du message : « Une erreur système s’est produite. Veuillez contacter l’administrateur Zabbix. ». Ce problème affecte les installations utilisant les versions de MariaDB 10.5.1 à 10.5.9.

Pour éviter ce problème, mettez à jour MariaDB vers une version postérieure à 10.5.9. Pour plus de détails, consultez ZBX-25746.

Analyse de l’utilisation excessive de la mémoire avec tcmalloc

Si vous soupçonnez que votre installation Zabbix utilise trop de mémoire, vous pouvez utiliser la fonctionnalité de profilage mémoire de tcmalloc pour examiner la consommation mémoire du serveur/proxy Zabbix.

1. Lors de l’installation de Zabbix à partir des sources, configurez des indicateurs supplémentaires :

export CFLAGS="-std=gnu99 -g -O0"

L’indicateur -std=gnu99 est requis pour compiler le serveur Zabbix, le proxy Zabbix ou l’agent Zabbix. L’indicateur -g ajoute des informations de débogage supplémentaires, tandis que -O0 désactive les optimisations, qui peuvent interférer avec le profilage de tcmalloc.

2. Définissez les variables d’environnement suivantes avant de démarrer le serveur Zabbix. Ces variables indiquent à tcmalloc comment suivre et signaler l’utilisation de la mémoire :

LD_PRELOAD="/usr/lib/aarch64-linux-gnu/libtcmalloc.so" \
HEAPPROFILE=./heap_profile \
HEAP_PROFILE_ALLOCATION_INTERVAL=0 \
HEAP_PROFILE_INUSE_INTERVAL=4294967296 \
HEAPPROFILESIGNAL=5 \
MALLOCSTATS=1 \
./sbin/zabbix_server -f -c /etc/zabbix/zabbix_server.conf

3. Déclenchez un vidage du profil en envoyant le signal 5 au processus cible. Remplacez 1234 par l’identifiant réel du processus (PID) :

kill -5 1234

4. Affichez le profil généré :

pprof-symbolize -text ./sbin/zabbix_server ./heap_profile.0001.heap

Using local file ./sbin/zabbix_server.
Using local file ./heap_profile.0001.heap.
Total: 1078.1 MB
  1076.8  99.9%  99.9%   1076.8  99.9% zbx_malloc2
     1.0   0.1% 100.0%      1.0   0.1% __GI___strdup
     0.2   0.0% 100.0%      0.2   0.0% CRYPTO_zalloc@@OPENSSL_3.0.0
     0.1   0.0% 100.0%      0.1   0.0% OPENSSL_LH_insert@@OPENSSL_3.0.0
     0.0   0.0% 100.0%      0.0   0.0% zbx_realloc2
     0.0   0.0% 100.0%      0.1   0.0% PKCS7_decrypt@@OPENSSL_3.0.0
     0.0   0.0% 100.0%      0.0   0.0% find_best_tree_node
     0.0   0.0% 100.0%      0.0   0.0% CRYPTO_strndup@@OPENSSL_3.0.0
     ...
     0.0   0.0% 100.0%      0.0   0.0% preprocessing_flush_value
     0.0   0.0% 100.0%   1074.0  99.6% preprocessor_add_request

Dans cet exemple, zbx_malloc2 est responsable de presque toutes les allocations mémoire.

Voir aussi :

Réplication de groupe MySQL 8.0 en mode multi-primaire

Lors de l’utilisation de la réplication de groupe MySQL 8.0 en mode multi-primaire, vous pouvez rencontrer une erreur lors de la validation des transactions, similaire à la suivante :

1531697:20250128:064734.697 query [txnlev:1] [update alerts set status=1,retries=0,error='' where alertid=154618;
1531697:20250128:064734.713 query [txnlev:1] [commit;]
1531697:20250128:064734.753 [Z3005] query failed: [3101] Plugin instructed the server to rollback the current transaction. [commit;]

Cette erreur semble être déclenchée par des problèmes liés aux opérations de rollback impliquant des contraintes de clé étrangère.

Voir aussi :