Zabbix

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. A savoir que l'éditeur développe en premier lieu sur l'écosystème MySQL (MariaDB, Percona, ...).

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

Il s'agit d'un démon binaire existant pour Linux, BSD et divers Unix (voir site officiel : http://www.zabbix.com/requirements.php). 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... Le logiciel peut réaliser le monitoring via SNMP.

Fonctionnalité intéressante, il est possible de configurer des "proxy Zabbix" afin de répartir la charge ou d'assurer une meilleure disponibilité de service.

Le logiciel Zabbix est écrit en langage C.

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.

• Nagios
• MRTG
• PRTG
• Xymon
• Ganglia (en)
• Centreon

• Iperf, un outil de test de performance réseau
• Supervision