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 en introduisant des 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 passe 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ément, découverte réseau, auto-enregistrement d'hôte) 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 le comportement par défaut après la mise à niveau.

Pour des performances optimisées, 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 en vidant vers la base de données les données non envoyé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é vidées dans la base de données, le proxy recommence à utiliser le tampon mémoire.

En mode mémoire, le tampon mémoire sera utilisé, mais il n'existe aucune protection contre la perte de données. Si le proxy est arrêté ou si la mémoire est saturée, les données non envoyées seront 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'âge maximal 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 uniquement aux médias créés pendant le provisionnement, sans possibilité de modifier des propriétés telles que les heures de travail ou les niveaux de gravité.

Désormais, davantage de flexibilité est disponible pour les utilisateurs provisionnés dans Zabbix :

le média utilisateur provisionné peut être désactivé/activé ;
les champs de média de l'utilisateur provisionné, tels que When active, Use if severity et Enabled, 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 When active, Use if severity et Enabled sont désormais disponibles. Notez que les modifications apportées au formulaire de mappage du type de média utilisateur ne prendront effet que pour les nouveaux médias créés pendant le 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 agents plus anciens, 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é de l'é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 valeurs 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é de l'élément est envoyée.

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

Protocoles de l'agent/agent2 unifiés

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

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 Disable lost resources 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 même développement, le paramètre Keep lost resources period a été renommé en Delete lost resources avec des options permettant de 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 JSON personnalisé communication protocol similaire à celui utilisé dans 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 HTTP agent (avec le trapping activé).

De plus, les opérations history.push correctes sont enregistrées dans Reports → Audit log, qui dispose d'options de filtrage supplémentaires (une nouvelle action Push et une ressource History), et la méthode d'API history.push est également disponible dans la Allow/Deny list des méthodes d'API lors de la configuration d'un rôle utilisateur.

Scripts

Exécution de scripts sur des agents actifs

Il est désormais possible d'exécuter des scripts sur des agents fonctionnant en mode actif. Une fois l'exécution du script déclenchée par une opération d'action ou par une exécution manuelle du 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'attente du serveur/proxy pour l'exécution du script. Veuillez augmenter le délai d'attente par défaut du serveur/proxy pour l'exécution du script. Le délai d'attente doit être supérieur à la fréquence d'actualisation des vérifications actives, sinon le délai d'attente est dépassé avant que l'agent actif ne reçoive le script et ne puisse renvoyer le résultat.

Notez que les anciens agents actifs ignorent 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 de l'utilisateur pour les scripts

La saisie manuelle de l'utilisateur pour les scripts de l'interface permet de fournir un paramètre personnalisé à chaque exécution du script. Cela évite d'avoir à 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 adresse URL différente au script lors de son exécution.

Pour activer la saisie manuelle de l'utilisateur :

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

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

Selon la configuration, l'utilisateur devra saisir une valeur de type chaîne ou sélectionner une valeur dans une liste déroulante d'options prédéfinies.

Performance

Réaction plus rapide à la mise à jour de la période de maintenance de l'hôte

Auparavant, les maintenances n'étaient recalculées qu'une fois par minute, ce qui pouvait entraîner une latence allant jusqu'à 60 secondes pour le démarrage ou l'arrêt d'une période de maintenance.

Désormais, les maintenances sont toujours recalculées chaque minute ou dès que le cache de configuration est rechargé s'il y a des modifications de la période de maintenance.

Chaque seconde, le processus de minuterie vérifie si des maintenances doivent être démarrées/arrêtées en fonction de l'existence de modifications des périodes de maintenance après la mise à jour de la configuration. Ainsi, la vitesse de démarrage/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 de période de maintenance n'incluent pas les paramètres Active since/Active till. De plus, si un hôte/groupe d'hôtes est ajouté à une période de maintenance active existante, les modifications ne seront activées par le processus de minuterie qu'au début de la minute suivante.

Vérifications des permissions plus rapides

Les vérifications des permissions ont été considérablement accélérées 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/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 qui sollicitent fortement les permissions (c’est-à-dire les hôtes, 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 de tableau de bord peuvent désormais se connecter et communiquer entre eux, rendant 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.

Déclencheurs principaux

Un widget Déclencheurs principaux a été ajouté aux widgets de tableau de bord, ce qui permet d’afficher les déclencheurs ayant le plus grand nombre de problèmes.

Pour plus d’informations, consultez : Déclencheurs principaux.

Historique d'élément et texte brut

Le nouveau widget de tableau de bord Historique d'élément 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 d'élément 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).

Pour plus d'informations, consultez Historique d'élément. Pour plus de détails sur le remplacement du widget Texte brut, consultez les Notes de mise à niveau pour 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 du tableau de bord peuvent désormais se connecter et communiquer entre eux, rendant les widgets et les tableaux de bord plus dynamiques. Plusieurs widgets disposent de paramètres qui leur permettent de partager des données de configuration entre des widgets compatibles ou le tableau de bord.

Cette fonctionnalité introduit les modifications suivantes :

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, ce qui permet de sélectionner une source de données fournissant une période.
Le paramètre Carte dans le widget Carte permet de sélectionner soit une carte, soit un autre widget comme source de données pour les cartes.
Le paramètre Graphique dans le widget Graphique (classique) permet de sélectionner soit un graphique, soit un autre widget comme source de données pour les graphiques.

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

Pour les modifications apportées aux modèles standard fournis avec Zabbix, consultez Modifications des modèles.

Périodes de temps pour l'agrégation dans les widgets de valeur d'élément/top hôtes

Les périodes de temps peuvent désormais être configurées dans les widgets Valeur d'élément et Top hôtes.

Il est également désormais possible d'afficher une valeur agrégée dans le widget de valeur d'élément pour la période choisie. La valeur agrégée peut être affichée comme :

minimum
maximum
moyenne
nombre
somme
premier
dernier

Ces nouvelles fonctionnalités sont utiles pour créer des widgets de comparaison de données. Par exemple, dans un widget, vous pouvez afficher la dernière valeur, tandis que dans un autre, la valeur moyenne sur une période plus longue. Ou plusieurs widgets peuvent être utilisés pour comparer côte à côte des valeurs agrégées provenant de différentes périodes dans le passé.

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 Item value, il est également possible de définir la colonne Host name ou Text comme colonne de tri dans le widget Top hosts.

Le widget Disponibilité des hôtes permet désormais d’afficher les hôtes avec l’interface Zabbix agent (active checks). Un autre état de disponibilité a été ajouté, à savoir Mixed, qui correspond à la situation où au moins une interface est indisponible et au moins une autre est soit disponible, soit inconnue. De plus, il est désormais possible d’afficher uniquement le total des hôtes, sans répartition par interfaces.

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 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 comptage.
La fonction last_foreach, auparavant configurée pour ignorer l'argument de période temporelle, l'accepte désormais comme paramètre facultatif.
La plage prise en charge pour les valeurs renvoyées par les fonctions de prédiction a été étendue afin de correspondre à la plage du type de données double. Désormais, la fonction timeleft() peut accepter des valeurs jusqu'à 1.7976931348623158E+308 et la fonction forecast() peut accepter des valeurs allant de -1.7976931348623158E+308 à 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. Ce changement affecte les formulaires de configuration des éléments, des éléments de modèle et des prototypes d'élément, ainsi que la substitution de la période de stockage de l'historique dans la découverte de bas niveau.

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 valeur sera tronquée de sa partie décimale et enregistrée comme un entier. Auparavant, une valeur à virgule flottante rendait un élément 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.

Nouveaux éléments agent et éléments agent 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 chronométrant l'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 au format 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é, 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 du 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 ;
L'élément oracle.ts.discovery de Zabbix agent 2 renvoie désormais une nouvelle macro LLD {#CON_NAME} avec le nom du conteneur ;
L'élément oracle.ts.stats de Zabbix agent 2 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 pas 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.

Vérifications simples

L'élément vmware.eventlog prend désormais en charge un filtrage facultatif par 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'interface réseau.

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

Ce paramètre peut être utilisé pour indiquer si les réponses redirigées doivent être considérées comme un hôte cible actif ou inactif. Consultez la section vérifications simples pour plus de détails.

Journalisation des Engine IDs SNMPv3 en double

Les Engine IDs dans SNMPv3 sont utilisés comme identifiants uniques de l'appareil. Il arrive parfois que les Engine IDs soient identiques sur plusieurs appareils en raison d'une mauvaise configuration ou de paramètres d'usine. Comme les normes SNMP exigent que les Engine IDs soient uniques, les éléments partageant le même Engine ID deviennent non pris en charge dans Zabbix, ce qui entraîne des problèmes de disponibilité pour ces appareils.

Pour aider à diagnostiquer ce type de problème, les informations concernant les appareils SNMPv3 partageant le même Engine ID seront désormais consignées périodiquement par le serveur Zabbix. Notez que la détection des Engine IDs 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 d'élément non pris en charge

La gestion des erreurs en cas d'échec de récupération de la valeur d'un élément (et donc de son passage à l'état non pris en charge) ne permettait auparavant pas de distinguer la raison ou 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 - soit 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 faire correspondre le message d'erreur à une expression régulière. Si l'erreur correspond (ou ne correspond pas), il est possible de spécifier comment 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 à rechercher et à traiter par une étape de prétraitement ultérieure, ou un problème intermittent (par exemple, de 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 Check for not supported value peuvent désormais être ajoutées. Notez qu'il ne peut y avoir qu'une seule étape de correspondance "any error" à 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 au motif associé, ou si un message d'erreur (modifié) a été conservé - c'est-à-dire qu'aucune substitution "Discard value" ou "Set value to" n'a pris effet.

Voir aussi : Check for not supported value

Meilleure ergonomie 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’était pas suffisamment claire quant à savoir si la mise à jour de l’étape de prétraitement allait ajouter ou remplacer des étapes de prétraitement. Dans la nouvelle conception, les boutons radio Remplacer et Tout supprimer ont été ajoutés, afin de clarifier pour les 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 d'élément et de prototype d'élément

Les macros utilisateur sont désormais prises en charge dans les noms d'élément et les noms de prototype d'élément.

Notez que la prise en charge des macros utilisateur a été supprimée des noms d'élément/de prototype d'élément dans Zabbix 6.0. Elle a maintenant été rétablie. Il est également désormais possible de rechercher un nom d'élément avec les macros résolues, ce qui n'était pas pris en charge auparavant.

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

Le nom d'é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 d'élément.

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 listées. Cela s'applique sauf indication explicite précisant qu'une macro est attendue uniquement (par exemple, lors de la configuration des macros d'hôte ou des filtres des règles de découverte bas niveau).

Rapports planifiés

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

Rapports multipages

Pour les tableaux de bord multipages, les rapports sont désormais renvoyés avec toutes les pages du tableau de bord, chaque page PDF correspondant à une page du tableau de bord. Auparavant, cette fonctionnalité se limitait au renvoi de la première page du tableau de bord uniquement.

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 de base de données distincte 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.

Processus

Multithreading

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

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 kilooctets).
La résolution des macros utilisateur a été déplacée du gestionnaire de 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 des 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 des 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 pour les notifications SMS peut désormais être spécifié dans le nouveau paramètre SMSDevices, ce qui limite la possibilité de mal configurer le 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 de Zabbix serveur, proxy, agent, agent 2 et service web. La validation peut être effectuée à l'aide de l'option -T --test-config. En cas de validation réussie, le code de retour sera "0" ; sinon, le composant se terminera avec un code de retour non nul et un message d'erreur correspondant. Les avertissements (par exemple, en cas de paramètre obsolète) n'affecteront pas le code de retour en cas de 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 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 les utiliser.

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

Voir aussi 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, tous les contrôles de service au sein de la règle ne pouvaient être exécutés que séquentiellement.

Dans la nouvelle version, le processus de découverte réseau a été remanié afin de permettre la concurrence entre les contrôles de service. Un nouveau processus de gestionnaire de découverte a été ajouté, ainsi qu’un nombre configurable de workers de découverte (ou de threads).

Le gestionnaire de découverte traite les règles de découverte et crée une tâche de découverte par règle avec des tâches (contrôles de service). Les contrôles de service sont pris en charge et exécutés par les workers de découverte. Seuls les contrôles ayant la même IP et le même port sont planifiés séquentiellement, car certains périphériques peuvent ne pas autoriser des connexions concurrentes sur le même port.

Un nouvel élément interne zabbix[discovery_queue] permet de surveiller le nombre de contrôles 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 pour la découverte. La valeur par défaut de StartDiscoverers a été augmentée 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.

En outre :

Tous les contrôles de service sont désormais exécutés de manière asynchrone, à l’exception des contrôles LDAP ;
Le nombre de contrôles asynchrones simultanés par type de contrôle de service (ou le nombre de workers disponibles pour tous les contrôles de service synchrones) est désormais configurable dans l’interface (voir Maximum concurrent checks per type). Ce paramètre est facultatif.
Le contrôle de service HTTP était auparavant identique au contrôle TCP. Désormais, la vérification HTTP/HTTPS est effectuée via libcurl. Si le serveur/proxy Zabbix est compilé sans libcurl, les contrôles HTTP fonctionneront comme auparavant (c’est-à-dire comme des contrôles TCP), mais les contrôles HTTPS ne fonctionneront pas.
Les erreurs dans le processus de découverte réseau seront désormais affichées dans l’interface (dans Data collection -> Discovery), 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 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 s'ouvrent désormais dans des fenêtres modales (pop-up) :

Règle de découverte réseau configuration ;
Script global configuration ;
Corrélation d'événements configuration ;
Module configuration ;
Type de média configuration ;
Modèle configuration ;
Déclencheur et prototype de déclencheur configuration ;
Élément et prototype d'élément configuration.

Configuration avancée repliable

Les cases à cocher Configuration avancée, qui servaient à afficher les options de configuration avancées, ont été remplacées par des blocs repliables (voir, par exemple, Configuration du connecteur, Configuration du service, Configuration du widget Clock, etc.). Cela améliore l'expérience utilisateur, car le fait de replier ces blocs puis d'enregistrer la configuration ne réinitialisera 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.

Limite de caractères augmentée pour les champs de configuration

Champs URL

La limite de caractères pour tous les champs URL est désormais de 2048 caractères. Cela inclut désormais : Tile URL pour les paramètres liés aux cartes géographiques, Frontend URL pour la configuration de divers paramètres de l'interface, URLs pour les cartes réseau et les éléments de carte réseau, URL A-C pour les champs de l'inventaire de l'hôte, et URL pour le widget de tableau de bord URL.

Champs d'authentification

La limite de caractères pour les champs d'authentification User/User name et Password est désormais de 255 caractères. Cela s'applique à la configuration de l'authentification HTTP pour les éléments HTTP agent, les scénarios web et les connecteurs, ainsi qu'à la configuration de l'authentification pour les vérifications simples, la surveillance ODBC, les vérifications SSH, les vérifications Telnet, et la surveillance JMX.

Troncature du résultat du test d'élément et de 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 de test sont désormais tronqués à une taille maximale de 512 KB lorsqu'ils sont envoyés à l'interface. Notez que les données supérieures à 512 KB 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'autoréenregistrement effectuées par le serveur (utilisateur système).

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

Filtre des dernières données

Dans Surveillance → 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.

Si vous effectuez une mise à niveau depuis des versions précédentes de Zabbix, consultez également : Notes de mise à niveau pour 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 des filtres non définis (dans les widgets ou les filtres contextuels sans données à afficher) ont été mis à jour. De plus, le pied de page "Displaying 0 of 0 found" a été supprimé dans les cas où il n'y a aucune donnée à afficher ou lorsque le filtrage (ou l'utilisation de la recherche globale) ne renvoie aucune correspondance.
Les numéros de version de l'interface Zabbix et du serveur Zabbix sont désormais visibles sur la page d'informations système ;
Toutes les actions où le type de média est utilisé sont désormais affichées dans la liste des types de média (colonne Used in actions). Auparavant, les actions où l'option Send only to option dans la configuration de l'opération d'action était "All" n'étaient pas incluses dans la colonne Used in 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 Acknowledgement status 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 standard de fermeture de fenêtre a été ajouté aux fenêtres contextuelles destinées à la configuration et à la mise à jour en masse des éléments et des formes de la carte ;
La configuration des autorisations des groupes d'utilisateurs et des balises pour filtrer les problèmes visibles a été affiné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 autorisations.
Les notifications globales Snoozing dans un navigateur les mettront désormais en veille dans tous les navigateurs/appareils où l'utilisateur est connecté.
Le paramètre Override host du widget Item value a été déplacé avant la section Advanced configuration pour une meilleure ergonomie.

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

What’s next?

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