8 Problèmes connus

Démarrage du proxy avec MySQL 8.0.0-8.0.17

zabbix_proxy sur MySQL versions 8.0.0-8.0.17 échoue avec l'erreur "accès refusé" suivante :

[Z3001] connection to database 'zabbix' failed: [1227] Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

Cela est dû au fait que MySQL 8.0.0 commence à appliquer des autorisations spéciales pour définir les variables de session. Cependant, dans la version 8.0.18, ce comportement a été supprimé : Depuis MySQL 8.0.18, la définition de la valeur de session de cette variable système n'est plus une opération restreinte.

La solution de contournement est basée sur l'octroi de privilèges supplémentaires à l'utilisateur zabbix :

Pour les versions 8.0.14 à 8.0.17 de MySQL :

 grant SESSION_VARIABLES_ADMIN on *.* to 'zabbix'@'localhost';

Pour les versions 8.0.0 à 8.0.13 de MySQL :

grant SYSTEM_VARIABLES_ADMIN on *.* to 'zabbix'@'localhost';

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 avec un grand nombre de partitions (voir le rapport du problème). Ce problème se manifeste lorsque Zabbix met à jour les tendances sur les systèmes avec TimescaleDB si les tendances sont divisées en segments relativement petits (par exemple, 1 jour). Cela conduit à des centaines de morceaux présents dans les tables de tendances avec des paramètres de maintenance par défaut - la condition dans laquelle PostgreSQL est susceptible de manquer de mémoire.

Le problème a été résolu depuis 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.

Timescaledb 2.5.0 : la stratégie de compression peut échouer sur les tables contenant des entiers

Ce problème se manifeste lorsque TimescaleDB 2.5.0 est utilisé. Il a été résolu depuis TimescaleDB 2.5.1.

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

Upgrade

SQL mode setting for successful upgrade

The sql_mode setting in MySQL/MariaDB must have the "STRICT_TRANS_TABLES" mode set. If it is absent, the Zabbix database upgrade will fail (see also ZBX-19435).

Mise à jour avec MariaDB 10.2.1 et versions antérieures

La mise à jour de Zabbix peut échouer si les tables de base de données ont été créées avec MariaDB 10.2.1 et versions antérieures, car dans ces versions, le format de ligne par défaut est compact. Cela peut être résolu en changeant le format de ligne en dynamique (voir aussi ZBX-17690).

Templates

Template compatibility in dual-stack (IPv4/IPv6) environments

In dual-stack environments (systems configured to support both IPv4 and IPv6), the hostname localhost typically resolves to both IPv4 and IPv6 addresses. Due to the common prioritization of IPv6 over IPv4 by many operating systems and DNS resolvers, Zabbix templates may fail to work correctly if the service being monitored is configured to listen only on IPv4.

Services that are not configured to listen on IPv6 addresses may become inaccessible, leading to monitoring failures. Users might configure access correctly for IPv4 but still face connectivity issues due to the default behavior of prioritizing IPv6.

A workaround for this is to ensure that the services (Nginx, Apache, PostgreSQL, etc.) are configured to listen on both IPv4 and IPv6 addresses, and Zabbix server/agent is allowed access via IPv6. Additionally, in Zabbix templates and configurations, use localhost explicitly instead of 127.0.0.1 to ensure compatibility with both IPv4 and IPv6.

For example, when monitoring PostgreSQL with the PostgreSQL by Zabbix agent 2 template, you may need to edit the pg_hba.conf file to allow connections for the zbx_monitor user. If the dual-stack environment prioritizes IPv6 (system resolves localhost to ::1) and you configure localhost but only add an IPv4 entry (127.0.0.1/32), the connection will fail because there is no matching IPv6 entry.

The following pg_hba.conf file example ensures that the zbx_monitor user can connect to any database from the local machine using both IPv4 and IPv6 addresses with different authentication methods:

# 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

If necessary, you can also use the IPv4 address (127.0.0.1) directly when configuring the PostgreSQL by Zabbix agent 2 template macro for the connection string.

Accidental installation of EPEL Zabbix packages

With EPEL repository installed and enabled, installing Zabbix from packages will lead to EPEL Zabbix packages being installed rather than official Zabbix packages.

In this case uninstall Zabbix packages from EPEL, i.e.:

dnf remove zabbix-server-mysql

Block Zabbix packages from EPEL. Add the following line in the /etc/yum.conf file:

exclude=zabbix6.0*

Install Zabbix server again:

dnf install zabbix-server-mysql

Notice that official Zabbix packages have the word release in their version string:

6.0.25-release1.el8

Zabbix packages for RHEL on Red Hat UBI environments

When installing Zabbix from Red Hat Enterprise Linux packages on Red Hat Universal Base Image environments, ensure access to required repositories and dependencies. Zabbix packages depend on libOpenIPMI.so and libOpenIPMIposix.so libraries, which are not provided by any package in the default package manager repositories enabled on UBI systems and will result in installation failures.

The libOpenIPMI.so and libOpenIPMIposix.so libraries are available in the OpenIPMI-libs package, which is provided by the redhat-#-for-<arch>-appstream-rpms repository. Access to this repository is curated by subscriptions, which, in the case of UBI environments, get propagated by mounting repository configuration and secrets directories of the RHEL host into the container file-system namespace.

For more information, see ZBX-24291.

Expired signing key for RHEL packages

When upgrading Zabbix on Red Hat Enterprise Linux, you may encounter an expired signing key issue for packages on Zabbix repository. When a signing key expires, attempts to verify package signatures will result in an error indicating that the certificate or key is no longer valid. For example:

error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
         1. Certificiate 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

To resolve such issues, manually reinstall the latest zabbix-release package for your specific variant of RHEL (replace the link below with the correct one from Zabbix repository).

For example, on RHEL 9, run:

rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm

Then, update the repository information:

dnf update

For more information, see ZBX-24761.

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é.

Blocages possibles avec MySQL/MariaDB

Lors d'une exécution sous charge élevée et avec plus d'un agent LLD impliqué, il est possible de se retrouver dans un blocage causé par une erreur InnoDB liée à la stratégie de verrouillage de ligne (voir lebogue en amont). L'erreur a été corrigée dans MySQL depuis 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 petit, c'est-à-dire une demi-seconde et moins.

Plage de types de données numériques (float) avec PostgreSQL 11 et versions antérieures

PostgreSQL 11 et les versions antérieures ne prennent en charge que la plage de valeurs à virgule flottante d'environ -1,34E-154 à 1,34E+154.

NetBSD 8.0 et plus récent

Divers processus Zabbix peuvent planter de manière aléatoire au démarrage sur les versions 8.X et 9.X de NetBSD. Cela est dû à la taille trop petite de la pile par défaut (4 Mo), qui doit être augmentée en exécutant :

ulimit -s 10240

Pour plus d'informations, veuillez consulter le rapport de problème connexe : ZBX-18275.

Regular expression limitations in Zabbix agent 2

Zabbix agent 2 does not support lookaheads and lookbehinds in regular expressions due to the standard Go regexp library limitations.

Vérifications IPMI

Les vérifications IPMI ne fonctionneront pas avec le package de bibliothèque OpenIPMI standard sur Debian avant 9 (stretch) et Ubuntu avant 16.04 (xenial). Pour résoudre ce problème, recompilez la bibliothèque OpenIPMI avec OpenSSL activé, comme indiqué dans ZBX-6139.

Vérifications SSH

• Certaines distributions Linux comme Debian, Ubuntu ne prennent pas en charge les clés privées cryptées (avec mot de passe) si la bibliothèque libssh2 est installée à partir de packages. Veuillez consulter ZBX-4850 pour plus de détails.

• Lors de l'utilisation de libssh 0.9.x sur CentOS 8 sur certaines distributions Linux avec OpenSSH 8, les vérifications SSH peuvent occasionnellement signaler "Cannot read data from SSH server". Ceci est causé par un problème libssh (rapport plus détaillé) . L'erreur devrait avoir été corrigée par une version stable de libssh 0.9.5. Voir aussi ZBX-17756 pour plus de détails.

• Utilisation du pipe "|" 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 aussi ZBX-21337 pour plus de détails.

Vérifications ODBC

• Le pilote MySQL unixODBC ne doit pas être utilisé avec le serveur Zabbix ou le proxy Zabbix compilé avec la bibliothèque de connecteurs MariaDB et vice versa, 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 suggérée :

  PostgreSQL, SQLite ou Oracle connector → MariaDB ou MySQL unixODBC driver MariaDB connector → MariaDB unixODBC driver MySQL connector → MySQL unixODBC driver

Veuillez consulter ZBX-7665 pour plus d'informations et les solutions de contournement disponibles.

• Les données XML interrogées à partir de 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 les bases de données Oracle à l'aide de différentes versions d'Oracle Instant Client pour Linux provoque le blocage du serveur Zabbix. Voir aussi ZBX-18402, ZBX-20803.

• Si vous utilisez le pilote FreeTDS UnixODBC, vous devez ajouter une instruction 'SET NOCOUNT ON' à une requête SQL (par exemple, `SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = .... `). Sinon, l'élément de surveillance de la base de données dans Zabbix ne parviendra pas à récupérer les informations avec une erreur "SQL query returned empty result".
  Voir 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 autre que la valeur par défaut pour tous les éléments à la suite d'une mise à niveau à partir d'une version antérieure à la version 4.0 de Zabbix. Pour plus de détails sur la façon de résoudre ce problème, consultez ZBX-19308.

Surveillance Web et agent HTTP

Le serveur Zabbix perd de la mémoire sur certaines distributions Linux en raison d'un bogue en amont lorsque "SSL verify peer" est activé dans des scénarios Web ou un HTTP agent. Veuillez consulter ZBX-10486 pour plus d'informations et les solutions de contournement disponibles.

Vérifications simples

Il existe un bogue dans les versions fping antérieures à la v3.10 qui gère mal les paquets de relecture d'écho en double. 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.

Errors with fping execution in rootless containers

When containers are running in rootless mode or in a specific-restrictions environment, you may face errors related to fping execution when performing ICMP checks, such as fping: Operation not permitted or all packets to all resources lost.

To fix this problem add --cap-add=net_raw to "docker run" or "podman run" commands.

Additionally fping execution in non-root environments may require sysctl modification, i.e.:

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

where "1995" is the zabbix GID. For more details, see ZBX-22833.

Vérifications SNMP

Si le système d'exploitation OpenBSD est utilisé, un bogue 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. Pour contourner ce problème, veuillez ne pas définir le paramètre SourceIP. Le même problème s'applique également à Linux, mais cela n'empêche pas le serveur Zabbix de fonctionner. 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 qui peuvent être liés à certains facteurs physiques tels que les pics de tension. Voir ZBX-14318 pour plus de détails.

Traps SNMP

Le package "net-snmp-perl", nécessaire pour les traps SNMP, a été supprimé dans RHEL 8.0-8.2 ; rajouté dans RHEL 8.3.

Donc, si vous utilisez RHEL 8.0-8.2, la meilleure solution consiste à effectuer une mise à niveau vers RHEL 8.3.

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

Plantage du processus Alerter dans RHEL 7

Des plantages des instances du processus d'alerte du serveur Zabbix ont été rencontrées dans RHEL 7. Veuillez consulter ZBX-10461 pour plus de détails.

Upgrading Zabbix agent 2 (6.0.5 or older)

When upgrading Zabbix agent 2 (version 6.0.5 or older) from packages, a plugin-related file conflict error may occur. To fix the error, back up your agent 2 configuration (if necessary), uninstall agent 2 and install it anew.

On RHEL-based systems, run:

dnf remove zabbix-agent2
       dnf install zabbix-agent2

On Debian-based systems, run:

apt remove zabbix-agent2
       apt install zabbix-agent2

For more information, see ZBX-23250.

Inverser les paramètres régionaux de l'interface web

Il a été observé que les paramètres régionaux de l'interface web peuvent basculer sans logique apparente, c'est-à-dire que certaines pages (ou parties de pages) sont affichées dans une langue tandis que d'autres pages (ou parties de pages) sont affichées dans une langue différente. En règle générale, 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é au fonctionnement de la définition des paramètres régionaux en PHP : les informations sur les paramètres régionaux sont conservées par processus, et non par thread. Ainsi, dans un environnement multi-thread, lorsque plusieurs projets sont exécutés par le même processus Apache, il est possible que les paramètres régionaux soient modifiés dans un autre thread et que cela modifie la façon dont les données peuvent être traitées dans le thread Zabbix.

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

• ZBX-10911 (Problème avec la bascule des paramètres régionaux de l'interface web)
• ZBX-16297 (Problème avec le traitement des nombres dans les graphiques en utilisant la fonction bcdiv des fonctions BC Math)

Configuration de l'opcache PHP 7.3

Si "opcache" est activé dans la configuration PHP 7.3, l'interface Zabbix peut afficher un écran vide lors du premier chargement. Il s'agit d'un bogue PHP enregistré. Pour contourner ce problème, veuillez définir le paramètre "opcache.optimization_level" sur 0x7FFFBFDF dans la configuration PHP (fichier php.ini).

Graphiques

Heure d'été

Les modifications apportées à l'heure d'été (DST) entraînent des irrégularités lors de l'affichage des étiquettes de l'axe X (double date, date manquante, etc.).

Agrégation de somme

Lors de l'utilisation de l'agrégation de 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 de tendances.

Surveillance des fichiers de log

Les éléments log[] et logrt[] relisent à plusieurs reprises le fichier journal depuis le début si le système de fichiers est plein à 100 % et que le fichier de log est en mode append (voir ZBX-10884 pour plus d'informations).

Requêtes MySQL lentes

Le serveur Zabbix génère des requêtes de sélection lentes en cas de valeurs inexistantes pour les éléments. Ceci est dû à un problème connu dans les versions MySQL 5.6/5.7. Une solution de contournement consiste à désactiver l'optimiseur index_condition_pushdown dans MySQL. Pour une discussion approfondie, voir ZBX-10652.

Slow configuration sync with Oracle

Configuration sync might be slow in Zabbix 6.0 installations with Oracle DB that have high number of items and item preprocessing steps. This is caused by the Oracle database engine speed processing nclob type fields.

To improve performance, you can convert the field types from nclob to nvarchar2 by manually applying the database patch items_nvarchar_prepare.sql. Note that this conversion will reduce the maximum field size limit from 65535 bytes to 4000 bytes for item preprocessing parameters and item parameters such as Description, Script item's field Script, HTTP agent item's fields Request body and Headers, Database monitor item's field SQL query. Queries to determine template names that need to be deleted before applying the patch are provided in the patch as a comment. Alternatively, if MAX_STRING_SIZE is set you can change nvarchar2(4000) to nvarchar2(32767) in the patch queries to set the 32767 bytes field size limit.

For an extended discussion, see ZBX-22363.

Connexion à l'API

Un grand nombre de sessions utilisateur ouvertes peuvent être créées lors de l'utilisation de scripts personnalisés avec la méthode user.login sans user.logout par la suite.

Persistent filter settings from links

When opening a link to Zabbix frontend page that contains filter settings, including the time selector, the filter is automatically saved in the database for the user, replacing the previously saved filter and/or time selector settings for that page. These settings remain active until the user manually updates or resets them.

Problème d'adresse IPv6 dans les traps SNMPv3

En raison d'un bogue 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, voir ZBX-14541.

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

Un message de tentative de connexion échouée n'affichera que les 39 premiers caractères d'une adresse IP stockée car c'est la limite de caractères dans le champ de 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 le paramètre Server du fichier de configuration de l'agent Zabbix (zabbix_agentd.conf) peut augmenter le temps de réponse de l'agent Zabbix sous Windows. Cela se produit parce que le démon de la mise en cache DNS de Windows ne met pas en cache les réponses négatives pour les adresses IPv4. Cependant, pour les adresses IPv6 les réponses négatives sont mises en cache, donc une solution de contournement possible sera de désactiver IPv4 sur l'hôte.

Exportation/importation YAML

Il existe des problèmes connus avec les exportations/importations 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 mises entre guillemets sont automatiquement converties en horodatages Unix.

Assistant de configuration sur SUSE avec NGINX et php-fpm

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

Deux options de contournement sont disponibles :

• Mettre l'option ProtectSystem à 'true' au lieu de 'full' dans l'unité systemd php-fpm.
• Enregistrer manuellement le fichier /etc/zabbix/web/zabbix.conf.php.

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 car /var/lib/zabbix est utilisé comme répertoire personnel de l'utilisateur 'zabbix'.

Codes d'erreur personnalisés MySQL

Si Zabbix est utilisé avec l'installation de MySQL sur Azure, un message d'erreur peu clair [9002] Some errors occurred peut apparaître dans les journaux Zabbix. Ce texte d'erreur générique est envoyé au serveur ou proxy Zabbix par la base de données. Pour obtenir plus d'informations sur la cause de l'erreur, consultez les journaux Azure.

Expressions régulières non valides 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 packages d'installation 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. Tout en offrant de nombreux avantages, le passage à PCRE2 peut rendre invalides ou se comporter différemment certains modèles d'expressions régulières PCRE existants. En particulier, cela affecte le modèle ^[\w-\.]. Afin de rendre cette expression régulière à nouveau valide sans affecter 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. Les packages d'installation Zabbix suivants ont été mis à jour et utilisent désormais PCRE2 : RHEL 7 et versions ultérieures, SLES (toutes les versions), Debian 9 et versions ultérieures, Ubuntu 16.04 et versions ultérieures.

Mauvaise conversion des services dans Zabbix 6.0.0-6.0.2

Dans Zabbix 6.0, de nouveaux algorithmes de calcul d'état de service plus flexibles ont été introduits.

Après une mise à niveau de Zabbix <6.0 vers Zabbix 6.0.0, 6.0.1, 6.0.2, les règles de calcul de l'état du service 'Le plus critique si tous les enfants ont des problèmes' et 'Le plus critique des services enfants' seront permutées. Les services créés dans Zabbix 6.0.0 et versions ultérieures auront des règles de calcul de statut correctes.

Lors de la mise à niveau des versions <6.0 vers Zabbix 6.0.3 ou plus récent, Zabbix mettra correctement à jour les règles de calcul de l'état du service. La mise à niveau de 6.0.x vers 6.0.3 n'aura aucun effet sur les règles de calcul de l'état du service.

Erreur du widget Geomap

Les cartes du widget Geomap peuvent ne pas se charger correctement si vous avez effectué une mise à niveau à partir d'une ancienne version de Zabbix avec NGINX et que vous n'êtes pas passé au nouveau fichier de configuration NGINX lors de la mise à niveau.

Pour résoudre le problème, vous pouvez supprimer l'ancien fichier de configuration, utiliser le fichier de configuration du package 6.0 et le reconfigurer comme décrit dans les instructions de téléchargement dans la section e. Configurer PHP pour l'interface 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; · }

Logrotate for Zabbix server and proxy

The logrotate utility is only included into packages for zabbix-agent, zabbix-agent2 and zabbix-web-service, but needs to be installed separately for Zabbix server and proxy. The logrotate dependency has been added to the server and proxy packages for RHEL and SUSE starting from Zabbix 6.4.4rc1.

Problèmes dans Zabbix 6.0.11

Erreurs d'analyse JSONPath

Des erreurs d'analyse JSONPath se produisent en cas d'espace blanc en tête et de tableau/objet vide. Corrigé dans Zabbix 6.0.12.

Évaluation ET/OU dans les filtres LLD

L'évaluation des expressions ET/OU dans les filtres/substitutions de découverte de bas niveau peut échouer dans cette version. Corrigé dans Zabbix 6.0.12.

Missing files in Windows agent archive

The Windows Zabbix agent download ZIP file is missing zabbix_sender.h and zabbix_sender.lib files in versions 6.0.0-6.0.27, required for zabbix_sender.dll.

Use case with global variables shared across webhook calls

As global variables are shared across different webhook calls, the following code will result in the tag value counter gradually increasing:

try 
       {
          aa = aa + 1;
       }
       catch(e)
       {
          aa = 0;
       }

       result = {
               'tags': {
                   'endpoint': aa
               }
           };
       return JSON.stringify(result);

Using local variables instead of global ones is recommended to make sure that each script operates on its own data and that there are no collisions between simultaneous calls.