Par défaut, une vérification de mise à jour a été rajoutée pour les nouvelles installations ainsi que les installations existantes - Le frontend Zabbix communiquera avec les serveurs publics Zabbix pour vérifier les mises à jour.

Les informations liées aux mises à jour Zabbix sont affichéee dans Rapports -> Information système et (optionnellement) dans le widget Information système widget.

Vous pouvez désactiver la vérification des mises à jour avec le paramètre AllowSoftwareUpdateCheck=0 dans configuration du serveur.

Interrogateurs asynchrones

De nouveaux processus d'interrogation ont été ajoutés, capables d'exécuter plusieurs vérifications en même temps :

agent poller
http agent poller
snmp poller (pour les éléments walk[OID] et get[OID])

Ces interrogateurs sont asynchrones - ils sont capables de lancer de nouvelles vérifications sans avoir à attendre une réponse, avec une concurrence configurable jusqu'à 1000 vérifications simultanées.

Les interrogateurs asynchrones ont été développés car, à l'inverse, les processus d'interrogation synchrones ne peuvent exécuter qu'une seule vérification à la fois et passent la majeure partie de leur temps à attendre la réponse. L'efficacité peut donc être améliorée en lançant de nouvelles vérifications parallèles pendant l'attente de la réponse réseau, et les nouveaux interrogateurs le font.

Vous pouvez démarrer les interrogateurs asynchrones d'agent en modifiant la valeur de StartAgentPollers - un nouveau paramètre du serveur/proxy. Les interrogateurs HTTP agent peuvent être démarrés en modifiant respectivement StartHTTPAgentPollers. Les interrogateurs SNMP peuvent être démarrés en modifiant respectivement StartSNMPPollers.

La concurrence maximale pour les interrogateurs asynchrones (agent, HTTP agent et SNMP) est définie par MaxConcurrentChecksPerPoller.

Notez qu'après la mise à niveau, toutes les vérifications walk[OID] d'agent, HTTP agent et SNMP seront déplacées vers les interrogateurs asynchrones.

Dans le cadre du développement, la fonctionnalité de connexions persistantes cURL a été ajoutée aux vérifications HTTP agent.

Surveillance du navigateur

Un nouveau type d'élément - élément de navigateur - a été ajouté à Zabbix, permettant la surveillance de sites web et d'applications web complexes à l'aide d'un navigateur. Les éléments de 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.

Cet élément collecte des données via HTTP/HTTPS et implémente partiellement la norme W3C WebDriver avec Selenium Server ou un WebDriver simple (par exemple, ChromeDriver) comme point de terminaison de test.

Notez que la prise en charge des éléments de navigateur est actuellement expérimentale.

De plus, cette fonctionnalité ajoute le modèle Website by Browser et de nouveaux éléments à l'export/import de configuration, aux fichiers de configuration du serveur/proxy Zabbix, aux délais d'attente, ainsi qu'à l'utilitaire en ligne de commande zabbix_js. Pour plus d'informations, consultez les notes de mise à niveau vers 7.0.0.

Équilibrage de charge et haute disponibilité des proxy

L’équilibrage de charge des proxy est mis en œuvre grâce à l’introduction de groupes de proxy dans Zabbix. Les groupes de proxy assurent la répartition automatique des hôtes entre les proxy, le rééquilibrage de la charge des proxy et la haute disponibilité : lorsqu’un proxy se met hors ligne, ses hôtes sont immédiatement répartis entre les autres proxy du groupe.

Pour plus d’informations, consultez l’équilibrage de charge et la haute disponibilité des proxy.

Tampon mémoire du proxy

Un tampon mémoire a été développé pour le proxy Zabbix. Le tampon mémoire permet de stocker les nouvelles données (valeurs d'éléments, découverte réseau, enregistrement automatique des hôtes) dans le tampon et de les envoyer au serveur Zabbix sans accéder à la base de données.

Dans les installations antérieures à Zabbix 7.0, les données collectées étaient stockées dans la base de données avant d'être envoyées au serveur Zabbix. Pour ces installations, ce comportement reste celui par défaut après la mise à niveau.

Pour optimiser les performances, il est recommandé de configurer l'utilisation du tampon mémoire sur le proxy. Cela est possible en modifiant la valeur de ProxyBufferMode, de « disk » (valeur par défaut codée en dur pour les installations existantes) à « hybrid » (recommandé) ou « memory ». Il est également nécessaire de définir la taille du tampon mémoire (paramètre ProxyMemoryBufferSize).

En mode hybride, le tampon est protégé contre la perte de données grâce à l'enregistrement des données non envoyées dans la base de données si le proxy est arrêté, si le tampon est plein ou si les données sont trop anciennes. Lorsque toutes les valeurs ont été enregistrées dans la base de données, le proxy recommence à utiliser le tampon mémoire.

En mode mémoire, le tampon mémoire est utilisé, mais aucune protection contre la perte de données n'est assurée. Si le proxy est arrêté ou si la mémoire est saturée, les données non envoyées sont supprimées.

Le mode hybride (ProxyBufferMode=hybrid) est appliqué à toutes les nouvelles installations depuis Zabbix 7.0.

Des paramètres supplémentaires tels que ProxyMemoryBufferSize et ProxyMemoryBufferAge définissent respectivement la taille du tampon mémoire et l'ancienneté maximale des données dans le tampon.

De nouveaux éléments internes ont été ajoutés pour surveiller le tampon mémoire du proxy.

Provisionnement JIT des utilisateurs

Auparavant, les utilisateurs provisionnés étaient limités aux médias créés lors du provisionnement, sans possibilité de modifier des propriétés telles que les heures d'activité ou les niveaux de gravité.

Désormais, les utilisateurs provisionnés disposent de davantage de flexibilité dans Zabbix :

les médias utilisateur provisionnés peuvent être désactivés/activés ;
les champs des médias utilisateur provisionnés, tels que Actif pendant, Utiliser si la gravité et Activé, peuvent être modifiés manuellement ;
des médias utilisateur supplémentaires peuvent être ajoutés manuellement pour les utilisateurs provisionnés (par exemple, des adresses e-mail supplémentaires) ;
les médias utilisateur ajoutés manuellement peuvent être supprimés (les médias utilisateur provisionnés ne peuvent pas l'être).

De plus, lors de la configuration du mappage des médias utilisateur pour le provisionnement, des champs tels que Actif pendant, Utiliser si la gravité et Activé sont désormais disponibles. Notez que les modifications apportées au formulaire de mappage des types de médias utilisateur ne prendront effet que pour les nouveaux médias créés lors du provisionnement.

Délais d'attente configurables par élément

La configuration des délais d'attente par élément est désormais disponible pour davantage de types d'éléments (voir les types d'éléments pris en charge). En plus de définir les valeurs de délai d'attente au niveau de l'élément, il est possible de définir des délais d'attente globaux et de proxy pour différents types d'éléments.

Les délais d'attente configurés au niveau de l'élément ont la priorité la plus élevée. Par défaut, les délais d'attente globaux s'appliquent à tous les éléments ; toutefois, si des délais d'attente de proxy sont définis, ils remplacent les délais globaux.

Oracle DB obsolète

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

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 met en cache l'interface utilisant l'ancien protocole et réessaie la vérification en envoyant uniquement la clé de l'élément en texte brut.

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

auto - se connecter à l'aide du protocole JSON, puis basculer vers le protocole en texte brut et réessayer (valeur par défaut) ;
json - se connecter à l'aide de la clé du protocole JSON ;
plaintext - se connecter à l'aide du protocole en texte brut, dans lequel seule la clé de l'élément est envoyée.

Si une clé d'élément n'est pas prise en charge, Zabbix get renvoie le code de sortie 1.

Protocoles unifiés de l'agent/agent2

Les protocoles de l'agent Zabbix et de l'agent 2 ont été unifiés en faisant passer l'agent Zabbix au protocole de l'agent 2 Zabbix. La différence entre les requêtes/réponses de l'agent Zabbix et de l'agent 2 Zabbix est exprimée par la valeur de la balise « variant » (« 1 » - agent Zabbix, « 2 » - agent 2 Zabbix).

Voir aussi : Vérifications passives et actives de l'agent.

Prise en charge des intervalles flexibles/de planification dans les vérifications actives

Les intervalles flexibles/de planification sont désormais pris en charge dans les vérifications actives par Zabbix agent et Zabbix agent 2 (auparavant uniquement par Zabbix agent 2).

Désactivation automatique des ressources perdues

Les ressources qui ne sont plus découvertes par la découverte de bas niveau peuvent désormais être désactivées automatiquement. Elles peuvent être désactivées immédiatement, après une période spécifiée ou jamais (voir le nouveau paramètre Désactiver les ressources perdues dans la configuration de la règle de découverte).

Les ressources perdues (hôtes, éléments, déclencheurs) sont signalées par une icône dans la colonne d’informations. Le texte de l’infobulle fournit des détails sur leur état.

Dans le cadre du même développement, le paramètre Conserver les ressources perdues pendant a été renommé Supprimer les ressources perdues, avec des options permettant de les supprimer immédiatement, après une période spécifiée ou jamais.

Envoi de données au serveur Zabbix via l’API Zabbix

Auparavant, l’envoi de données spécifiques au serveur Zabbix était possible à l’aide de l’utilitaire Zabbix sender ou en implémentant un protocole de communication personnalisé basé sur JSON, similaire à celui utilisé par Zabbix sender.

Il est désormais également possible d’envoyer des données au serveur Zabbix via le protocole HTTP à l’aide de la méthode d’API history.push. Notez que la réception des données envoyées nécessite un élément trapper configuré ou un élément agent HTTP (avec la capture activée).

En outre, les opérations history.push correctes sont enregistrées dans Rapports → Journal d’audit, qui dispose d’options de filtrage supplémentaires (une nouvelle action Push et la ressource History). La méthode d’API history.push est également disponible dans la Liste d’autorisation/de refus des méthodes d’API lors de la configuration d’un rôle utilisateur.

Scripts

Exécution de scripts sur les agents actifs

Il est désormais possible d'exécuter des scripts sur les agents fonctionnant en mode actif. Lorsque l'exécution du script est déclenchée par une opération d'action ou par l'exécution manuelle d'un script, la commande est incluse dans la configuration des vérifications actives et exécutée dès que l'agent actif la reçoit.

Les scripts manuels sont envoyés à l'agent actif avec le délai d'expiration du serveur/proxy pour l'exécution des scripts. Veuillez augmenter le délai d'expiration par défaut du serveur/proxy pour l'exécution des scripts. Le délai d'expiration doit être supérieur à la fréquence d'actualisation des vérifications actives ; sinon, il est dépassé avant que l'agent actif ne reçoive le script et puisse renvoyer le résultat.

Notez que les agents actifs plus anciens ignorent toutes les commandes distantes incluses dans la configuration des vérifications actives. Pour plus d'informations, consultez Vérifications passives et actives de l'agent.

Saisie manuelle par l'utilisateur pour les scripts

La saisie manuelle par l'utilisateur pour les scripts de l'interface permet de fournir un paramètre personnalisé à chaque exécution du script. Cela évite de devoir créer plusieurs scripts utilisateur similaires ne différant que par un seul paramètre.

Par exemple, vous pouvez vouloir fournir un entier différent ou une autre adresse URL au script lors de son exécution.

Pour activer la saisie manuelle par l'utilisateur :

utilisez la macro {MANUALINPUT} dans le script (commandes, script, paramètre du script) là où cela est nécessaire ; ou dans le champ URL des scripts URL ;
dans la configuration avancée du script, activez la saisie manuelle par l'utilisateur et configurez les options de saisie :

Lorsque la saisie utilisateur est activée, une fenêtre contextuelle Saisie manuelle s'affiche avant l'exécution du script, demandant à l'utilisateur de fournir une valeur personnalisée. La valeur fournie remplace {MANUALINPUT} dans le script.

Selon la configuration, l'utilisateur devra saisir une valeur textuelle ou la sélectionner dans une liste déroulante d'options prédéfinies.

Performance

Réaction plus rapide aux mises à jour des périodes de maintenance des hôtes

Auparavant, les maintenances étaient recalculées uniquement toutes les minutes, ce qui pouvait entraîner une latence allant jusqu'à 60 secondes avant le démarrage ou l'arrêt d'une période de maintenance.

Désormais, les maintenances sont toujours recalculées toutes les minutes ou dès que le cache de configuration est rechargé si des modifications ont été apportées à la période de maintenance.

Chaque seconde, le processus timer vérifie si des maintenances doivent être démarrées ou arrêtées, en fonction de la présence de modifications apportées aux périodes de maintenance après la mise à jour de la configuration. Ainsi, la rapidité de démarrage ou d'arrêt des périodes de maintenance dépend de l'intervalle de mise à jour de la configuration (10 secondes par défaut). Notez que les modifications des périodes de maintenance n'incluent pas les paramètres Active since/Active till. De plus, si un hôte ou un groupe d'hôtes est ajouté à une période de maintenance active existante, les modifications ne seront activées par le processus timer qu'au début de la minute suivante.

Vérifications des permissions plus rapides

Les vérifications des permissions sont désormais beaucoup plus rapides grâce à l’introduction de plusieurs tables intermédiaires pour vérifier les permissions des utilisateurs non privilégiés.

Ces tables conservent les hachages (SHA-256) des ensembles de groupes d’utilisateurs et des ensembles de groupes d’hôtes pour chaque utilisateur et chaque hôte, respectivement. De plus, une table des permissions stocke uniquement les combinaisons accessibles d’utilisateurs et d’hôtes, spécifiées par les identifiants de hachage.

Cette amélioration accélère considérablement le chargement des pages de l’interface nécessitant de nombreuses permissions (c’est-à-dire les hôtes et les problèmes). Notez que les hachages et les permissions ne sont pas calculés pour les utilisateurs Super-admin.

Exécution plus rapide des actions de déclencheur

L'exécution de l'opération de action de déclencheur, de l'opération de récupération et de l'opération de mise à jour sur le serveur Zabbix se produit désormais immédiatement (moins de 100 millisecondes) après un changement d'état du déclencheur, alors qu'auparavant les utilisateurs pouvaient subir jusqu'à 4 secondes de latence.

La réduction de la latence est rendue possible par la mise en œuvre de mécanismes de communication interprocessus (IPC) entre plusieurs processus (escalator et son module de distribution des escalades, escalator et alerter, gestionnaire de prétraitement et synchroniseur d'historique).

Widgets

Plusieurs nouveaux widgets ont été ajoutés dans la nouvelle version, tandis que les fonctionnalités disponibles dans d'autres ont été améliorées. De plus, les widgets des tableaux de bord peuvent désormais se connecter et communiquer entre eux, ce qui rend les widgets et les tableaux de bord plus dynamiques.

Jauge

Un widget Jauge a été ajouté aux widgets de tableau de bord, permettant d'afficher la valeur d'un seul élément sous forme de jauge. Pour plus d'informations, consultez Jauge.

Diagramme circulaire

Un widget Diagramme circulaire a été ajouté aux widgets du tableau de bord, permettant d'afficher les valeurs des éléments sélectionnés sous forme de :

graphique en camembert ;
graphique en anneau.


Diagramme circulaire.	Graphique en anneau.

Pour plus d'informations, voir Diagramme circulaire.

Dans le cadre de ce développement, une case à cocher Afficher la fonction d'agrégation a été ajoutée à la configuration du widget graphique (dans l'onglet Légende).

Honeycomb

Un widget Honeycomb a été ajouté aux widgets du tableau de bord, offrant une vue d'ensemble dynamique et vivante de l'infrastructure réseau et des ressources surveillées, où les groupes d'hôtes, tels que les machines virtuelles et les périphériques réseau, ainsi que leurs éléments respectifs, sont représentés visuellement sous forme de cellules hexagonales interactives. Pour plus d'informations, consultez Honeycomb.

Principaux déclencheurs

Un widget Principaux déclencheurs a été ajouté aux widgets des tableaux de bord. Il permet d'afficher les déclencheurs ayant le plus grand nombre de problèmes.

Pour plus d'informations, consultez : Principaux déclencheurs.

Historique des éléments et texte brut

Le nouveau widget de tableau de bord Historique des éléments a remplacé le widget Texte brut et offre 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 différentes 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 navigateur) et mettre en évidence les valeurs textuelles (utile pour la surveillance des fichiers journaux).

Pour plus d'informations, consultez Historique des éléments. Pour plus de détails sur le remplacement du widget Texte brut, consultez les Notes de mise à niveau vers la version 7.0.0.

Navigateur d'hôtes et navigateur d'éléments

Les widgets Navigateur d'hôtes et Navigateur d'éléments ont été ajoutés aux widgets de tableau de bord. Ces widgets affichent des hôtes ou des éléments, respectivement, en fonction de diverses options de filtrage et de regroupement, et permettent de contrôler les informations affichées dans d'autres widgets en fonction de l'hôte ou de l'élément sélectionné. Pour plus d'informations, consultez Navigateur d'hôtes et Navigateur d'éléments.

Cadre de communication pour les widgets

Les widgets des tableaux de bord peuvent désormais se connecter et communiquer entre eux, ce qui rend les widgets et les tableaux de bord plus dynamiques. Plusieurs widgets disposent de paramètres leur permettant de partager des données de configuration entre des widgets compatibles ou avec le tableau de bord.

Cette fonctionnalité introduit les changements suivants :

Les paramètres Groupes d'hôtes, Hôtes et Élément permettent de sélectionner soit les entités correspondantes, soit une source de données qui les fournit.
Le paramètre Activer la sélection de l'hôte a été remplacé par le paramètre Remplacer l'hôte, qui permet de sélectionner une source de données fournissant des hôtes.
Le paramètre Période a été ajouté à plusieurs widgets. Il permet de sélectionner une source de données fournissant une période.
Le paramètre Carte du widget Carte permet de sélectionner soit une carte, soit un autre widget comme source de données pour les cartes.
Le paramètre Graphe du widget Graphe (classique) permet de sélectionner soit un graphe, soit un autre widget comme source de données pour les graphes.

Selon le widget et ses paramètres, la source de données peut être un widget compatible du même tableau de bord ou le tableau de bord lui-même. Pour plus d'informations, consultez la page Widgets des tableaux de bord.

Pour connaître les modifications apportées aux modèles standard fournis avec Zabbix, consultez la page Modifications des modèles.

Périodes pour l'agrégation dans les widgets « Valeur de l'élément » et « Hôtes principaux »

Il est désormais possible de configurer des périodes dans les widgets Valeur de l'élément et Hôtes principaux.

Il est également désormais possible d'afficher une valeur agrégée dans le widget « Valeur de l'élément » pour la période sélectionnée. La valeur agrégée peut être affichée sous forme de :

minimum
maximum
moyenne
nombre
somme
première valeur
dernière valeur

Ces fonctionnalités supplémentaires sont utiles pour créer des widgets de comparaison de données. Par exemple, vous pouvez afficher la dernière valeur dans un widget et la valeur moyenne sur une période plus longue dans un autre. Vous pouvez également utiliser plusieurs widgets pour comparer côte à côte des valeurs agrégées provenant de différentes périodes passées.

Disponibilité étendue des widgets sur les tableaux de bord de modèle

Auparavant, sur un tableau de bord de modèle, vous pouviez créer uniquement les widgets suivants : Clock, Graph (classic), Graph prototype, Item value, Plain text, URL.

Désormais, les tableaux de bord de modèle prennent en charge la création de tous les widgets.

Désormais, en plus du tri par Valeur de l'élément, il est également possible de définir la colonne Nom de l'hôte ou Texte comme colonne de tri dans le widget Hôtes principaux.

Le widget Disponibilité des hôtes permet désormais d'afficher les hôtes dotés d'une interface Zabbix agent (active checks). Un autre état de disponibilité a été ajouté : Mixte. Il correspond à la situation dans laquelle au moins une interface est indisponible et au moins une autre est disponible ou inconnue. En outre, il est désormais possible d'afficher uniquement le nombre total d'hôtes, sans ventilation par interface.

Le widget Graph prend désormais en charge la configuration d'un nombre variable de lignes de légende, déterminé par le nombre d'éléments configurés.

Fonctions

Nouvelles fonctions

De nouvelles fonctions ont été ajoutées pour être utilisées dans les expressions de déclencheur et les éléments calculés :

jsonpath() - renvoie le résultat JSONPath ;
xmlxpath() - renvoie le résultat XPath XML.

Voir aussi : Fonctions de chaîne

Fonctions mises à jour

Plusieurs fonctions ont été mises à jour :

Les fonctions d'agrégation prennent désormais également en charge les types non numériques pour les calculs. 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 compter uniquement les valeurs correspondant aux critères indiqués.
Toutes les fonctions foreach n'incluent plus les éléments non pris en charge dans le décompte.
La fonction last_foreach, qui était auparavant configurée pour ignorer l'argument de période, l'accepte désormais comme paramètre facultatif.
La plage de valeurs prises en charge par les fonctions de prédiction a été étendue afin de correspondre à la plage du type de données double. La fonction timeleft() peut désormais accepter des valeurs allant jusqu'à 1.7976931348623158E+308 et la fonction forecast() peut accepter des valeurs comprises entre -1.7976931348623158E+308 et 1.7976931348623158E+308.

Éléments

Période de stockage de l’historique par défaut cohérente

La période par défaut de conservation de l’historique des éléments a été harmonisée à 31 jours dans l’interface et dans la base de données. Cette modification concerne les formulaires de configuration des éléments, des éléments de modèle et des prototypes d’éléments, ainsi que la substitution de la période de stockage de l’historique dans la découverte de bas niveau.

Les valeurs à virgule flottante sont tronquées pour les éléments de type entier

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

Comptage des lignes dans le journal des événements Windows

Un nouvel élément eventlog.count a été ajouté à Zabbix agent/agent 2 sous Windows. Cet élément renvoie une valeur entière correspondant au nombre de lignes dans le journal des événements Windows, en fonction des paramètres spécifiés.

Requêtes SNMP asynchrones à OID unique

Un nouvel élément SNMP get[OID] a été ajouté, permettant d'interroger de manière asynchrone une seule valeur OID.

Éléments internes

Les vérifications internes sont désormais prises en charge par un nouveau processus internal poller du serveur Zabbix/proxy.

Des éléments internes ont été ajoutés pour surveiller le tampon mémoire du proxy :

zabbix[proxy_buffer,buffer,<mode>] - renvoie les statistiques d'utilisation du tampon mémoire du proxy ;
zabbix[proxy_buffer,state,changes] - renvoie le nombre de changements d'état entre les modes tampon disque/mémoire depuis le démarrage ;
zabbix[proxy_buffer,state,current] - renvoie l'état de fonctionnement actuel dans lequel les nouvelles données sont stockées.

Les éléments internes suivants ont également été ajoutés :

zabbix[discovery_queue] - permet de surveiller le nombre de vérifications de découverte dans la file d'attente ;
zabbix[vps,written] - permet de surveiller le nombre total de valeurs d'historique écrites dans la base de données.

Éléments agent nouveaux et mis à jour

De nouveaux éléments ont été ajoutés à Zabbix agent/agent 2 :

L'élément net.dns.perf renvoie le nombre de secondes passées à attendre une réponse d'un service, en mesurant la durée d'exécution de l'élément net.dns.
L'élément net.dns.get de Zabbix agent 2 renvoie des informations détaillées sur les enregistrements DNS.

Les éléments Zabbix agent/agent 2 suivants ont été mis à jour :

Les éléments net.dns et net.dns.record acceptent désormais le nom DNS aux formats inversé et non inversé lors de l'exécution de recherches DNS inversées ;
Les éléments proc.get en mode « process » et « summary » renvoient désormais également la mémoire PSS (proportional set size) sous Linux ;
Les éléments system.sw.packages et system.sw.packages.get sont désormais pris en charge sur Gentoo Linux ;
L'élément system.hostname peut désormais renvoyer un nom de domaine pleinement qualifié (FQDN), si la nouvelle option fqdn est spécifiée dans le paramètre type ;
Les éléments wmi.get et wmi.getall utilisés avec Zabbix agent 2 renvoient désormais un JSON dans lequel les valeurs booléennes sont représentées sous forme de chaînes (par exemple, "RealTimeProtectionEnabled": "True" au lieu de "RealTimeProtectionEnabled": true, comme précédemment), afin de correspondre au format de sortie de ces éléments dans Zabbix agent ;
L'élément oracle.ts.discovery de Zabbix agent 2 renvoie désormais une nouvelle macro LLD {#CON_NAME} contenant le nom du conteneur ;
L'élément oracle.ts.stats de Zabbix agent 2 dispose d'un nouveau paramètre conname permettant de spécifier le nom du conteneur cible.

Le format JSON des données renvoyées a été mis à jour. Lorsqu'aucun paramètre tablespace, type ou conname n'est spécifié dans les paramètres de la clé, les données renvoyées incluent un niveau JSON supplémentaire contenant le nom du conteneur, ce qui permet de différencier les conteneurs.

Vérifications simples

L’élément vmware.eventlog prend désormais en charge le filtrage facultatif par niveau de gravité dans le troisième paramètre.

L’élément vmware.vm.discovery renvoie désormais également des données sur les interfaces réseau des machines virtuelles. Ces données peuvent être utilisées pour configurer des interfaces d’hôte personnalisées.

L’élément vmware.vm.net.if.discovery renvoie désormais également un tableau d’adresses d’interfaces réseau.

Un nouveau paramètre options a été ajouté aux éléments suivants :

Ce paramètre permet de spécifier si les réponses redirigées doivent être considérées comme indiquant que l’hôte cible est disponible ou indisponible. Consultez les vérifications simples pour plus de détails.

Journalisation des identifiants Engine SNMPv3 en double

Les identifiants Engine dans SNMPv3 servent d’identifiants uniques pour les appareils. Il arrive que plusieurs appareils aient les mêmes identifiants Engine en raison d’une mauvaise configuration ou des paramètres d’usine. Comme les normes SNMP exigent que les identifiants Engine soient uniques, les éléments partageant le même identifiant Engine deviennent non pris en charge dans Zabbix, ce qui entraîne des problèmes de disponibilité pour ces appareils.

Pour faciliter le dépannage de ces problèmes, les informations concernant les appareils SNMPv3 partageant le même identifiant Engine seront désormais consignées périodiquement par le serveur Zabbix. Notez que la détection des identifiants Engine en double fonctionne séparément dans chaque poller SNMP.

Lien de documentation pour chaque élément standard

Chaque élément standard dispose désormais d'un lien direct depuis l'interface vers sa page de documentation.

Les liens sont placés sous l'icône en forme de point d'interrogation, lors de l'ouverture de la fenêtre d'aide de l'élément depuis le formulaire de configuration de l'élément (cliquez sur Sélectionner à côté du champ de clé de l'élément).

Prétraitement

Gestion avancée de la cause racine pour l’état non pris en charge

La gestion des erreurs en cas d’échec de récupération de la valeur d’un élément (qui devient alors non pris en charge) ne permettait auparavant pas de distinguer la raison de l’échec ni l’étape d’exécution à laquelle le processus avait échoué. Toutes les erreurs devaient être traitées à l’aide d’une seule et même option de gestion des erreurs : ignorer la valeur, définir une valeur spécifiée ou définir un message d’erreur spécifié.

Il est désormais possible de comparer le message d’erreur à une expression régulière. Si l’erreur correspond (ou ne correspond pas), il est possible de spécifier la manière dont le cas d’erreur doit être traité. Par exemple, un message d’erreur spécifique peut être « mappé » vers un cas plus général, afin d’être comparé et traité par une étape de prétraitement ultérieure. De même, un problème intermittent (par exemple, lié à la connectivité réseau) peut être traité différemment d’un échec définitif de récupération de la valeur de l’élément.

Plusieurs étapes de prétraitement Vérifier la valeur non prise en charge peuvent désormais être ajoutées. Notez qu’une seule étape de correspondance « toute erreur » peut être placée à la fin du pipeline qui vérifie l’état non pris en charge de l’élément. Si elle est présente, elle est activée si aucune des vérifications spécifiques ne correspond (ou ne correspond pas) au modèle correspondant, ou si un message d’erreur (modifié) a été transmis, c’est-à-dire si aucun remplacement « Ignorer la valeur » ou « Définir la valeur sur » n’a été appliqué.

Voir également : Vérifier la valeur non prise en charge

Meilleure convivialité pour la mise à jour en masse des étapes de prétraitement

La conception précédente du formulaire de mise à jour en masse des éléments n'indiquait pas suffisamment clairement si la mise à jour des étapes de prétraitement allait ajouter ou remplacer les étapes de prétraitement. Dans la nouvelle conception, les boutons radio Remplacer et Tout supprimer ont été ajoutés afin d'indiquer clairement aux utilisateurs le résultat attendu de la mise à jour en masse des étapes de prétraitement :

Macros

Macros utilisateur pris en charge dans les noms des éléments et des prototypes d’éléments

Les macros utilisateur sont désormais prises en charge dans les noms des éléments et des prototypes d’éléments.

Notez que la prise en charge des macros utilisateur a été supprimée des noms des éléments et des prototypes d’éléments dans Zabbix 6.0. Elle est maintenant rétablie. Il est également désormais possible d’effectuer des recherches sur le nom de l’élément avec les macros résolues, ce qui n’était pas pris en charge auparavant.

Le nom de l’élément avec les macros résolues est stocké dans une table distincte de la base de données (item_rtname), qui est une extension de la table items. Pour chaque enregistrement de la table items, un enregistrement item_rtname correspondant est créé (à l’exception des prototypes d’éléments, des éléments des règles de découverte et des éléments des modèles). Le nom avec les macros résolues est limité à 2048 caractères.

Le nom de l’élément avec les macros résolues est affiché dans tous les emplacements de l’interface, à l’exception de la section Collecte de données.

Un nouveau processus serveur configuration syncer worker a été ajouté. Il est chargé de résoudre et de synchroniser les valeurs des macros utilisateur dans les noms des éléments.

Prise en charge étendue des fonctions de macro

Les fonctions de macro sont désormais prises en charge avec tous les types de macros :

Les fonctions de macro peuvent être utilisées dans tous les emplacements prenant en charge les macros répertoriées. Cela s'applique sauf s'il est explicitement indiqué qu'une macro seule est attendue (par exemple, lors de la configuration des macros d'hôte ou des filtres des règles de découverte de bas niveau).

Rapports planifiés

La fonctionnalité rapports planifiés n'est plus expérimentale.

Rapports multipages

Pour les tableaux de bord comportant plusieurs pages, les rapports incluent désormais toutes les pages du tableau de bord, chaque page du PDF correspondant à une page du tableau de bord. Auparavant, cette fonctionnalité se limitait à renvoyer uniquement la première page du tableau de bord.

Notifications

Prise en charge du traitement des tags pour les événements internes

Le traitement des tags renvoyés par le script webhook est désormais également pris en charge pour les événements internes.

De plus, les macros {EVENT.TAGS.<tag name>}, {EVENT.TAGS}, {EVENT.TAGSJSON}, {EVENT.RECOVERY.TAGS}, {EVENT.RECOVERY.TAGSJSON} sont désormais prises en charge pour les notifications d'événements internes.

Ces changements permettent d'utiliser des webhooks pour mettre à jour ou fermer un ticket de support/problème externe via une notification de récupération d'événement interne.

Bases de données

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 basé sur le 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 de TimescaleDB prises en charge

Table distincte pour les proxy

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

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

Processus

Multithreading

Plusieurs modifications ont été apportées dans le cadre de la transition vers une architecture multithread :

Un nouveau paramètre de configuration a été ajouté : --with-stacksize. Ce paramètre permet de remplacer la taille de pile par défaut des threads utilisée par le système (en kilo-octets).
La résolution des macros utilisateur a été déplacée du gestionnaire du prétraitement vers les workers de prétraitement.

Renforcement de la sécurité de l'environnement du serveur

Il est désormais possible de restreindre certaines fonctions de Zabbix afin de renforcer la sécurité de l'environnement du serveur :

L'exécution globale de scripts sur le serveur Zabbix peut être désactivée en définissant EnableGlobalScripts=0 dans la configuration du serveur. Pour les nouvelles installations, l'exécution globale de scripts sur le serveur Zabbix est désactivée par défaut.
L'authentification HTTP des utilisateurs peut être désactivée en définissant $ALLOW_HTTP_AUTH=false dans le fichier de configuration de l'interface (zabbix.conf.php).
Le modem GSM utilisé pour les notifications par SMS peut désormais être spécifié dans le nouveau paramètre SMSDevices, ce qui limite les risques de mauvaise configuration du chemin du modem GSM depuis l'interface.

Validation du fichier de configuration

La possibilité de valider le fichier de configuration a été ajoutée aux commandes de maintenance du serveur, du proxy, de l'agent, de l'agent 2 et du service web Zabbix. La validation peut être effectuée à l'aide de l'option -T --test-config. En cas de validation réussie, le code de sortie sera « 0 » ; sinon, le composant se terminera avec un code de sortie différent de zéro et un message d'erreur correspondant. Les avertissements (par exemple, dans le cas d'un paramètre obsolète) n'affecteront pas le code de sortie indiquant la réussite.

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 lors de la compilation du serveur, du proxy ou de l'agent Zabbix. Si les fonctionnalités de cURL étaient mises à niveau, le composant Zabbix concerné devait être recompilé pour pouvoir les utiliser.

Désormais, un 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.

Voir également les notes de mise à niveau.

Configuration de l'agent 2

Taille du tampon

La valeur par défaut du paramètre de configuration BufferSize pour Zabbix agent 2 a été augmentée de 100 à 1000.

Valeurs vides autorisées

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

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.

La prise en charge de l'ancien type numérique a été abandonnée

L'ancien format des valeurs à virgule flottante, précédemment obsolète, n'est plus pris en charge, car des valeurs numériques de plage étendue sont utilisées.

Paramètre de préfixe Vault ajouté aux fichiers de configuration

Les fichiers de configuration zabbix_server.conf et zabbix_proxy.conf ont été complétés par un nouveau paramètre facultatif Vault Prefix ; zabbix.conf.php a été complété par le paramètre facultatif $DB['VAULT_PREFIX'], et setup.php a été mis à jour en conséquence.

Les chemins du coffre-fort pour CyberArk et HashiCorp ne sont donc plus codés en dur, afin de permettre des déploiements de coffre-fort avec des chemins non standard.

Découverte

Concurrence dans la découverte réseau

Auparavant, chaque règle de découverte réseau était traitée par un seul processus discoverer. Ainsi, toutes les vérifications de service au sein de la règle ne pouvaient être effectuées que séquentiellement.

Dans la nouvelle version, le processus de découverte réseau a été remanié afin d'autoriser la concurrence entre les 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 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 ses tâches (vérifications de service). Les vérifications de service sont prises en charge et effectuées par les workers de découverte. Seules les vérifications utilisant la même adresse IP et le même port sont planifiées séquentiellement, car certains appareils peuvent ne pas autoriser les connexions simultanées sur le même port.

Un nouvel élément interne zabbix[discovery_queue] permet de surveiller le nombre de vérifications de découverte dans la file d'attente.

Le paramètre StartDiscoverers détermine désormais le nombre total de workers de découverte disponibles. Le nombre par défaut de StartDiscoverers est passé 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 :

Toutes les vérifications de service sont désormais effectuées asynchroniquement, à l'exception des vérifications LDAP ;
Le nombre de vérifications asynchrones simultanées pour chaque type de vérification de service (ou le nombre de workers disponibles pour toutes les vérifications de service synchrones) est désormais configurable dans l'interface (voir Nombre maximal de vérifications simultanées par type). Ce paramètre est facultatif.
La vérification de service HTTP était auparavant identique à la vérification TCP. Désormais, les vérifications HTTP/HTTPS sont effectuées via libcurl. Si le serveur/proxy Zabbix est compilé sans libcurl, les vérifications HTTP fonctionneront comme auparavant (c'est-à-dire comme des vérifications TCP), mais les vérifications HTTPS ne fonctionneront pas.
Les erreurs survenant dans le processus de découverte réseau seront désormais affichées dans l'interface (dans Collecte de données > Découverte), par exemple :
- erreurs fping ;
- OID SNMP incorrect ;
- macro incorrecte pour le délai d'expiration de l'élément ;
- erreurs de plage d'adresses.

Ajout de balises d'hôte lors de la découverte/de l'autodéclaration

Des opérations supplémentaires sont désormais disponibles pour les événements de découverte et d'autodéclaration :

Ajouter des balises d'hôte
Supprimer des balises d'hôte

Partage des groupes d'hôtes découverts

Les règles de découverte de bas niveau peuvent désormais associer aux hôtes créés par les mêmes règles de découverte de bas niveau des groupes d'hôtes déjà découverts et existants. Cela concerne les groupes d'hôtes précédemment découverts et créés par d'autres règles de découverte de bas niveau, sur la base des prototypes de groupe spécifiés.

Connecteurs

La fonctionnalité data streaming n'est plus expérimentale.

Diffuser des données sélectives et configurer les intervalles de tentative

Lorsque vous diffusez des valeurs d'élément de Zabbix vers des systèmes externes, vous pouvez désormais configurer quelles valeurs d'élément le connecteur doit diffuser en fonction de leur type d'information (numérique (non signé), numérique (flottant), caractère, etc.).

De plus, afin d'éviter des tentatives infructueuses de diffusion des valeurs d'élément ou des événements (par exemple, si le point de terminaison HTTP est occupé ou soumis à une limitation de débit), vous pouvez désormais également configurer l'intervalle de tentative - la durée pendant laquelle le connecteur doit attendre après une tentative infructueuse de diffusion des données.

Les codes de réponse HTTP 201, 202, 203 et 204 sont désormais également acceptés par les connecteurs comme succès (auparavant uniquement 200).

Diffuser des données vers Apache Kafka

Un nouvel outil pour diffuser en continu des données vers des systèmes externes - le connecteur Kafka pour Zabbix server - est désormais disponible. Le connecteur Kafka est un serveur léger écrit en Go, conçu pour transférer les valeurs d'élément et les événements d'un serveur Zabbix vers un courtier Kafka.

Modèles

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

Interface

Authentification multifacteur

L'authentification multifacteur (MFA) avec la méthode d'authentification Time-Based One-Time Password (TOTP) ou Duo Universal Prompt peut désormais être utilisée pour se connecter à Zabbix, offrant une couche de sécurité supplémentaire au-delà du simple nom d'utilisateur et mot de passe.

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

Clonage simplifié

Auparavant, il était possible d’effectuer Clone et Full clone de hôtes, de modèles et de cartes.

Désormais, l’option Clone a été supprimée, et l’option Full clone a été renommée Clone tout en conservant l’ensemble des fonctionnalités précédentes de Full clone.

Icônes remplacées par des polices

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

Formulaires modaux

Plusieurs formulaires de l'interface sont désormais ouverts dans des fenêtres modales (pop-up) :

Configuration de la règle de découverte réseau ;
Configuration du script global ;
Configuration de la corrélation des événements ;
Configuration du module ;
Configuration du type de média ;
Configuration du modèle ;
Configuration du déclencheur et du prototype de déclencheur ;
Configuration de l'élément et du prototype d'élément.

Configuration avancée réductible

Les cases à cocher Configuration avancée, qui permettaient d'afficher les options de configuration avancées, ont été remplacées par des blocs réductibles (voir, par exemple, la configuration du connecteur, la configuration du service, la configuration du widget Horloge, etc.). Cela améliore l'expérience utilisateur, car la réduction de ces blocs et l'enregistrement de la configuration ne réinitialiseront plus les options avancées configurées à leurs valeurs par défaut.

La section de menu permettant d'afficher les principaux déclencheurs est désormais nommée Top 100 triggers. La possibilité de filtrer les déclencheurs par nom de problème et par tags a été ajoutée. De plus, le nombre de problèmes détectés, au lieu du nombre de changements d'état, est désormais affiché pour chaque déclencheur.

Augmentation de la limite de caractères pour les champs de configuration

Champs d’URL

La limite de caractères pour tous les champs d’URL est désormais de 2048 caractères. Cela inclut désormais : URL de la tuile pour les paramètres liés aux cartes géographiques, l’URL de l’interface pour la configuration de divers paramètres de l’interface, les URL des cartes réseau et des éléments de carte réseau, URL A-C pour les champs de l’inventaire des hôtes, ainsi que l’URL du widget de tableau de bord URL.

Champs d’authentification

La limite de caractères pour les champs d’authentification Utilisateur/Nom d’utilisateur et Mot de passe est désormais de 255 caractères. Cela s’applique à la configuration de l’authentification HTTP pour les éléments de type agent HTTP, les scénarios web et les connecteurs, ainsi qu’à la configuration de l’authentification pour les vérifications simples, la supervision ODBC, les vérifications SSH, les vérifications Telnet et la supervision JMX.

Troncature des résultats des tests des éléments et du prétraitement

Lors du test des éléments ou du test des étapes de prétraitement, les valeurs récupérées depuis un hôte et les résultats des tests sont désormais tronqués à une taille maximale de 512 Ko lors de leur envoi à l'interface. Notez que les données dépassant 512 Ko sont toujours traitées intégralement par le serveur Zabbix.

Onglets des tableaux de bord de l'hôte

Tous les tableaux de bord de l'hôte configurés pour l'hôte sélectionné sont désormais affichés sous forme d'onglets sous l'en-tête de la page des tableaux de bord de l'hôte, remplaçant le menu déroulant précédent dans le coin supérieur droit. Cela permet de passer facilement d'un tableau de bord de l'hôte à un autre et améliore la navigation dans les données de surveillance.

Journal d’audit

Dans Administration > Journal d’audit, vous pouvez désormais activer ou désactiver la journalisation d’audit des activités de découverte de bas niveau, de découverte réseau et d’enregistrement automatique effectuées par le serveur (utilisateur système).

La période de stockage par défaut des enregistrements du journal d’audit avant leur suppression par le housekeeper a été modifiée, passant de 365 jours à 31 jours.

Filtre des données récentes

Dans Supervision > Données récentes, le sous-filtre et les données ne sont plus affichés par défaut si le filtre n'est pas défini.

En cas de mise à niveau depuis des versions précédentes de Zabbix, consultez également : Notes de mise à niveau pour la version 7.0.0.

Version minimale requise de PHP

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

Éléments renommés

Certains paramètres de widget de tableau de bord portant l’étiquette Tags ont été renommés pour plus de clarté : Item tags (pour le widget Data overview), Scenario tags (pour le widget Web monitoring) ; Problem tags (pour les widgets Graph, Problem hosts, Problems, Problems by severity et Trigger overview) ;
Le lien d’action permettant de modifier le contenu de la carte, disponible depuis la liste des cartes dans la section Monitoring → Maps, a été renommé de Constructor en Edit ;
Les champs permettant de définir les périodes de conservation de l’historique et des tendances dans les formulaires de configuration de élément et de prototype d’élément ont été renommés ;
Dans la configuration du widget Top hosts, les champs Order column et Host count ont été renommés en Order by et Host limit afin de mieux décrire leurs fonctions.
Dans la configuration du widget Graph, le champ legend Display min/max/avg a été renommé en Display min/avg/max, et les champs du data set host pattern et item pattern ont été renommés en host patterns et item patterns.
Dans les paramètres du profil utilisateur, l’onglet Messaging a été renommé en Frontend notifications, et l’option Frontend messaging a également été renommée en Frontend notifications.

Divers

Les icônes du menu principal ont été mises à jour ;
Les messages indiquant l’absence de données ou l’absence de filtres définis (dans les widgets ou les filtres contextuels ne contenant aucune donnée à afficher) ont été mis à jour. De plus, le pied de page « Affichage de 0 résultat sur 0 trouvé » a été supprimé lorsqu’il n’y a aucune donnée à afficher ou lorsque le filtrage (ou l’utilisation de la recherche globale) ne renvoie aucun résultat.
Les numéros de version de l’interface et du serveur Zabbix sont désormais visibles sur la page Informations système ;
Toutes les actions utilisant le type de média sont désormais affichées dans la liste des types de média (colonne Utilisé dans les actions). Auparavant, les actions dont l’option Envoyer uniquement à était définie sur « Tous » dans la configuration des opérations d’action n’étaient pas incluses dans la colonne Utilisé dans les actions du type de média ;
Une nouvelle option de filtrage a été ajoutée à la section Dernières données : elle permet désormais de filtrer les éléments selon leur état (pris en charge/non pris en charge) ;
Une nouvelle option de filtrage État de l’acquittement a été ajoutée à la section Problèmes : elle permet désormais de filtrer les problèmes selon leur état (non acquitté/acquitté/acquitté par moi) ;
Un bouton de fermeture standard a été ajouté aux fenêtres contextuelles destinées à configurer et à mettre à jour en masse les éléments et les formes des cartes ;
La configuration des permissions des groupes d’utilisateurs et des tags servant à filtrer les problèmes visibles a été améliorée. Il est désormais possible de sélectionner plusieurs groupes d’hôtes/modèles à la fois afin de leur attribuer les mêmes permissions.
La mise en veille des notifications globales dans un navigateur les mettra désormais en veille dans tous les navigateurs et appareils sur lesquels l’utilisateur est connecté.
Le paramètre Remplacer l’hôte du widget Valeur de l’élément a été déplacé avant la section Configuration avancée afin d’en améliorer l’utilisation.

Plugins

Ember+

Un nouveau plugin pour la supervision directe d'Ember+ par l'agent 2 Zabbix a été ajouté.

Pour plus d'informations, consultez :

Installation

Packages d'installation distincts pour les dérivés de RHEL

Des packages d'installation dédiés sont disponibles pour les versions 8 et 9 d'AlmaLinux, CentOS Stream, Oracle Linux et Rocky Linux. Auparavant, des packages d'installation uniques étaient fournis pour RHEL et les distributions basées sur RHEL. Désormais, des packages distincts sont utilisés pour RHEL et chacun de ses dérivés mentionnés ci-dessus afin d'éviter d'éventuels problèmes d'incompatibilité binaire.

Prise en charge de ARM64/AArch64

Des paquets d'installation ARM64/AArch64 sont désormais disponibles pour Debian, RHEL 8, 9 et ses dérivés, ainsi que pour SLES/OpenSUSE Leap 15.

Quelle est la prochaine étape ?

6 Quoi de neuf dans Zabbix 7.0.1

Docs

5 Quoi de neuf dans Zabbix 7.0.0

AGPL-3.0 license

Vérification de mise à jour