Aller au contenu

Zabbix

Un article de Wikipédia, l'encyclopédie libre.
Zabbix
Description de l'image Zabbix logo.svg.
Description de l'image Dashboard graphs v4 dark 1.png.
Informations
Créateur Alexei Vladishev (d)Voir et modifier les données sur Wikidata
Développé par Zabbix (d)Voir et modifier les données sur Wikidata
Première version [1]Voir et modifier les données sur Wikidata
Dernière version 7.0.0 ()[2]Voir et modifier les données sur Wikidata
Dépôt git.zabbix.com/scm/zbx/zabbix.gitVoir et modifier les données sur Wikidata
Écrit en C, PHP et JavaVoir et modifier les données sur Wikidata
Système d'exploitation GNU/Linux, Solaris, macOS, HP-UX, NetBSD, FreeBSD, IBM Power Systems et AIXVoir et modifier les données sur Wikidata
Type Supervision
Licence AGPL-3.0Voir et modifier les données sur Wikidata
Site web www.zabbix.comVoir et modifier les données sur Wikidata

ZABBIX est un logiciel libre permettant de surveiller l'état de divers services réseau, serveurs et autres matériels réseau et produisant des graphiques dynamiques de consommation des ressources. C'est un logiciel créé par Alexei Vladishev.

Structure du logiciel

[modifier | modifier le code]

Le « serveur ZABBIX » peut être décomposé en trois parties séparées : Le serveur de données, l'interface de gestion et le serveur de traitement. Chacune d'elles peut être disposée sur une machine différente pour répartir la charge et optimiser les performances.

Le système dont l'utilisation des ressources doit être analysée comporte un agent fonctionnant sous forme de daemon appelé zabbix-agentd et écoutant par défaut sur le port TCP 10050. Celui-ci intègre des fonctions permettant d'échantillonner l'état des ressources des différents composants du système (mémoire, CPU, débit réseau, entrées-sorties, nombre de connexion à une application, etc.) et propose si nécessaire l'exécution de scripts. Le serveur Zabbix appelle donc régulièrement cet agent et lui demande les informations concernant telle ou telle ressource.

Le serveur de données

[modifier | modifier le code]

ZABBIX utilise MySQL, PostgreSQL ou Oracle pour stocker les données. Selon l'importance du nombre de machines et de données à surveiller, le choix du SGBD influe grandement sur les performances. Il existe une section relative à ce choix dans le manuel officiel. À savoir que l'éditeur développe en premier lieu sur l'écosystème MySQL (MariaDB, Percona, ...).

L'interface de gestion

[modifier | modifier le code]

Son interface web est écrite en PHP. Elle agit directement sur les informations stockées dans la base de données. Chaque information nécessaire au serveur de traitement étant réactualisée automatiquement, il n'y a pas d'action à effectuer sur le binaire pour lui indiquer qu'il y a eu une mise à jour.

Cette interface dispose des fonctionnalités principales suivantes :

  • Affichage des données et état des machines
  • Génération de graphiques (évolution des données et état des machines/liens)
  • Classement et groupement des machines surveillées
  • Auto découverte de machines et ajout automatique
  • Gestion fine des droits d'accès pour les utilisateurs de l'interface

Le serveur de traitement

[modifier | modifier le code]

Il s'agit d'un démon binaire existant pour Linux, BSD et divers Unix. Il offre diverses options de monitoring. La vérification simple permet de vérifier la disponibilité ainsi que le temps de réponse de services standards comme SMTP ou HTTP sans installer aucun logiciel sur l'hôte monitoré. Un agent ZABBIX peut aussi être installé sur les hôtes Linux, UNIX et Windows afin d'obtenir des statistiques comme la charge CPU, l'utilisation du réseau, l'espace disque, etc. Le logiciel peut réaliser le monitoring via SNMP.

Il est aussi possible de configurer des « proxy Zabbix » afin de répartir la charge ou d'assurer une meilleure disponibilité de service.

Le logiciel est écrit en langage C.

Méthode de traitement

[modifier | modifier le code]

Pour ZABBIX, chaque valeur récupérée correspond à un item. A chacun d'eux peut être associé un ou plusieurs tests appelés triggers. Des actions peuvent être liées aux triggers, ce qui permet d'effectuer un traitement particulier (notification, remédiation, ...) pour chaque anomalie pouvant survenir. Par exemple, si une machine devient indisponible, on peut envoyer un mail à l'administrateur système. Si la charge d'un programme devient trop importante pendant trop longtemps, on peut lancer un programme qui fera un flush...

Collecter l'information est donc le premier traitement réalisé (on peut adjoindre à cette collecte un premier niveau de transformation de la donnée collectée) ;

Stocker cette information dans une base de données est le deuxième traitement ;

Analyser les conditions de déclenchement d'un événement sera la troisième étape ;

Restituer les événements, mais également les indicateurs collectés sous forme de graphe dans le temps, sera réalisé par le frontal Web.

Les items sont des valeurs récupérées par le serveur ZABBIX. Leur source peut être sélectionnée. Elles peuvent être des réponses ou trap SNMP, des codes de retour ou le résultat de programmes externes, des valeurs demandées à un agent ZABBIX, des compteurs JMX, des valeurs calculées (formule mathématique de plusieurs indicateurs bruts), des valeurs agrégées (agrégation d'une valeur collectée pour un groupe d'équipements), ...

Pour chaque item, on peut spécifier la durée d'enregistrement dans la base de chaque valeur remontée.

Les triggers sont des tests effectués sur un ou plusieurs item. Ils peuvent avoir des dépendances. Cela permet d'éviter de générer des alertes pour des machines si c'est le réseau en amont qui est défaillant. Les triggers représentent la fonction d'analyse des conditions de déclenchement d'un événement. Étant donné que cette analyse se fait sur les données collectées, on peut baser notre analyse sur un ou plusieurs indicateurs, en provenance d'un ou plusieurs équipements : il s'agit de fonction de corrélation.

Une action peut être lancée sur 4 types d'événements : les événements de découverte, les événements d'auto-enregistrement des agents, les événements internes et les triggers. Dans ce dernier cas, on pourra définir des actions de notification (envoi de courriel, d'événement sur messagerie instantanée, création de ticket d'incident...) et des actions de remédiation (tentative de correction automatisée de l'anomalie).

Les actions permettent de concevoir des scénarios d'escalade, comme :

  1. l'envoi immédiat d'un courriel à un administrateur du composant touché par l'anomalie ;
  2. l'envoi d'un SMS 5 min après le déclenchement de l'événement à un administrateur du composant touché par l'anomalie, si celle-ci perdure pendant ce laps de temps ;
  3. la création d'un ticket d'incident 10 min après le déclenchement de l'événement, si l'anomalie perdure pendant ce temps ;
  4. etc.

ZABBIX est distribué sous licence publique générale GNU Affero Version 3 (AGPL v.3).

Articles connexes

[modifier | modifier le code]

Autres logiciels de supervision

[modifier | modifier le code]

Références

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]