Modifications incompatibles - modifications susceptibles de rompre les installations existantes et autres informations critiques liées au processus de mise à niveau
Autres - toutes les autres informations décrivant les changements dans les fonctionnalités de Zabbix

Voir aussi :

Procédure de mise à niveau pour toutes les informations pertinentes sur la mise à niveau depuis des versions antérieures à Zabbix 6.4.0 ;
Mise à niveau d'un cluster HA pour les instructions de mise à niveau des serveurs dans un cluster à haute disponibilité (HA).

Processus de mise à niveau

Pour mener à bien une mise à niveau du serveur Zabbix sur MySQL/MariaDB, il peut être nécessaire de définir GLOBAL log_bin_trust_function_creators = 1 dans MySQL si la journalisation binaire est activée, qu’aucun privilège de superutilisateur n’est disponible et que log_bin_trust_function_creators = 1 n’est pas défini dans le fichier de configuration MySQL.

Pour définir la variable à l’aide de la console MySQL, exécutez :

mysql> SET GLOBAL log_bin_trust_function_creators = 1;

Une fois la mise à niveau terminée avec succès, cette option peut être désactivée :

mysql> SET GLOBAL log_bin_trust_function_creators = 0;

Modifications incompatibles

Panne du serveur avec TimescaleDB après la mise à niveau vers 7.0.1 depuis 7.0.0

La mise à niveau vers Zabbix 7.0.1 (ou une version ultérieure) depuis Zabbix 7.0.0 avec TimescaleDB entraîne une panne du serveur. Ce problème est causé par une solution de contournement à un problème de tâche de compression dans la table auditlog de Zabbix 7.0, qui modifie de manière irréversible la stratégie de compression de la table auditlog.

Consultez les problèmes connus pour obtenir des détails sur la correction manuelle de la table auditlog.

Si vous n'avez pas encore effectué la mise à niveau vers Zabbix 7.0.0, notez qu'il ne devrait pas y avoir de tels problèmes lors des mises à niveau depuis des versions de Zabbix antérieures à 7.0 vers 7.0.1. Pour les instructions de mise à niveau, consultez Mise à niveau du schéma TimescaleDB.

Erreur de restauration de base de données avec PostgreSQL/TimescaleDB après une mise à niveau depuis 7.0.0-7.0.4

L’utilisation de pg_restore pour restaurer une sauvegarde PostgreSQL ou TimescaleDB créée dans Zabbix 7.0.0-7.0.4 entraînera une erreur indiquant l’absence de la fonction base36_decode, ce qui provoquera l’échec de la restauration. Cette erreur se produit lors de la restauration d’une sauvegarde créée avec pg_dump.

Consultez les problèmes connus pour obtenir des détails sur la correction manuelle de ce problème avant de créer la sauvegarde.

Si vous n’avez pas encore effectué la mise à niveau vers Zabbix 7.0.0, notez qu’il ne devrait pas y avoir de tels problèmes lors des mises à niveau depuis des versions de Zabbix antérieures à 7.0 vers 7.0.5. Pour les instructions de mise à niveau, consultez Mise à niveau du schéma TimescaleDB.

Version minimale requise de PHP

La version minimale requise de PHP a été relevée de 7.4.0 à 8.0.0.

Commandes à distance sur les agents actifs

Les commandes à distance peuvent désormais également être exécutées sur un agent 7.0 fonctionnant uniquement en mode actif.

Notez que pour les scripts exécutés uniquement sur un agent actif, il est probable que le délai d'attente par défaut du serveur ou du proxy doive être augmenté. Le délai d'attente du serveur/proxy doit être supérieur à la fréquence d'actualisation des vérifications actives, sinon le délai d'attente du serveur/proxy peut être dépassé avant même que l'agent actif ne reçoive le script.

Échappement des antislashs dans les paramètres des fonctions d'historique

Un échappement correct des antislashs a été ajouté dans les paramètres de chaîne des fonctions d'historique.

Comme des antislashs supplémentaires sont ajoutés lors de la mise à niveau depuis les versions de Zabbix antérieures à 7.0, cela entraîne des paramètres plus longs, ce qui peut provoquer des fonctions de déclencheur défectueuses si la longueur du paramètre dépasse la taille maximale des données de 255 caractères.

Pour éviter ce problème, il est conseillé de déplacer manuellement les paramètres longs dans des macros utilisateur avant la mise à niveau.

Notez que depuis Zabbix 7.0.11, des vérifications supplémentaires de la longueur du paramètre résultant ont été ajoutées pour les mises à niveau depuis les versions de Zabbix antérieures à 7.0. Si la longueur résultante dépasse la taille maximale, ces paramètres ne sont pas mis à niveau et un avertissement est affiché dans les journaux, demandant aux utilisateurs de corriger manuellement les paramètres listés.

Voir aussi problèmes de mise à niveau liés à l'échappement.

Emplacement par défaut du fichier de configuration de l'agent Windows

L'emplacement par défaut où l'agent Zabbix sous Windows recherche le fichier de configuration a été modifié. Désormais, l'agent le recherche dans le répertoire où se trouve le binaire de l'agent zabbix_agentd.exe (au lieu de C:\zabbix_agentd.conf, comme auparavant).

L'agent 2 Zabbix sous Windows recherchait déjà le fichier de configuration par défaut dans le répertoire où se trouve le binaire zabbix_agent2.exe. Cependant, dans la nouvelle version, l'agent 2 s'attend à ce que le fichier de configuration s'appelle zabbix_agent2.conf (au lieu de zabbix_agent2.win.conf).

Voir aussi: Installation de l'agent Zabbix sur Windows.

Valeurs vides autorisées dans la configuration du plugin agent 2

Les valeurs vides sont désormais autorisées dans les paramètres de configuration liés aux plugins sur Zabbix agent 2.

TimescaleDB 1.x n'est plus pris en charge

La prise en charge de TimescaleDB 1.x a été supprimée.

Types de données en double précision sur TimescaleDB

Avant de mettre à niveau vers Zabbix 7.0.0, il est nécessaire de mettre à niveau manuellement TimescaleDB pour utiliser des types de données en double précision si TimescaleDB est utilisé avec la compression. Vous pouvez déterminer si TimescaleDB n'utilise pas de types de données en double précision grâce à l'avertissement dans la section Informations système de l'interface ou dans le journal du serveur Zabbix : "Database is not upgraded to use double precision values. Support for the old numeric type will be removed in future versions."

Pour plus d'informations, consultez Mise à niveau vers des valeurs numériques de plage étendue.

Journal d'audit converti en hypertable sur TimescaleDB

La table auditlog a été convertie en hypertable sur TimescaleDB dans les nouvelles installations afin de bénéficier du partitionnement automatique par temps (7 jours par défaut) et de meilleures performances.

Pour mettre à niveau avec succès les installations existantes, consultez Mise à niveau du schéma TimescaleDB.

Voir aussi: Versions prises en charge de TimescaleDB

Table de base de données séparée pour les proxy

Les enregistrements de proxy ont été déplacés hors de la table hosts et sont désormais stockés dans la nouvelle table proxy.

De plus, les données opérationnelles des proxy (telles que le dernier accès, la version, la compatibilité) ont été déplacées hors de la table host_rtdata et sont désormais stockées dans la nouvelle table proxy_rtdata.

Il existe également un nouvel objet proxy dans l'API. Toutes les opérations avec les proxy doivent être mises à jour pour être effectuées via ce nouvel objet proxy.

Délai d'exécution des requêtes pour les éléments de surveillance de base de données

En fonction des modifications apportées à la configuration du délai d'attente des éléments, le délai d'attente de connexion ODBC et le délai d'exécution des requêtes pour les éléments de surveillance de base de données sont désormais limités à la valeur du paramètre Timeout définie dans le formulaire de configuration de l'élément.

Éléments agent/agent2 mis à jour

wmi.get et wmi.getall, lorsqu'ils sont utilisés avec Zabbix agent 2, renvoient désormais un JSON avec des valeurs booléennes représentées sous forme de chaînes (par exemple, "RealTimeProtectionEnabled": "True" au lieu de "RealTimeProtectionEnabled": true renvoyé précédemment) afin de correspondre au format de sortie de ces éléments sur Zabbix agent ;
oracle.ts.stats dispose d'un nouveau paramètre conname pour spécifier le nom du conteneur cible. Le format JSON des données renvoyées a été mis à jour. Lorsque tablespace, type ou conname n'est spécifié dans les paramètres de la clé, les données renvoyées incluront un niveau JSON supplémentaire avec le nom du conteneur, ce qui permet de différencier les conteneurs.
Les éléments net.dns.* ne peuvent plus être configurés sans le paramètre name. Bien qu'il soit toujours indiqué comme obligatoire, le paramètre name, s'il était omis, était auparavant résolu avec une valeur par défaut (zabbix.com), ce qui n'est plus le cas.

Pour la liste des modifications d'éléments qui ne rompent pas la compatibilité, voir Nouveautés de Zabbix 7.0.0.

Traps SNMP avec la haute disponibilité Zabbix

Zabbix peut désormais lire les fichiers de traps SNMP depuis l'emplacement correct lorsque le nœud actif est basculé dans une configuration à haute disponibilité.

Cependant, pour que cette fonctionnalité fonctionne, il est nécessaire de mettre à jour le format de l'heure dans tous les scripts bash, perl et SNMPTT en "%Y-%m-%dT%H:%M:%S%z" (c'est-à-dire 2024-01-10T11:56:14+0300).

Augmentation de la taille maximale et du nombre de widgets du tableau de bord

La largeur par défaut a été multipliée par 3 pour tous les widgets. Notez que si vous utilisez des widgets personnalisés, vous devrez peut-être mettre à jour les paramètres correspondants du fichier manifest.json (par exemple, lors de la configuration d'un widget Clock personnalisé, width doit être modifié de 4 à 12).

Un widget peut désormais avoir une largeur allant jusqu'à 72 colonnes (contre 24 auparavant) et une hauteur de 1 à 64 lignes (contre 2 à 32 auparavant). Le tableau de bord peut donc désormais contenir jusqu'à 72 widgets horizontalement.

Historique des éléments et widgets Texte brut

Le nouveau widget de tableau de bord Historique des éléments a remplacé le widget Texte brut, en offrant plusieurs améliorations.

Contrairement au widget Texte brut, qui affichait uniquement les dernières données de l'élément en texte brut, le widget Historique des éléments prend en charge diverses options d'affichage pour plusieurs types d'éléments (numérique, caractère, journal, texte et binaire). Par exemple, il peut afficher des barres de progression ou des indicateurs, des images pour les types de données binaires (utile pour les éléments de navigateur), et mettre en évidence les valeurs textuelles (utile pour la surveillance des fichiers journaux).

Après la mise à niveau, tous les widgets Texte brut précédemment configurés seront automatiquement remplacés par des widgets Historique des éléments, en conservant les mêmes paramètres de configuration. Cependant, tous les scripts API faisant référence au widget Texte brut doivent être mis à jour manuellement.

Modifications dans la résolution de certaines macros intégrées après la mise à niveau vers 7.0.4

Dans Zabbix 7.0.4, le comportement de résolution des macros {HOST.CONN}, {HOST.DNS}, {HOST.IP}, {EVENT.CAUSE.*}, {EVENT.TAGS.*} et {EVENT.SYMPTOMS} a été corrigé afin d’être cohérent avec celui des autres macros intégrées. Désormais, elles seront résolues en *UNKNOWN* si une erreur se produit lors de l’évaluation de leur valeur.

À la suite de cette modification, afin de garantir le bon fonctionnement, il est nécessaire de mettre à jour les types de média pour les intégrations suivantes : iTop, Jira Service Desk, ManageEngine ServiceDesk, SolarWinds Service Desk.

Cette modification peut également affecter tous les scripts personnalisés ou intégrations utilisant les macros mentionnées ci-dessus.

Modifications de l'API

Consultez la liste des modifications de l'API dans Zabbix 7.0.0.

Autres

Oracle DB obsolète

La prise en charge d'Oracle en tant que base de données backend est obsolète depuis Zabbix 7.0 et devrait être complètement supprimée dans les versions futures.

Vérification des mises à jour logicielles

Une vérification des mises à jour logicielles est désormais ajoutée par défaut aux nouvelles installations et aux installations existantes - l'interface Zabbix communiquera avec le point de terminaison public Zabbix pour vérifier les mises à jour.

Vous pouvez désactiver cette vérification en définissant AllowSoftwareUpdateCheck=0 dans la configuration du serveur.

Valeurs à virgule flottante tronquées pour les éléments entiers

Désormais, si une valeur à virgule flottante est reçue pour un élément entier non signé, la partie décimale de la valeur sera supprimée et la valeur sera enregistrée comme un entier. Auparavant, une valeur à virgule flottante rendait un élément entier non pris en charge.

Format de l'heure US

Les affichages de l'heure et de la date dans l'interface sont désormais conformes au format standard américain d'affichage de l'heure et de la date lorsque la langue par défaut de l'interface (en_US) est utilisée.

Before	Now

Pollers asynchrones

Après la mise à niveau, toutes les vérifications agent, agent HTTP et walk[OID] SNMP seront déplacées vers les pollers asynchrones. Les nouveaux éléments get[OID] ajoutés utilisent les pollers asynchrones par défaut.

Détection des fonctionnalités de la bibliothèque cURL à l'exécution

Auparavant, les fonctionnalités de la bibliothèque cURL étaient détectées au moment de la compilation du serveur, du proxy ou de l'agent Zabbix. Si les fonctionnalités de cURL étaient mises à niveau, il fallait recompiler le composant Zabbix concerné pour pouvoir en tirer parti.

Désormais, un simple redémarrage suffit pour que les fonctionnalités mises à niveau de la bibliothèque cURL soient disponibles dans Zabbix. La recompilation n'est plus nécessaire. Cela s'applique au serveur, au proxy et à l'agent Zabbix.

De plus :

La version minimale requise de cURL au moment de la compilation a été portée à 7.19.1 ;
Lors de la compilation, Zabbix vérifie simplement si la bibliothèque cURL est disponible (si cela est demandé) et si elle satisfait à l'exigence de version ;
Lorsqu'une erreur de bibliothèque cURL est signalée à l'exécution, la version utilisée sera ajoutée (par exemple, "cURL library does not support SSL/TLS (using version 7.88.1)") ;
Lorsque le serveur Zabbix démarre et que l'authentification SMTP est journalisée, il écrit la disponibilité de l'authentification SMTP de la bibliothèque cURL utilisée.

Modifications de la configuration du délai d'expiration des éléments

Lors de la mise à niveau, les délais d'expiration globaux pour tous les types d'éléments pris en charge seront définis en fonction de la valeur du paramètre Timeout dans le fichier de configuration du serveur. Si un proxy est configuré, il utilisera par défaut les paramètres de délai d'expiration globaux du serveur.

Lors de l'utilisation d'un serveur mis à niveau (version 7.0.0 ou ultérieure) avec un proxy ou un agent plus ancien, le proxy ou l'agent fonctionnera comme auparavant :

le proxy utilisera le paramètre Timeout du fichier de configuration du proxy ;
l'agent utilisera le paramètre Timeout du fichier de configuration de l'agent.

Les paramètres de délai d'expiration ont été supprimés des fichiers de configuration des plugins Modbus et MQTT. Les délais d'exécution des requêtes peuvent désormais être définis à l'aide du formulaire de configuration de l'élément.

Éléments navigateur

Un nouveau type d'élément - élément navigateur - a été ajouté à Zabbix, permettant la supervision de sites web et d'applications web complexes à l'aide d'un navigateur. Les éléments navigateur permettent l'exécution de code JavaScript défini par l'utilisateur afin de simuler des actions liées au navigateur, telles que cliquer, saisir du texte, naviguer dans des pages web, etc.

De plus, cette fonctionnalité ajoute les modifications suivantes :

le modèle Website by Browser a été ajouté aux modèles fournis par défaut ;
le type d'élément ITEM_TYPE_BROWSER (22) a été ajouté à l'export/import de configuration des éléments de modèle ou d'hôte, des règles de découverte de bas niveau et des prototypes d'élément ;
les paramètres de fichier de configuration Zabbix StartBrowserPollers et WebDriverURL du serveur/proxy ont été ajoutés ;
le délai d'attente des éléments navigateur a été ajouté aux délais d'attente du proxy ou aux délais d'attente globaux (si aucun proxy n'est utilisé) ;
le paramètre de ligne de commande -w <webdriver url> pour activer la supervision par navigateur a été ajouté à l'utilitaire en ligne de commande zabbix_js.

Concurrence dans la découverte réseau

Dans la nouvelle version, le processus de découverte réseau a été remanié afin de permettre l’exécution concurrente des vérifications de service.
Un nouveau processus de gestionnaire de découverte a été ajouté, ainsi qu’un nombre configurable de workers de découverte (ou threads). Le processus de gestionnaire de découverte traite les règles de découverte et crée une tâche de découverte pour chaque règle avec des tâches (vérifications de service). Les vérifications de service sont prises en charge et exécutées par les workers de découverte.

Le paramètre StartDiscoverers détermine désormais le nombre total de workers de découverte disponibles pour la découverte.
Le nombre par défaut de StartDiscoverers a été augmenté de 1 à 5, et la plage de 0-250 à 0-1000. Les processus discoverer des versions précédentes de Zabbix ont été supprimés.

De plus, le nombre de workers disponibles par règle est désormais configurable dans l’interface. Ce paramètre est facultatif.
Lors de la mise à niveau, il sera défini sur "One", comme dans les versions précédentes de Zabbix.

Icônes remplacées par des polices

Toutes les icônes de l'interface ont été remplacées par des feuilles d'images d'icônes au profit de polices.

Filtre des dernières données

Dans Monitoring → Dernières données, le sous-filtre et les données ne sont plus affichés par défaut si le filtre n'est pas défini. Notez toutefois que les filtres enregistrés précédemment, qui ont été définis en utilisant uniquement le sous-filtre, ne sont pas affectés. Dans ce cas, le sous-filtre restera visible et les données seront affichées même si le filtre principal n'est pas défini.

Paramètres de configuration

La valeur par défaut de plusieurs paramètres de configuration a été modifiée :

Le paramètre de configuration BufferSize pour Zabbix agent 2 a été augmenté de 100 à 1000 ;
Le paramètre de configuration Plugins.<PluginName>.System.Capacity pour Zabbix agent 2 a été augmenté de 100 à 1000 (maximum). Notez que le paramètre Plugins.<PluginName>.Capacity, obsolète dans Zabbix 6.0, a été complètement supprimé ;
Le paramètre de configuration StartAgents pour Zabbix agent a été augmenté de 3 à 10. Notez que, selon le paquetage, pour les systèmes plus petits (par exemple Raspberry Pi), la valeur par défaut peut rester à 3.

Ces changements n'affectent pas les installations existantes où ces paramètres sont explicitement définis.

Calculs agrégés

Plusieurs fonctions d'agrégation ont été mises à jour. Désormais :

Les fonctions d'agrégation prennent également en charge les types non numériques pour le calcul. Cela peut être utile, par exemple, avec les fonctions count et count_foreach.
Les fonctions d'agrégation count et count_foreach prennent en charge les paramètres facultatifs operator et pattern, qui peuvent être utilisés pour affiner le filtrage des éléments et ne compter que les valeurs correspondant aux critères donnés.
Toutes les fonctions foreach n'incluent plus les éléments non pris en charge dans le calcul.
La fonction last_foreach, auparavant configurée pour ignorer l'argument de période de temps, l'accepte désormais comme paramètre facultatif.

Ancien type de valeur numérique (float) supprimé

Depuis Zabbix 5.0, le type de données numérique (float) prend en charge une précision d'environ 15 chiffres et une plage allant d'environ -1.79E+308 à 1.79E+308. L'ancien type numérique était désactivé, mais restait pris en charge. À partir de Zabbix 6.4, il a été déprécié, et depuis Zabbix 7.0, il a été entièrement supprimé.

Si votre installation n'a pas été mise à niveau pour utiliser des valeurs numériques à plage étendue, l'avertissement suivant s'affiche dans Rapports → Informations système : "Database history tables upgraded: No. Support for the old numeric type is deprecated. Please upgrade to numeric values of extended range".

Lors de la mise à niveau vers Zabbix 7.0, les bases de données suivantes sont mises à niveau automatiquement :

MySQL
PostgreSQL/TimescaleDB (sans compression)
Oracle

Cependant, pour Oracle, les anciennes versions de MySQL et les grandes installations, il est recommandé de mettre à niveau manuellement le type de données avant de passer à Zabbix 7.0.

Pour TimescaleDB avec compression, la base de données doit être mise à niveau manuellement.

Pour plus de détails sur la mise à niveau, consultez Mise à niveau vers des valeurs numériques à plage étendue.

Définition du type de démarrage du service agent Windows

L'option permettant de définir le type de démarrage du service Windows Zabbix agent/agent 2 (-S --startup-type) a été ajoutée. Cette option permet de configurer le service agent/agent 2 pour qu'il démarre automatiquement au démarrage de Windows (automatic), après la fin du démarrage des services lancés automatiquement (delayed), lorsqu'il est démarré manuellement par un utilisateur ou une application (manual) ou pour désactiver complètement le service (disabled).

Lors de l'installation de l'agent Windows à partir du MSI, le type de démarrage par défaut sur Windows Server 2008/Vista et les versions ultérieures est désormais delayed s'il n'est pas spécifié autrement dans le paramètre de ligne de commande STARTUPTYPE. Cela améliore la fiabilité et les performances du service Windows Zabbix agent/agent 2, en particulier lors des redémarrages du système.

Modèles

Pour les nouveaux modèles et les modifications apportées aux modèles existants, consultez Modifications des modèles.

Nouvelle structure de répertoires pour les fichiers liés à la base de données

Lors de l'installation de Zabbix à partir des paquets et de la préparation du schéma de base de données, l'emplacement des fichiers liés à la base de données a changé afin de mieux correspondre à la structure des fichiers dans les sources :

Les fichiers d'initialisation de base (schema.sql, data.sql, images.sql) se trouvent à la racine du répertoire de la base de données.
Les fichiers/patchs facultatifs pour la mise à niveau des tables de base de données se trouvent dans le répertoire option-patches.
Les extensions et modules complémentaires de base de données sont désormais des sous-répertoires, nommés d'après l'extension et situés dans le répertoire de base de données correspondant.
Modifications spécifiques à TimescaleDB :
- L'abréviation tsdb a été remplacée par timescaledb.
- Le répertoire option-patches inclut les sous-répertoires with-compression et without-compression ; ceux-ci contiennent des fichiers/patchs facultatifs pour la mise à niveau des tables de base de données en fonction des paramètres de compression TimescaleDB.
- Le fichier de création du schéma hypertable pour TimescaleDB a été déplacé vers database/postgresql/timescaledb/schema.sql.

Veuillez également noter les changements suivants :

Tous les fichiers history_pk_*.sql ont été renommés en history_upgrade_*.sql, et un fichier trends_upgrade.sql a été ajouté pour améliorer les scripts de mise à niveau de la base de données.
Le fichier double.sql a été supprimé en raison de la suppression de l'ancien type de valeur numérique (float).

Vous trouverez ci-dessous une comparaison de l'ancienne et de la nouvelle structure de répertoires pour les bases de données MySQL et PostgreSQL.

# Previous:                                         # Current:

database                                            database
├── mysql                                           ├── mysql
│  ├── data.sql                                     │  ├── option-patches
│  ├── double.sql                                   │  │  └── history_upgrade_prepare.sql
│  ├── history_pk_prepare.sql                       │  ├── data.sql
│  ├── images.sql                                   │  ├── images.sql
│  └── schema.sql                                   │  └── schema.sql
│                                                   │
│                                                   │
├── postgresql                                      ├── postgresql
│  ├── tsdb_history_pk_upgrade_no_compression       │  ├── option-patches
│  │  ├── history_pk.sql                            │  │  └── history_upgrade_prepare.sql
│  │  ├── history_pk_log.sql                        │  ├── timescaledb
│  │  ├── history_pk_str.sql                        │  │  ├── option-patches
│  │  │  ├── with-compression
│  │  │  │  ├── history_upgrade.sql
│  │  │  │  ├── history_upgrade_log.sql
│  │  │  │  ├── history_upgrade_str.sql
│  │  │  │  ├── history_upgrade_text.sql
│  │  │  │  ├── history_upgrade_uint.sql
│  │  │  │  └── trends_upgrade.sql
│  │  │  └── without-compression
│  │  │     ├── history_upgrade.sql
│  │  │     ├── history_upgrade_log.sql
│  │  │     ├── history_upgrade_str.sql
│  │  │     ├── history_upgrade_text.sql
│  │  │     ├── history_upgrade_uint.sql
│  │  │     └── trends_upgrade.sql
│  │  └── schema.sql
│  ├── data.sql                                     │  ├── data.sql
│  ├── images.sql                                   │  ├── images.sql
│  └── schema.sql                                   │  └── schema.sql
├── ...                                             ├── ...

Veuillez mettre à jour vos scripts, le cas échéant, s'ils contiennent des références à l'ancienne structure de répertoires ou aux anciens fichiers.

Protocole JSON pour les vérifications passives de l'agent

Un protocole basé sur JSON pour les vérifications passives de l'agent a été implémenté.

Pour assurer la compatibilité avec les anciens agents, un basculement vers l'ancien protocole en texte brut a été ajouté. Si l'agent renvoie "ZBX_NOTSUPPORTED", Zabbix mettra en cache l'interface comme utilisant l'ancien protocole et réessaiera la vérification en envoyant uniquement la clé d'élément en texte brut.

Zabbix get peut désormais être exécuté avec une nouvelle option -P --protocol <value> où "value" est l'une des suivantes :

auto - se connecter en utilisant le protocole JSON, puis basculer et réessayer avec le protocole en texte brut (par défaut) ;
json - se connecter en utilisant la clé du protocole JSON ;
plaintext - se connecter en utilisant le protocole en texte brut, où seule la clé d'élément est envoyée.

Si une clé d'élément n'est pas prise en charge, Zabbix get renverra désormais le code de sortie 1 au lieu de 0.

What’s next?

12 Notes de mise à niveau pour 7.0.1

Docs

11 Notes de mise à niveau pour 7.0.0