Zabbix

Université d’Angers
40 Rue de Rennes
49035 Angers
Teé l: (+33) 02 41 96 23 23
Site web: www.univ-angers.fr
Rapport du projet
Sujet 2
2018-2019
Projet tutoré de Licence professionnelle : systèmes

d’information et gestion de données/ Logiciels libres
Meé trologie et monitoring sous Zabbix
Réalisateurs :
- AGHARBI Ayman
- BANGA Jovial Bodenan
- BLAUDY Evan
- MAMORI Nabil
Superviseurs :
- Monsieur Fabien GARREAU
- Monsieur EÉ ric GIRARDEAU
RAPPORT DU PROJET 2018-2019
Table des matières

Introduction.................................................................................................................................3
Présentation générale..............................................................................................................4
Installation...................................................................................................................................6
Liste des participants au projet
NOM(S) ET PRENOM(S) FONCTION RÔLES

Mr Fabien GARREAU Enseignant Superviseur
Mr Éric GIRARDEAU Agent technique Superviseur
AGHARBI Ayman Etudiant Réalisateur
BANGA Jovial Bodenan Etudiant Réalisateur
BLAUDY Evan Etudiant Réalisateur
MAMORI Nabil Etudiant Réalisateur
Introduction générale
Actuellement, les systèmes d’informations dans les entreprises deviennent de plus en plus
importants mais aussi complexes. Le besoin de maintenance et de gestion de ces systèmes est
rapidement devenu une priorité.C’est ainsi qu’aucun acteur du numérique ne peut se
soustraire à la question de savoir comment gérer (suivi, surveillance) de manière efficace et
rationnelle des flux de données dans un réseau informatique. Pour ce faire, plusieurs logiciels
de surveillance et de supervision de réseaux ont été développés pour vérifier l’état du réseau
en temps réel et pour être informé au plutôt de tout incident réseau. Grâce à ces logiciels, les
délais d’interventions sont fortement réduites et les anomalies peuvent être aussitôt prises en
main sans que les utilisateurs du réseau en question soient affectés ou remarquent des erreurs.
C’est en effet, ce qui résulte des concepts de Métrologie et monitoring ou monitorage.
Dans ce cadre, nous envisageons de mettre en place une console d’administration
réseau pour le département informatique de la faculté des sciences de l’université d’Angers.
Cette console permettra de superviser et de contrôler le réseau et l’état des équipements
informatiques.
Ce rapport présente l’ensemble des étapes suivies pour développer une solution de
supervision sous le thème «Projet Métrologie & monitoring sous Zabbix» . Il
contient quatre chapitres organisés comme suit :
Le premier chapitre sera intitulé « Principes généraux » présente un rappel du principe de

supervision avant de passer à l’étude comparative des outils de supervision existants et la
fixation du choix de l’outil à mettre en place.
Le deuxième chapitre a pour objectif de présenter l’étude théorique de la solution de

monitoring adoptée pour ce travail, son architecture et son principe de fonctionnement.
Le troisième et dernier chapitre intitulé « Mise en place de la solution adoptée » présente

l’environnement de travail ainsi que les outils logiciels que nous avons utilisés pour la
réalisation de notre projet. Il illustre aussi le travail réalisé et quelques tests.
Chapitre 1 : Principes généraux
I. Introduction :
Dans ce chapitre, nous allons définir précisément le concept de supervision de façon plus
large et des éléments qui interviennent dans ce processus, aussi la manière dont il a été
normalisé par l’ISO, ensuite nous procédons à une étude comparative des outils de
supervision et à préciser le choix de l’outil retenu.
1. Principe de la supervision :
La supervision se définit comme une technique utilisant au mieux les ressources
informatiques pour obtenir des informations sur l'état des réseaux et de leurs composants. Ces
données seront ensuite traitées et affichées afin de mettre ma lumière sur d'éventuels
problèmes.
La supervision peut résoudre les problèmes automatiquement ou dans le cas contraire prévenir
via un système d'alerte (email ou SMS par exemple) les administrateurs. Cette définition de la
supervision est décrite plus en détail dans la norme ISO7498/4.
Plusieurs actions sont ainsi réalisées : Acquisition de données, analyse, puis visualisation et
réaction .
Un tel processus est réalisé à plusieurs niveaux d'un parc de machines : Au niveau
interconnexions (Réseau), au niveau de la machine elle-même (Système) et au niveau des
services offerts par cette machine (Applications).
 Supervision réseau : Par le terme réseau on entend ici l'aspect communication entre
les machines. Le rôle est de s'assurer du bon fonctionnement des communications et
de la performance des liens (débit, latence, taux d'erreurs). C'est dans ce cadre que l'on
va vérifier par exemple si une adresse IP est toujours joignable, ou si tel port est ouvert
sur telle machine, ou faire des statistiques sur la latence du lien réseau.
 Supervision système : La surveillance se cantonne dans ce cas à la machine elle-

même et en particulier ses ressources. Si l'on souhaite par exemple contrôler la
mémoire utilisée ou la charge processeur sur le serveur voire analyser les fichiers de
logs système.
 Supervision applicative : Cette technique est plus subtile, c'est elle qui va nous
permettre de vérifier le fonctionnement d'une application lancée sur une machine.Cela
peut être par exemple une tentative de connexion sur le port de l'application pour voir
si elle retourne ou demande bien les bonnes informations, mais aussi de l'analyse de
logs applicatifs.
2. La norme ISO 7498/4:
Le concept de supervision a été normalisé par l’ISO (International Organization for

Standardization). Voici les différentes fonctions qui ont été défini par l’ISO :
2.1. Gestion des performances :

Elle doit pouvoir évaluer les performances des ressources du système et leur efficacité. Elle
comprend les procédures de collecte de données et de statistiques. Elle doit aboutir à
l’établissement de tableaux de bord. Les informations recueillies doivent aussi permettre de
planifier les évolutions du réseau.
Les performances du réseau sont évaluées à partir de quatre paramètres :
 Le temps de réponse
 Le débit
 Le temps d’erreur par bit
 La disponibilité
2.2. Gestion des configurations (Management configuration)
La gestion de configuration permet d’identifier, de paramétrer et de contrôler les différents

objets du réseau. Les procédures requises pour gérer une configuration sont :
 La collecte d’information
 Le contrôle d’état
 La sauvegarde historique de configurations de l’état du système
2.3. Gestion de la comptabilité(Accouting management)
Son rôle est de connaître les charges des objets gérés ainsi que leurs coûts de communication.
Des quotas d’utilisation peuvent être fixés temporairement ou non sur chacune des ressources
réseaux. De plus, la gestion de la comptabilité autorise la mise en place de systèmes de
facturation en fonction de l’utilisation pour chaque utilisateur.
2.4. Gestion des anomalies(Fault Management)
La gestion des fautes permet la détection, la localisation et la correction d’anomalies

passagères ou persistantes. Elle doit également permettre le rétablissement du service à une
situation normale.
2.5. Gestion de la sécurité(Security Management)
La gestion de la sécurité contrôle l’accès aux ressources en fonction des politiques de droits
d’utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent accéder à
certaines ressources protégées.
Elle a également pour rôle de mettre en application les politiques de sécurité.
3. Le protocole SNMP :
Sauf exception pour des besoins d’utilisation comme c’est le cas pour notre projet, la majeure
partie du temps, pour superviser les activités d’un réseau informatique, il y a un protocole très
essentiel souvent utilisé par les plateformes de supervision qui est le SNMP qui signifie «
Simple Network Management Protocol », en français « Protocole simple de gestion de réseau

».
C’est un protocole de communication qui nous permettra de faire le lien entre l’agent (client)
qui peut être le switch par exemple et le manager soit, le serveur qui va être la machine. Mais
il permet aussi aux administrateurs réseaux de pouvoir gérer les équipements du réseau, de les
superviser et de vérifier s’il y a d’éventuels problèmes.
Pour fonctionner et pouvoir recevoir les informations du switch vers le serveur, le protocole
SNMP devra être installer sur l’agent. De plus, on devra s’appuyer sur deux principes à
savoir: les alertes que l’agent émet vers le serveur, appelées « traps » et les requêtes du
serveur vers l’agent. Soit, deux techniques de supervision avec SNMP, le polling et les traps.
Le polling consiste simplement à envoyer une requête pour obtenir une valeur particulière.
Les traps consistent à faire de la vérification passive, c’est-à-dire qu’on configure l'agent
SNMP pour qu'il contacte un autre agent SNMP en cas de problème. Autrement dit, on peut
configurer un périphérique réseau (comme un routeur) pour qu'il envoie une trap SNMP.
Le protocole SNMP s’appuie sur le protocole UDP. L’agent aura le choix entre deux ports :
161 qui correspond à l’envoi de requêtes et de la réception des informations et le port 162, qui
concerne l’envoi des traps. Même si le protocole UDP n’est pas sécurisé, le protocole SNMP
est très utilisé par les administrateurs réseaux.
Il existe actuellement 3 versions différentes du protocole SNMP :
- SNMP v1 (RFC 1155, 1157 et 1212).
- SNMP v2c (RFC 1901 à 1908).
- SNMP v3 (RFC 3411 à 3418).
Dans les versions une et deux, une requête SNMP contient un nom appelée communauté,
utilisé comme un mot de passe. La valeur par défaut de communauté est public ou private.
Les versions 1 et 2 du protocole SNMP ne sont pas sécurisées. C'est pourquoi les bonnes
pratiques recommandent de n'utiliser que la version 3.
Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des requêtes de
management. C’est lui le serveur et est la cible pour gérer les traps.
 OID(Object Identifier)
Un agent SNMP est installé sur la machine à surveiller. Cet agent ira chercher les
informations à récupérer. Pour cela, on lui précise à travers les OID quelles sont les
informations qu'il doit aller chercher. Pour chaque OID, il ira consulter les différents fichiers
de MIB afin de déterminer le nom et le type de l'information.
Ensuite avec une commande SNMP, il peut récupérer la valeur associée à l'OID. A savoir que
les OID sont des identificateurs d'objets qui identifient de manière unique les objets gérés
dans une hiérarchie MIB. C’est aussi une longue séquence de nombres. On dit aussi que c'est
une adresse utilisée pour identifier les périphériques et leurs statuts.
Un objet est simplement un élément sur lequel nous pouvons recueillir des informations. De
plus, tous les objets SNMP sont numérotés.
 MIB
Une MIB est une base de données des informations. La structure de la MIB est hiérarchique :
les informations sont regroupées en arbre. Chaque information a un identificateur d’objet, une
suite de chiffres séparés par des points, qui l'identifie de façon unique et un nom, indiqué dans
le document qui décrit la MIB. Par exemple, 1.3.6.1.2.1.2.2.1.2 est l’identificateur d’objet.
Un fichier de MIB contient des définitions de la structure de l’arbre global et des définitions
d’objets de types feuilles qui vont permettre la collecte d’informations. La MIB est une
structure arborescente dont chaque nœud est défini par un nombre ou OID (Object Identifier).
On dit aussi qu’une MIB est une collection d'informations organisée hiérarchiquement.
Les différents éléments d'information sont accessibles par un protocole tel que SNMP. Le
fichier MIB ne sert qu'au manager SNMP. Pour pouvoir interroger le switch par exemple, il va
nous falloir un navigateur MIB. Ce dernier est un outil qui vous permet d'extraire les données
des périphériques SNMP (switch, sondes, wifi, pare-feu) et qui permet aussi de récupérer et
d’afficher les données MIB, de définir des variables MIB, créer, modifier ou supprimer des
tableaux. Ce navigateur nous permet aussi d’afficher un fichier texte de manière graphique
avec l’arbre MIB. Par la suite, on peut faire appel à un logiciel qui va nous permettre de
superviser le système d’information tels que Zabbix, Shinken, Nagios, Cacti, MRTG par
exemple. Ces logiciels surveillent les hôtes et services et alertent quand les systèmes
rencontrent des problèmes et quand ils sont dans un état correct.
Si nous prenons l’exemple de Shinken qui est l’ainé de Nagios, on constate qu’il comporte six
phases soit : « arbiter », « scheduler », « poller », « reactionner », « broker », « receiver ».
Shinken possède sa propre interface de visualisation des statuts. Elle est incluse et installée
par défaut. Une MIB compatible SNMP contient des définitions et des informations sur les
propriétés des ressources gérées et les services supportés par les agents.
Les fonctionnalités gérables des ressources, telles qu'elles sont définies dans une MIB
compatible SNMP, s'appellent des objets gérés ou des variables de gestion. Pour ce qui est de
la description des objets qu’on note également SMI « Structure of Mana-gement Information
», on retrouve la notation de syntaxe abstraite appelé ASN.1 soit en an-glais, « Abstract
Syntax Notation ».
ASN.1 (Abstract Syntax Notation One) est un standard international. La MIB est justement
décrite à l’aide du SMI qui lui va permettre de représenter des structures de données. Il est
nécessaire de connaître certaines notions concernant ASN.1 pour pouvoir comprendre SMI et
la MIB. Les objets qui sont définit avec ASN.1 peuvent être des types comme integer, boolean
par exemple. Mais les objets peuvent également être des valeurs, des macros.
On note aussi, que les types commenceront par une majuscule, les valeurs, par une minuscule
et les macros sont en entièrement en majuscule. SMI est la syntaxe qui est utilisée pour
représenter les objets de la MIB décrite avec ANS.1. Cette syntaxe permet de décrire les
objets de la MIB avec leur syntaxe et leur état de standardisation par exemple. Quant à la MIB
SNMP, celle-ci est composée de différents objets, à savoir : des objets partiels qui vont servir
à construire l’arborescence de la MIB. Ils n’ont pas de type mais ont un OID. L’autre objet est
l’objet scalaire. Celui-ci à une instance unique et ont un type simple ASN.1 ou des types
dérivés de ceux-ci. Et le dernier objet est l’objet tabulaires. Une table est alors décrite comme
une séquence de lignes. Si on souhaite interroger le client, il va nous falloir lire sa MIB qui est
un fichier. Pour cela un logiciel de supervision sera installé sur la machine.
Ca peut être Ireasoning MIB Browser, soit un navigateur de MIB afin de lire les informations
du switch.
Deux solutions s’offriront à nous. Soit, on prend directement le fichier MIB du switch et on la
charge grâce à ce logiciel. Autrement, on tape l’adresse IP du switch directement dans le
logiciel afin qu’il puisse nous donner toutes les informations dont nous avons besoin. Une fois
l’OID obtenu, on peut se permettre d’interroger le switch via une requête snmpwalk ou autre
pour pouvoir récupérer la donnée. Mais toutefois, certains agents SNMP peuvent bloquer
l’accès à certaines informations, ce qui nous oblige à les contacter pour obtenir le fichier MIB
en intégralité.
Les autres requêtes nous permettant d’interroger le switch sont :
- Snmptranslate : apprentissage de l'arbre MIB.
- Snmpget : récupération de données d'un hôte.
- Snmpgetnext : récupération de données indexées inconnues.
- Snmpwalk : récupérer beaucoup de données à la fois
- Snmptable : afficher une table.
- Snmpset : effectuer des opérations d'écriture.
- Snmpbulkget : communique avec une entité réseau en utilisant la requête SNMP GETBULK
- Snmpbulkwalk : pour récupérer un sous-arbre de valeurs de gestion en utilisant les requêtes
SNMP GETBULK.
- Snmptrap : Envoi et réception de pièges, et agissant sur eux. Concernant maintenant la
lecture des OID.
Le format d’un OID peut confondre au début. La première partie de l’OID sera la même pour
chaque équipement que vous utiliserez, soit : .1 qui correspond à l’iso, le .3 qui lui correspond
à l’org, le .6 qui correspond au dod, le .1 qui correspond à l’internet, le .4 qui correspond au

privé et le .1 qui correspond à entreprise.
Vous n'avez pas besoin d'un fichier MIB pour utiliser SNMP ou effectuer des requêtes sur des
périphériques SNMP mais sans la MIB, vous n'allez pas savoir facilement ce que signifient les
données retournées par le périphérique. Dans certains cas, c'est facile comme le nom de l'hôte,
l'usage des disques ou les informations d'état des ports. Par ailleurs, cela peut être plus
difficile et une MIB peut être d'une grande aide.
Aperçu de l’architecure :
II. Etude comparative des outils de supervision :
Dans cette partie, nous vous présenterons brièvement les principaux outils de supervision
réseau choisis au vu de leur diversité ainsi que leurs avantages et inconvénients :
1. NetMRG
 Présentation
Créé en 2001, NetMRG veut se distinguer des autres en proposant des petites améliorations :
Visualisation des graphiques avec historiques et "auto-scroll", utilisation de modèles
(templates) pour plus facilement ajouter de nouveaux graphiques, mise à jour du logiciel
simplifiée, Gestion des jours de travail.
L'architecture logicielle est découpée en composants :
 Un moteur C++ chargé de récolter les données (Via scripts, Données SNMP ou
MySQL). Conçu dans le but de supporter une charge conséquente (Application
multithreadée grâce à pthreads). Ce moteur est au coeur de l'application, il ordonnance
les tâches et gère les interactions en plus de son rôle de "récolteur".
 RRDTOOL composant vu précédemment qui apporte sa puissante gestion des
données ainsi que ses atouts indéniables en matière de génération de graphique.
 Une base de donnée MySQL permettant de sauvegarder la configuration.
 Une interface réalisée grâce à PHP, qui permet de modifier la configuration et
d'afficher les graphiques au format PNG générés par RRDTOOL. Pour retrouver les
graphiques on doit tout d'abord passer par un arbre qui organise les différentes
machines et statistiques associées. Ce "Device Tree" affiche tout d'abord des groupes
(Group) lesquels contiennent des machines (Device), puis on accède aux différents
services ou valeurs monitorées (Sub device) avant de trouver à l'intérieur les
graphiques (Monitors). Des "events" sont également visibles en cas de problème.
 Avantages :
Performances : L'application semble pouvoir tenir la charge avec énormément de machines
surveillées grâce au moteur multithreadé.
 Alarmes : Il est possible de configurer des évènements qui avertissent l'administrateur

d'un fonctionnement anormal.
 Interface : L'interface permet de gérer un grand nombre de machines, classées dans des
groupes.
 Gestion des utilisateurs
 Inconvénients :
 Interface : L'interface n'est pas très accueillante et est déroutante au début.
 Configuration : Il n'est pas très aisé d'ajouter de nouveaux équipements à surveiller si

l'on sort du cadre du template prédéfinie.
 Un développement lent, peu de versions et très espacées dans le temps (environ une
année).
 Aucune gestion de carte de réseau, et aspect rudimentaire des alarmes. Aucune gestion
de panne.
2. Cacti
 Présentation
Tout comme NetMRG, Cacti se base sur RRDTOOL et se présente lui même comme étant
l'interface la plus complète à celui-ci. Cacti utilise également une base MySQL pour stocker la
configuration.
Depuis la version 0.8.6, Cacti propose un moteur de récolte des données en C, nommé Cactid,
utilisant avantageusement les Threads POSIX. Une stratégie qui ressemble étrangement à
celle réalisée par NetMRG sauf que Cacti propose de l'utiliser seulement si vous avez
réellement besoin de performances (dans le cas contraire c'est le moteur PHP qui prend le
relais).
On retrouve les mêmes fonctionnalités que NetMRG : Sources de données multiples via
scripts dans de multiples langages, gestion des utilisateurs et ajout d'équipement à partir de
modèles(templates) de configuration.
L'interface est divisée en deux, une partie nommée "Console" permettant de tout configurer et
une autre nommée "Graphs" permettant d'afficher les graphiques. L'originalité réside dans le
fait que la partie affichage de graphiques possède trois modes d'affichages :
 Tree mode : Ressemble à l'interface de NetMRG, classement en arbre des différentes

machines par groupes. Utile pour gérer un grand nombre de machines ou équipements.
 List mode : Permet de lister les graphiques présents sur une machine sélectionnée
dans la liste.
 Preview mode : Ressemble à List Mode excepté que les graphiques sont affichées
directement au lieu d'un lien vers celui-ci. Utile pour avoir un aperçu rapide de l'état
d'une machine et de ses services.
 Avantages
 Interface : Beaucoup plus claire que celle de NetMRG elle permet également
beaucoup plus de choses (Plus de modes d'affichages et plus de possibilités de
configuration)
 Configuration : Avec l'utilisation des templates pour les machines, les graphiques, et la
récupération des données tout se configure aisément et entièrement via l'interface web.
Import/ Export très simple des templates au format XML. On peut aussi très
facilement utiliser des options poussées de RRDTOOL
 Performance : Avec le choix du moteur de récolte des données, On peut opter pour la
performance ou la simplicité
 Gestion des utilisateurs
 Communauté sur le web, présence d'une dizaine de plugins permettant d'étendre les
fonctionnalités
 Inconvénients
 Pas de gestion d'alarmes, sauf avec un plugin nommé Thold
 Pas de gestion de panne et absence d'une cartographie de réseau
 Un développement lent tout comme NetMRG
3. Nagios :
 Présentation
Successeur de NetSaint, Nagios est certainement le logiciel libre le plus connu dans le milieu
de la supervision réseau. Appréciée des entreprises ainsi que des particuliers, cette application
possède une très grande communauté qui participent activement au développement.
L'architecture logicielle est modulaire comme chez ses concurrents :
 Le moteur qui gère l'ordonancement de la supervision, écrit en C

 L'interface Web réalisé à l'aide des CGI
 Des greffons, ou plugins qui étendent les possibilités de Nagios (Plus de 1200 plugins
existants sur nagiosexchange.org)
Il existe notamment des plugins Nagios nommée NRPE et NCSA qui fonctionnent un peu sur
le même principe que ceux de Zabbix. NRPE est un agent esclave qui attend les ordre du
moteur Nagios (polling) et NCSA envoi de lui même les données (trapping).
L'interface est divisée en trois :
 Partie monitoring, qui permet plusieurs vues : vue globale, vue précise, vue de la carte
du réseau, vue des problèmes, ... même une vue "3D".
 Partie reporting regroupant les tendances des statistiques, les alertes et évènements
ainsi qu'un rapport de disponibilités des services.
 Partie configuration classique permettant de tout configurer.
 Avantages
 Reconnu auprès des entreprises, grande communauté
 Plétore de plugins qui permettent d'étendre les possibilités (agents comme zabbix,
reporting amélioré, etc...)
 Une solution complète permettant le reporting, la gestion de panne et d'alarmes,
gestion utilisateurs, ainsi que la cartographie du réseaux
 Beaucoup de documentations sur le web
 Performances du moteur
 Inconvénients
 Interface non ergonomique et peu intuitive
 Configuration fastidieuse via beaucoup de fichiers
 Pour avoir toute les fonctionnalités il faut installer des plugins, de base c'est assez
limité.
4. Centréon :
 Présentation
Centréon, basé sur Nagios, se présente comme une évolution de celui-ci pour tout d'abord son
interface mais aussi ses fonctionnalités. Créé en 2003 par des français souhaitant améliorer
Nagios et son interface très austère, Centréon (anciennement Oréon) a été repris par une
nouvelle entreprise nommée Merethis.
Centréon reprend donc les avantages du moteur de Nagios et permet ainsi d'être entièrement
compatible avec des solutions existantes. Son interface reprend un découpage classique :
 Home : Page d'accueil avec Le "Tactical Overview" de Nagios permettant un coup

d'oeil rapide aux problèmes survenus et accès aux statistiques des performances du
moteur et de ses composants.
 Monitoring : Possède plusieurs vues, mais reprend la grande idée de l'arbre des
groupes d'équipements. Reprend également la vue Nagios.
 Views : Permet d'accéder à tous les graphiques avec un menu arborescent. Accès à une
cartographie du réseau en applet Java.
 Reporting : Un dashboard ressemblant à celui de Zabbix en ajoutant une frise

chronologique de la disponibilité de l'équipement.
 Configuration : Pour tout configurer de A à Z.
 Administration : Configuration des accès utilisateurs.

Toujours visibles en haut à gauche, un tableau récapitulatif du nombre de machines actives et
des éventuelles machines ne répondant plus pour toujours garder un oeil sur l'ensemble du
réseau.
 Avantages
 La robustesse et la renommée de Nagios
 Une interface beaucoup plus sympathique, permettant de tout configurer, de garder un
oeil sur tout le réseau en permanence
 Les utilisateurs de Nagios ne seront pas perdus pour autant, l'interface reprenant
avantageusement certaines vues Nagios
 Une solution complète permettant le reporting, la gestion de panne et d'alarmes,
gestion utilisateurs, ainsi que la cartographie du réseaux
 Une entreprise qui pousse le développement
 Peut être décorelé du serveur Nagios et tourner tout seul sur un autre serveur
 Inconvénients
 L'interface peut paraître complexe car il existe beaucoup d'options, de vues....cela
nécessite une petite formation
 Un développement qui n'est pas encore en phase avec celui de Nagios : Parfois des
problèmes de compatibilité
 Un peu plus lourd que du Nagios pur
5. Zabbix :
 Présentation
Créé en 2001, puis donnant naissance à une entreprise nommée Zabbix SIA en 2005, Zabbix
est une solution de supervision open-source de plus en plus prisée. L'entreprise vise à faire de
Zabbix un logiciel reconnu dans le milieu de la supervision et créer une communauté autour
de lui pour permettre une évolution plus rapide. A côté de cela, cette societé propose un
service de maintenance commercial.
Zabbix permet plusieurs moyens d'acquérir les données :
 Via SNMP : comme tous ses concurrents

 Via test de service : Il n'y a rien a installer sur l'équipement surveillé, mais les tests
sont limités à des ping ou test de protocoles (SMTP, HTTP,...)
 Via l'agent Zabbix local : C'est une originalité, installer un agent permet d'obtenir toute
information sur l'équipement sans utiliser le protocole SNMP
L'architecture logicielle est découpée en composants dans le but de faciliter le monitoring
distribué :
 Serveur : Le serveur est le coeur de l'application Zabbix. Il centralise les données et

permet de les attendre (trapping) ou d'aller les chercher (polling). Il centralise aussi
toutes les informations de configuration et permet d'alerter les administrateurs en cas
de problème.
 Le proxy : Élément optionnel de l'architecture, il permet de bufferiser les données

reçus des différents sites dans le but d'alléger les traitements pour le serveur.
 L'agent : Une fois installé sur un système, l'agent va collecter les données locales et les
envoyer au serveur.
 L'interface Web : Celle-ci est une partie du serveur bien qu'il n'est pas obligatoire
qu'elle se trouve sur la même machine que le serveur. L'interface permet de configurer
entièrement Zabbix, d'accéder aux statistiques ainsi qu'à d'autres informations
Tous ces composants sont écrits en C afin de garder de hautes performances, hormis bien
évidemment l'interface Web développée en PHP.
L'interface est divisée en cinq parties :
➢ Monitoring : La partie affichage des statistiques, graphiques, alertes, cartographie..etc..
➢ Inventory : l'inventaire des machines et équipements
➢ Report : Statistiques sur le serveur Zabbix et rapport de disponibilité des services sur
les machines supervisées
➢ Configuration : Comme son nom l'indique, permet de configurer entièrement Zabbix
➢ Administration : Permet de gérer les moyens d'alertes (SMS, Jabber, Email, ...) et les
utilisateurs
➢ Avantages
 Une solution très complète : cartographie de réseaux, gestion poussée d'alarmes via
SMS, Jabber ou Email, gestion des utilisateurs, gestion de pannes, statistiques et
reporting
 Une entreprise qui pousse le développement, et une communauté croissante
 Une interface vaste mais claire
 Une gestion des templates poussée, avec import/export xml, modifications via
l'interface
 Des performances au rendez-vous : l'application a été testée avec succès avec 10000
équipements supervisés
 Compatible avec MySQL, PostgreSQL, Oracle, SQLite
 Inconvénients
 Interface est un peu vaste, la mise en place des templates n'est pas évidente au début :
petit temps de formation nécessaire
 L'agent zabbix communique par défaut en clair les informations, nécessité de sécuriser
ces données (via VPN par exemple)
 Commence à être connu, mais pas encore auprès des entreprises : Peu d'interfaçage
avec d'autres solutions commerciales
III. Choix de notre outil de supervision
Pour notre projet sur la métrologie et la supervision, nous avions décidé de choisir Zabbix
comme outil compte tenu de ses avantages et de sa performance, capable de gérer un parc
important de machines. L’interface utilisateur de Zabbix est une interface web tournant donc
sur un serveur web, ce qui fait qu’on a pas besoin de logiciels particuliers côté client pour
pouvoir bénéficier de Zabbix, aussi il est relativement léger et peut-être installé sur un serveur
web peu performant ou sur un serveur utilisé pour un autre service même s’il est préférable
par mesure de sécurité, de l’installer sur un serveur non accessible à l’extérieur du service
informatique.
L’aspect crucial de notre choix a été qu’avec zabbix, en plus du protocole SNMP utilisé par la
quasi-totalité des logiciels de supervision d’un réseau informatique, zabbix lui peut superviser
un réseau informatique sans utiliser le protocole SNMP mais les Agents zabbix. En
effet,l'équipe de Zabbix met à disposition des outils nommés Agent Zabbix. Ces agents sont
des services à installer ( executable pour windows, paquets ou source de dépôt pour linux )
sur chaque équipement, qui tournent en arrière plan, et communiquent régulièrement avec le
serveur Zabbix. Contrairement au SNMP qui peut être délicat à mettre en place sur un serveur
par exemple, les agents s'installent et se configurent très facilement. On peut ainsi avoir accès
à énormément de données, telles que l'utilisation de la bande passante sur chaque carte réseau,
l'utilisation du processeur, de la ram, du disque dur, … La limite de ce système, est qu'il n'est
pas envisageable de l'installer sur un routeur ou un switch par exemple, là où le SNMP reste le
plus adapté. Les agents Zabbix sont cependant disponibles pour beaucoup de plate-formes ;
Linux, Windows ( à partir de windows 2000 ), IBM AIX, IBM Power8, FreeBSD, NetBSD,
OpenBSD, HP-UX, Mac OS X, et Solaris.
Aussi pour la simplicité de ses fonctionnalités :

• Création facile d’hôtes : Avec Zabbix, on a pas besoin de passer par l’édition/création
de fichiers pour pour créer un hôte à surveiller, comme nous aurions à le faire avec
nagios par exemple. Il n'y a qu'à choisir le type de communication ( agent zabbix,
SNMP, … ) et remplir les différents champs et valider.
Lorsque l'agent Zabbix sera installé et configuré sur l'équipement à surveiller, l’icône
ZBX passera au vert. S'il y a une erreur de configuration ou d'installation, il sera en
rouge. Il en va de même pour les autres protocoles.
• Création facile de déclencheurs : Sur le même principe que pour la création d'hôte, on
peut créer assez facilement des déclencheurs. Un déclencheur apparaît dans le tableau
des erreurs si sa condition a été vérifiée.
L'intérêt de pouvoir créer des déclencheurs est de pouvoir adapter Zabbix à son
infrastructure réseau et à ses besoins, si nécessaire. Comme par exemple des tests de
ping pour vérifier une liaison.
• Importation de listes d’hôtes/templates : Lors de la migration d'un serveur Zabbix par
exemple, on peut sauvegarder sa liste d’hôtes, pour l'importer sur le nouveau serveur
Zabbix. Il y a aussi possibilité d'importer des templates d'équipements, fichiers
rassemblant une liste de triggers. Cela peut être très utile lorsque l'on a un équipement
capable de communiquer avec SNMP, mais que l'on n'a pas le temps de créer tous les
triggers dont on a besoin, ou parce qu'on ne sait pas à quoi correspondent tous les
OID. Sur le site de Zabbix, il y a une base de données de templates crées en général
par des utlisateurs.
• Graphiques,cartes,écrans et diaporamas : Que serait un superviseur réseau sans
graphiques ? Zabbix propose de base de nombreux graphiques remplis avec les
informations des triggers de templates présents. Mais Zabbix offre aussi la possibilité
de créer ses propres graphiques.
Une carte réseau permet de représenter son infrastructure réseau avec des éléments dy
namiques, comme la couleur des liens selon leur état, des valeurs de bande passante,
… Zabbix possède de base un certain nombre d'images, mais on peut importer nos
propres images si on le souhaite.
Un écran est une entité rassemblant un ensemble d’entités, qui peuvent être des gra
phiques, d'autres écrans, des cartes, … Ceux ci permettent de faire des pages regrou
pant tout un tas de données, sans à avoir à basculer entre les différents éléments.
• Messages d’information:courriel et push : Enfin, l'une des fonctions très utile que
présente Zabbix est l'alerte par courriel, ou par message push ( android ) en installant
un plugin.
Le niveau d'alerte pour qu'un message soit envoyé peut être défini. Ainsi, à chaque
événement que l'on juge important, on peut recevoir un message rapportant l'erreur.
Conclusion :
Après avoir choisi Zabbix comme outil de supervision convenable, au travers de ses
différentes fonctionnalités, est relativement puissant, simple d'utilisation et de configuration.
Il a l'avantage d'avoir une communauté active, qui partage facilement des astuces, plugins,
templates. Nous allons donc l’étudier en profondeur pour faciliter sa mise en œuvre. Il sied de
signaler que Zabbix comme la plupart des logiciels de supervision cités ci-dessus sont en
Open Source.
IV. Etude technique détaillée de Zabbix :
Introduction :
Dans cette partie de notre rapport, nous commencerons par présenter l’outil Zabbix,son
principe de fonctionnement dont son architecure mais aussi notre solution ainsi que son
installation et la configuration mise en place pour répondre aux attentes du projet.
Présentation de zabbix :
Zabbix a été créé par Alexei Vladishev, et est actuellement activement développé et soutenu
par ZABBIX SIA.C’est une “entreprise-class open source distributed monitoring solution”.
Zabbix est un logiciel qui supervise de nombreux paramètres réseaux ainsi que la santé et
l'intégrité des serveurs. Il utilise un mécanisme de notification flexible qui permet aux
utilisateurs de configurer une base d'alerte e-mail pour pratiquement tous les événements.
Cela permet une réponse rapide aux problèmes serveurs. Zabbix offre un excellent reporting
et des fonctionnalités de visualisation de données basées sur les données stockées. Cela rend
Zabbix idéal “for capacity planning”.
Zabbix supporte à la fois “polling et trapping”. Tous les rapports et statistiques, comme la
configuration de paramètres, sont accessibles par l'interface web. L'interface web veille à ce
que le statut de votre réseau et de vos serveurs puisse être évalué depuis n'importe quel
endroit. Correctement configuré, Zabbix peux jouer un rôle important dans la supervision de
l'infrastructure IT. Ceci est également vrai pour les petites organisations avec peu de serveurs
ainsi que pour les grandes entreprises avec une multitude de serveurs.
Zabbix est gratuit. Il est écrit et distribué sous Licence publique générale GNU version 2. Cela
signifie que son code source est librement distribué et disponible pour le public. Le support
gratuit et commercial est disponible et fourni par Zabbix Company.
Grâce à zabbix, on a les possibilités suivantes :
 Découverte automatique des serveurs et périphériques réseaux

 Supervision répartie sur une administration web centralisée
 Support des mécanismes “polling and trapping”
 Logiciels serveurs pour Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, X
 Agent haute performance en natif (Logiciel client pour Linux, Solaris, HP-UX, AIX,
Free BSD, Open BSD, X, Tru64/OSF1, Windows NT4.0, Windows 2000, Windows
2003, Windows XP, Windows Vista)
 Supervision sans agent
 Authentification d'agent sécurisée
 Permissions utilisateurs flexibles.
 Interface web
 Notification par e-mail d'événements prédéfinis
 Haut niveau (business) de visualisation des ressources supervisées

 Log d'audit
Zabbix attire plusieurs organisations de différentes tailles dans le monde en tant que
plateforme de supervision principale.
Fonctionnement :
Pour son fonctionnement, Zabbix possède plusieurs composants, à savoir :
➢ Zabbix server :
Comme composant principal, zabbix Server permet une surveillance à distance(et en local) du
bon fonctionnement de différents services systèmes et réseaux, tels que : les serveurs Web, les
serveurs de courriers, ou bien encore les serveurs , …etc. Il gère la notification par mail, afin
d’avertir les administrateurs de toute nouvelle alerte.
Comme nous l’avions dit dans la partie portant choix de Zabbix comme outil de supervision,
que Zabbix à travers son composant Zabbix server peut fonctionner sans avoir recours au
protocole SNMP en utilisant les agents. Aussi, Zabbix peut fonctionner sans avoir recours aux
agents en utilisant le protocole SNMP, mais dans ce cas, il ne remontera qu’une quantité
limitée d’informations.
➢ Zabbix Fronted
Deuxième composant essentiel après Zabbix Server, Zabbix Frontend est tout simplement
l’interface de visualisation des événements, mais aussi, et surtout l’interface d’administration
et de configuration de Zabbix.
Zabbix Frontend, étant une interface Web (php), a l’avantage d’être accessible depuis
n’importe quelle plateforme possédant un navigateur internet.
➢ Zabbix Proxy
Zabbix Proxy permet de collecter des informations sur la performance et la disponibilité des
données sur un hôte, avant de les transmettre au Zabbix Server.
Zabbix Proxy offre la possibilité de réduire la charge d’un serveur Zabbix. En effet, toutes les
informations collectées peuvent être traitées en local, avant leur transmission au serveur.
Le Proxy de Zabbix est idéal pour une surveillance centralisée de sites distants, fonctionnant
comme un serveur intermédiaire, il remplit parfaitement son rôle de collecteur de données
d’équipements variés. Distant d’un serveur Zabbix, il agit comme une sonde de collecte et de
traitement des données.
➢ Zabbix Agent
Bien qu’optionnel, se passer du Zabbix Agent serait une erreur, car même si le serveur Zabbix
peut fonctionner sans agent, l’usage de ces derniers permet une meilleure surveillance des
hôtes, et donc une supervision plus accrue.
L’installation d’un Zabbix Agent sur un hôte offre essentiellement une surveillance active des
ressources locales, des applications, … etc. L’agent envoi toutes informations supervisée au
Zabbix Server.
Interactions :
➢ Principes de fonctionnement :
Modulable qu’il est, Zabbix dispose d’une capacité d’adaptation aux infrastructures à la fois
pratique, et simple à mettre en place.
Entre ses différents composants, il existe un certain nombre d’interactions, utiles à connaître
afin d’en comprendre au mieux le fonctionnement :
Dans la figure ci-dessus, les composants de Zabbix sont regroupés en trois blocs, le premier
bloc coloré en vert clair représente lui la partie serveur de Zabbix, comprenant les composants
Server et Frontend, qui sont essentiels au fonctionnement et à l’administration d’un serveur
Zabbix. Ces deux composants utilisent une base de données, servant à stocker les données de
supervision, et également pour les afficher dans l’interface Web.
Quant aux deux autres blocs à savoir les blocs colorés en orange et jaune clair, représentent
eux respectivement la partie Agent et Proxy de Zabbix. L’agent peut interagir avec le proxy,
en transférant ses données non-plus directement vers le serveur Zabbix, mais plutôt vers le
proxy. Ce dernier agissant comme un serveur intermédiaire, c’est-à-dire un collecteur, il

utilise donc comme pour Zabbix Server une base de données.
➢ Gestion des flux :
La figure suivante montre les protocoles et flux utilisés par les différents éléments qui
composent une supervision Zabbix :
➢ Checks actifs/passifs :
Pour communiquer avec les Zabbix agents, Zabbix utilise le protocole JSON.
• Checks passifs :
Comme l’illustre la figure suivante, dans Zabbix, les checks passifs sont en réalité, que de
simples requêtes de données émises par le serveur (Zabbix Proxy ou Server) à l’agent installé
sur un hôte à superviser. Le Zabbix Agent répond ensuite à la requête.
Pour mieux illustrer le fonctionnement avec un cas concret, voici un exemple :

1. Le serveur ouvre une connexion TCP avec l’agent
2. Le serveur envoi une requête agent.ping\n
3. L’agent réceptionne et lit la requête
4. Réponse de l’agent au serveur avec <HEADER><DATALEN>1
5. Le serveur analyse la réponse de l’agent et récupère la valeur demandée 1
• Checks actifs :
A la différence des checks passifs, les checks actifs n’attendent pas la requête du serveur pour
envoyer les données, en effet, les checks actifs effectuent eux-mêmes les tests de manière
périodique, puis ils transmettent les différents résultats au serveur. Le processus de
fonctionnement des checks actifs peut être décomposé en 2 parties :
Récupération de la liste des items

Pour chaque hôte supervisé (configuré) sur le serveur Zabbix, un certain nombre d’items (par
l’intermédiaire des templates) sont définis. Lorsqu’un agent est démarré en mode actif, il
effectue une requête au serveur afin de récupérer sa liste d’items.
Voici un exemple un peu plus concret :

1. L’agent ouvre une connexion TCP avec le serveur
2. L’agent demande ensuite sa liste d’items
3. Le serveur répond en envoyant la liste d’items propres à cet agent
4. L’agent réceptionne la réponse du serveur
5. La collecte des données définis par les items démarre
Envoi des données collectées

Une fois la liste des items récupérés par l’agent, ce dernier démarre alors sa collecte de
données à un intervalle régulier pour chaque item. Il transmet ensuite au serveur les données,
et reçoit une réponse de celui-ci pour confirmer la bonne réception.
Exemple du processus d’envoi de données :

1. L’agent ouvre une connexion TCP avec le serveur
2. L’agent envoi sa liste de valeurs (données collectées pour chaque item)
3. Le serveur réceptionne et traite les données
4. Le server retourne le statut à l’agent
Systèmes d’alertes :
• Terminologie
Item : un item est un élément qui teste des services et collecte des données.
Trigger : génère un évènement en réaction à une certaine valeur ou donnée re
montée par un item.
Action : envoi des alertes (notifications), en fonction d’évènements précis gé nérés
par des triggers.
• Principe de fonctionnement
Dans Zabbix, la génération d’une alerte est le résultat d’un enchaînement de conditions. Voici
un schéma montrant les différentes relations entre les 3 éléments essentiels de Zabbix pour la
génération d’une alerte, c’est-à-dire l’item, le trigger et l’action.
Dans le processus de génération d’une alerte, le premier maillon de la chaîne est l’item. Cet
élément collecte les données à surveiller, comme par exemple « Est-ce que le port 522 est
ouvert ? », ensuite, le trigger chargé de surveiller cet item, en fonction de ses conditions et des
valeurs remontées par l’item, il génère un évènement de type PROBLEM, UNKNOW ou OK
(avec différents niveaux de criticités possibles).
Pour créer une alerte, le 3ème et dernier élément de Zabbix à entrer en jeux est l’action. Celui-
ci fonctionne comme le trigger, à la différence qu’il surveille les évènements créés par le
trigger (au lieu des valeurs remontées par les items pour ce dernier) , selon ses conditions, il
génère alors une alerte (ou notification) de type EMAIL, SMS, ou encore JABBER.
Architecture :
➢ Mono-serveur :
Architecture la plus simple de Zabbix, le choix de l’installation d’un seul serveur répond
avant tout à des besoins propres à de petites ou moyennes entreprises.
La mise en place d’une architecture mono-serveur (standalone) est des plus classiques, on y
retrouve un serveur Zabbix, à partir duquel sont surveillés des agents Zabbix, des
équipements SNMP, IPMI, ou encore tout autre système ou service.
➢ Distribuée :
Lorsque les infrastructures et/ou les besoins ne permettent pas l’utilisation d’un mono-serveur,
il faut alors mettre en place une architecture distribuée. Zabbix permet 3 types de supervision
distribuée :
• Multi-serveur
Le premier type d’architecture distribuée de Zabbix correspond à l’association de plusieurs
Zabbix Server. Cette architecture permet par exemple de mettre en place deux serveurs dans 2
sites distants, avec une administration locale de la supervision pour chacun d’entre eux.
L’usage d’une architecture multi-serveur permet de combiner l’administration décentralisée et

centralisée, offrant ainsi des possibilités organisationnelles intéressantes.
• Multi-proxy
Selon les besoins d’administration de la supervision d’une infrastructure, un seul serveur
Zabbix peut suffire, à partir duquel l’ensemble des hôtes seront gérés, puis pour la collecte de
données, l’ajout de plusieurs proxys Zabbix vont permettre de recueillir toutes les
informations des équipements supervisés dans différents lieux, avant de les transmettre au
serveur Zabbix.
Avec une architecture multi-proxy, l’administration est centralisée sur un seul serveur Zabbix,
et utilise plusieurs proxy, à savoir des collecteurs, afin de remontées les données de différents
sites, secteurs d’une infrastructure IT.
• Multi-serveur et Multi-proxy
Lorsqu’il est nécessaire d’administrer localement plusieurs sites, bâtiments différents,
l’utilisation de plusieurs serveurs Zabbix combinés à des collecteurs (proxy) devient alors
indispensable. Grâce à cette combinaison, il devient alors possible de mettre en place de
vastes architectures de supervision, parfaitement optimisé pour répondre correctement aux
besoins de supervision d’une infrastructure.
En combinant les architectures multi-serveur et multi-proxy, il est alors possible à la

fois de centraliser et de décentraliser l’administration de la supervision, tout en
utilisant des collecteurs pour des zones ne nécessitant pas une administration locale.
Conclusion :
Après avoir bien étudié l’outil de supervision que nous avions choisi, nous allons
passer au chapite lié à la mise en place de notre projet.
V. Présentation du projet :
A prendre dans le wiki
Description du projet :
Il s'agit de prendre en main l'outils Zabbix et d'alimenter sa base de données à par

des fichiers de logs existants dans un premier temps pour la validation de principe à
partir des logs des onduleurs à insérer dans la base de données de Zabbix
paramétrage de seuil et niveau d'alerte, représentation graphique … L'outils sera à
installer sur la plateforme de développement dans une machine virtuelle exportable
puis éventuellement sur machine physique.

1. Installation et configuration d'Ubuntu Server 18.04.1 LTS sur une machine

virtuelle
• Prérequis :
- Avoir installé Virtualbox sur notre système hôte
- Avoir une image d’installation d’Ubuntu Server 18.04.1 LTS
• Installation :
Initialisation du système invité :

 Lancer Virtualbox
 Pour ajouter une nouvelle machine virtuelle cliquez sur « Nouvelle »

 Nom : Choisir le nom que vous voulez pour votre nouvelle machine
virtuelle
 Type : choisir Linux
 Version : choisir Ubuntu (64-bit)
 Cliquer sur «Suivant ».
➢ Laisser par défaut ou allouer plus de mémoire à la machine virtuelle si

besoin.
➢ Cliquer sur “Suivant”.
 Laisser par défaut sur “Créer un disque virtuel maintenant”.

 Cliquer sur « Suivant »
➢ Laisser par défaut sur “VDI” pour le type de fichier de disque dur.
➢ Cliquer sur “Suivant”.
 Choisir entre un fichier de disque dur dynamiquement alloué ou un fichier

de taille fixe sachant que le premier est plus lent mais prend seulement
l'espace nécessaire pour la machine virtuelle et que le second aura une
taille fixe.
 Cliquer sur « Suivant »
 Choisir l'emplacement du fichier de disque dur virtuel sur votre machine

(Sachant que par défaut l'emplacement est dans home/user/VirtualBox Vms).
 Choisir la taille du fichier de disque dur virtuel (10 Go semblent raisonnables
pour cette machine).
 Cliquer sur « créer»
➢ Pour démarrer votre machine virtuelle la sélectionner dans la liste puis cliquer sur
“Démarrer”.
➢ Une fenêtre s'ouvre demandant une image disque pour l'installation du système,
sélectionner l'emplacement de l'image d'Ubuntu Server.Cliquer sur “Démarrer”
Installation d'Ubuntu Server 18.04.1 sur la machine virtuelle

➢ Laisser le chargement s'effectuer jusqu'à ce que votre écran affiche
comme l'image ci-dessous.
➢ Se déplacer avec les flèches directionnelles et sélectionner “Français” puis

presser la touche Entrée.
➢ Pour le layout (la disposition du clavier) sélectionner “Français”, laisser la variante

sur “Français” et sélectionner “Terminé” ensuite.
➢ Sélectionner “Installer Ubuntu”.

➢ Ne rien modifier concernant le réseau, sélectionner “Terminé”.
➢ Ne pas configurer de proxy hormis si besoin, sélectionner “Terminé”.

➢ Laisser le miroir par défaut, sélectionner “Terminé”.
➢ Sélectionner “Utiliser un disque dur entier”.

➢ Sélectionner le premier disque apparaissant.
➢ Après avoir vu le récapitulatif, selectionner “Terminé”.

➢ Sélectionner “Continuer”.
➢ Your name : choisir le nom que vous souhaitez.
➢ Your server's name : choisir un nom pour votre serveur.
➢ Pick a username : choisir un nom d'utilisateur.
➢ Choose a password : choisir un mot de passe.
➢ Confirm your password : retaper le mot de passe.
➢ SSH identity : ne pas en importer.
➢ Sélectionner “Terminé”.
➢ Ne pas ajouter de snaps, sélectionner “Terminé”.

➢ Laisser l'installation s'effectuer.
➢ Sélectionner “Redémarrer maintenant”.

➢ Retirer l'image disque des lecteurs optiques (décocher l'image disque).
2. Configuration
Configuration du réseau et d'Ubuntu Server

- Lancer le système invité dans VirtualBox
Réglages réseau VirtualBox
- Aller dans Périphériques → Réseau → Réglages réseau

- Pour la carte 1, choisir le mode d'accès réseau : accès par pont.
Vous pouvez désormais accéder à votre système invité via le réseau privé. Consultez votre
adresse IP privée avec la commande suivante :
Elle sera à côté de “inet” et du type 192.X.X.X ou 172.X.X.X ou 10.X.X.X. L'adresse

127.0.0.1 est le localhost (hôte local).
Il est possible que votre adresse privée ne soit pas attribuée tout de suite pour cela vous
pouvez redémarrer votre système invité (commande reboot) ou faire la commande suivante :
A priori enp0s3 est le nom de l'interface réseau physique sur le système invité vous pouvez
vérifier que c'est bien celui-ci avec la commande ip précédente.
Si vous utilisez plusieurs fois les mêmes images .ova de système invité sur le même réseau
privé il est possible qu'elles utilisent la même adresse ip ce qui pose des problèmes
(notamment au niveau du frontend Zabbix au lieu d'aller sur le votre depuis votre adresse
privée vous pourriez aller sur celui d'un autre système invité). Pour régler ceci nous avons
utilisé la commande suivante :
Avec X.X.X.X l'adresse ip privée désirée.
Accès par SSH

Vous pouvez désormais accéder à votre système invité via SSH sur votre système
hôte car le système hôte a désormais une adrresse privée. Il vous suffit de vous
connecter avec la commande suivante :
Puis tapez votre mot de passe.
Ajout des dépots
- Lancer la commande suivante pour modifier la liste des dépôts.
- Choisir l'éditeur de texte que vous souhaitez (par exemple nano).

- Remplacer le texte par celui-ci (vous pouvez utiliser ctrl+maj+v pour coller dans nano
si vous êtes en ssh).
- Mettre à jour les dépots avec cette commande.
- Mettre à jour les paquets avec cette commande.
Votre système invité Ubuntu Server 18.04.01 LTS est désormais prêt pour l'installation de Zabbix.
3. Installation et configuration de Zabbix sur la machine virtuelle
Prérequis :
- Bien avoir installé et configuré Ubuntu Server (cf les namespaces précédents).
Installation de zabbix
Nous travaillerons ici avec la version 4.0 de Zabbix pour Ubuntu 18.04 avec une base de
donnée Mysql.
Installer le dépot avec la base de donnée MySQL
- Pour obtenir le paquet du dépôt Zabbix tapez la commande suivante :
- Pour installer le dépôt, tapez :
- Mettez à jour les sources :

Installation du serveur, le frontend et l'agent zabbix

- Tapez la commande suivante :
Créer la base de donnée initiale

- Tapez la commande suivante :
- Puis lancez ces requễtes mysql (remplacez password par le mot de passe de
votre choix) :
- Tapez exit pour quitter mysql.

- Puis lancez la commande suivante :
Configurer la base de donnée pour le serveur Zabbix

- Editez le fichier /etc/zabbix/zabbix_server.conf en mode
superutilisateur.Au niveau de la ligne “# DBPassword=” décommentez la
en supprimant le '#' puis ajoutez le mot de passe précedemment saisi
après le '='. Puis au niveau de la ligne “# DBHost=” la remplacer par
“DBHost=localhost”
Configurer PHP pour le frontend Zabbix
- Editez le fichier /etc/zabbix/apache.conf en mode superutilisateur.
- Aux lignes suivantes (il y en a 2 dans le fichier) décommentez en supprimant le

'#' et ajoutez le bon fuseau horaire pour vous. Ce qui donne en France :
Démarrer le serveur Zabbix et l'agent

- Tapez les commandes suivantes :
Votre frontend Zabbix est désormais accessible à l'adresse suivante : http://votreipprivée/zabbix

Nous allons maintenant le configurer !
Configuration
- Configuration du front-end et de zabbix

- Configuration SSH dans zabbix
Par défaut, le serveur Zabbix n'est pas configuré pour effectuer des contrôles SSH.
Par conséquent, les éléments SSH ajoutés ne fonctionneront pas. Pour changer
cela,ouvrez le fichier de configuration /etc/zabbix/zabbix_server.conf en tant que root
et cherchez la ligne suivante:
Décommentez la chaîne SSHKeyLocation et spécifiez le chemin du répertoire

contenant les clés :
Enregistrez le fichier puis redémarrer zabbix-server:
Générez les clés publiques et privées avec la commande :
Appuyez sur entrée si le chemin est /home/zabbix/.ssh/id_rsa et laissez la phrase secrète vide.
Copiez la clé générée sur le serveur qui sera surveillé par SSH avec la commande :
3. Développement
Insertion des anciens logs dans la base de données ZABBIX via un script bash
Prérequis
- Il faut configurer l'accès SSH par clé publique plutôt que par mot de passe (cf
configuration SSH dans Zabbix)
Ce script permet de copier tous les logs depuis janus vers la base de données de Zabbix.
4. Récupération des valeurs de la dernière ligne du fichier log

Prérequis
- Il faut configurer les agents SSH, voir la partie configuration des éléments
Ce script s'exécute par les agents SSH toutes les 30s.

Remarques :

Conclusion générale :
L’objectif de notre projet était de permettre aux techniciens du département informatique de
l’université d’Angers de mieux superviser les équipements et les services de son réseau. En
effet une solution de supervision permet de diminuer le taux lors de diagnostic des pannes et
faciliter les tâches de l’administrateur réseaux.
Plus le nombre des équipements et des services informatiques augmente plus les
tâches des techniciens deviennent trop compliquées et il n’arrive pas à les assurer
convenablement ce qui engendre une perte du temps et un travail con accomplie.
Notre travail consistait à mettre en place un outil de supervision système et réseau sous
Zabbix. Dans
un premier lieu, nous avons pu réaliser une étude comparative entre les différentes solutions
open source existantes sur le marché. Dans la partie réalisation, nous avons mis en place
l’outil Zabbix et le configurer sur le serveur UBUNTU pour une meilleure supevision et
alerter les techniciens par mail en cas de pannes.
Comme perspectives, nous proposons l’amélioration de ce travail par :
-

Zabbix

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Zabbix

Transféré par

Droits d'auteur :

Formats disponibles

Université d’Angers

Projet tutoré de Licence professionnelle : systèmes

Meé trologie et monitoring sous Zabbix

Table des matières

Liste des participants au projet

NOM(S) ET PRENOM(S) FONCTION RÔLES

Le premier chapitre sera intitulé « Principes généraux » présente un rappel du principe de

Le deuxième chapitre a pour objectif de présenter l’étude théorique de la solution de

Le troisième et dernier chapitre intitulé « Mise en place de la solution adoptée » présente

Chapitre 1 : Principes généraux

 Supervision système : La surveillance se cantonne dans ce cas à la machine elle-

2. La norme ISO 7498/4:

Le concept de supervision a été normalisé par l’ISO (International Organization for

2.1. Gestion des performances :

Les performances du réseau sont évaluées à partir de quatre paramètres :

2.2. Gestion des configurations (Management configuration)

La gestion de configuration permet d’identifier, de paramétrer et de contrôler les différents

2.3. Gestion de la comptabilité(Accouting management)

2.4. Gestion des anomalies(Fault Management)

La gestion des fautes permet la détection, la localisation et la correction d’anomalies

2.5. Gestion de la sécurité(Security Management)

Elle a également pour rôle de mettre en application les politiques de sécurité.

Simple Network Management Protocol », en français « Protocole simple de gestion de réseau

à l’org, le .6 qui correspond au dod, le .1 qui correspond à l’internet, le .4 qui correspond au

II. Etude comparative des outils de supervision :

 Alarmes : Il est possible de configurer des évènements qui avertissent l'administrateur

 Interface : L'interface n'est pas très accueillante et est déroutante au début.

 Configuration : Il n'est pas très aisé d'ajouter de nouveaux équipements à surveiller si

 Tree mode : Ressemble à l'interface de NetMRG, classement en arbre des différentes

 Le moteur qui gère l'ordonancement de la supervision, écrit en C

L'interface est divisée en trois :

 Home : Page d'accueil avec Le "Tactical Overview" de Nagios permettant un coup

 Reporting : Un dashboard ressemblant à celui de Zabbix en ajoutant une frise

 Configuration : Pour tout configurer de A à Z.

 Administration : Configuration des accès utilisateurs.

Zabbix permet plusieurs moyens d'acquérir les données :

 Via SNMP : comme tous ses concurrents

 Serveur : Le serveur est le coeur de l'application Zabbix. Il centralise les données et

 Le proxy : Élément optionnel de l'architecture, il permet de bufferiser les données

III. Choix de notre outil de supervision

Aussi pour la simplicité de ses fonctionnalités :

IV. Etude technique détaillée de Zabbix :

 Découverte automatique des serveurs et périphériques réseaux

 Haut niveau (business) de visualisation des ressources supervisées

Pour son fonctionnement, Zabbix possède plusieurs composants, à savoir :

proxy. Ce dernier agissant comme un serveur intermédiaire, c’est-à-dire un collecteur, il

➢ Gestion des flux :

Pour mieux illustrer le fonctionnement avec un cas concret, voici un exemple :

Récupération de la liste des items

Voici un exemple un peu plus concret :

Envoi des données collectées

Exemple du processus d’envoi de données :

L’usage d’une architecture multi-serveur permet de combiner l’administration décentralisée et

En combinant les architectures multi-serveur et multi-proxy, il est alors possible à la

A prendre dans le wiki

Il s'agit de prendre en main l'outils Zabbix et d'alimenter sa base de données à par

A prendre dans le wiki

1. Installation et configuration d'Ubuntu Server 18.04.1 LTS sur une machine

- Avoir installé Virtualbox sur notre système hôte

- Avoir une image d’installation d’Ubuntu Server 18.04.1 LTS

Initialisation du système invité :

 Pour ajouter une nouvelle machine virtuelle cliquez sur « Nouvelle »

➢ Laisser par défaut ou allouer plus de mémoire à la machine virtuelle si