Bachelier en informatique et systèmes Stage en entreprise fileHEH Catégorie technique Etude de...
Transcript of Bachelier en informatique et systèmes Stage en entreprise fileHEH Catégorie technique Etude de...
Maître de stage : Monsieur Delor Xavier
Bachelier en informatique et systèmes
Stage en entreprise Bloc 3
Année 2017-2018
DELCAMPE Thomas
Etude de mise en œuvre d'un outil de monitoring
Bibliothèque royale de
Belgique Boulevard de l'Empereur 4
1000 Bruxelles
Maître de stage : Monsieur Delor Xavier
Bachelier en informatique et systèmes
Stage en entreprise Bloc 3
Année 2017-2018
DELCAMPE Thomas
Etude de mise en œuvre d'un outil de monitoring
Bibliothèque royale de
Belgique Boulevard de l'Empereur 4
1000 Bruxelles
Remerciements
À l’issue de ce stage, je tiens à adresser mes
remerciements à Xavier Delor, mon maître de stage, à
tout le personnel du service ICT pour leur bienveillance,
ainsi qu’à Jonathan Galand et Yves De Preter, mes
collègues de bureau, pour le temps qu’ils ont consacré,
tout au long de cette période de stage à mon
apprentissage et les réponses à mes questions.
Bruxelles, le 7 mai 2018
Thomas Delcampe
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
5 Rapport
Table des matières Résumé .................................................................................................................................................... 7
Abstract ................................................................................................................................................... 8
Introduction ............................................................................................................................................. 9
Présentation de l’entreprise .................................................................................................................. 10
Service ICT ..................................................................................................................................... 11
Localisation ........................................................................................................................................ 12
Organigramme simplifié .................................................................................................................... 13
Maître de stage ................................................................................................................................. 14
Objectifs du stage .............................................................................................................................. 14
Réalisation du stage .............................................................................................................................. 15
Plateforme de test ............................................................................................................................. 15
Analyse des besoins ........................................................................................................................... 15
Inventaire du réseau ..................................................................................................................... 15
Inventaire du monitoring .............................................................................................................. 16
Étude de marché ............................................................................................................................... 16
Salon Infosecurity .......................................................................................................................... 17
Analyse des solutions de monitoring ................................................................................................ 17
Nagios XI ........................................................................................................................................ 18
Zabbix ............................................................................................................................................ 30
PRTG .............................................................................................................................................. 31
NetCrunch...................................................................................................................................... 44
Comparatif des solutions de monitoring testées .......................................................................... 49
Implémentation de la solution de monitoring .................................................................................. 50
Cahier des charges ......................................................................................................................... 50
Best practices ................................................................................................................................ 51
Choix de la solution de monitoring ............................................................................................... 52
Déploiement de PRTG ................................................................................................................... 52
Problèmes rencontrés ................................................................................................................... 53
Sondes ........................................................................................................................................... 55
Alertes ........................................................................................................................................... 56
Supervision des serveurs Linux...................................................................................................... 56
Documents annexes ...................................................................................................................... 57
Relationnel ............................................................................................................................................ 58
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
6 Rapport
Compétences acquises ...................................................................................................................... 58
Relation avec les employés ............................................................................................................... 58
Suivi du travail ................................................................................................................................... 59
Planification du travail ................................................................................................................... 59
Conclusion ............................................................................................................................................. 60
Lexique .................................................................................................................................................. 61
Bibliographie.......................................................................................................................................... 62
Cours .................................................................................................................................................. 62
Livres .................................................................................................................................................. 62
Documents électroniques ................................................................................................................. 62
Annexes ................................................................................................................................................. 63
Liste des annexes ............................................................................................................................... 63
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
7 Rapport
Résumé Au cours de mon stage à la Bibliothèque royale de Belgique, j’ai été chargé d’analyser les besoins de
leur réseau informatique en termes de supervision puis de réaliser un cahier des charges de leurs
besoins, afin de réaliser une étude de marché des solutions de monitoring éventuellement adaptées,
puis de tester celles-ci.
À la suite des tests, l’équipe s’est prononcée en faveur de l’outil « PRTG » dont j’ai dû réaliser
l’installation et l’implémentation complète dans le réseau, incluant la configuration et sécurisation du
protocole SNMP sur les périphériques supervisés.
Ce document présente aussi la Bibliothèque royale de Belgique, leur service informatique, mon maître
de stage et l’aspect relationnel du stage.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
8 Rapport
Abstract During my internship at the Royal Library of Belgium, I was asked to analyse the needs of their
computer network in terms of supervision, then to draw up specifications of their needs, in order to
carry out a market study of monitoring solutions that might be adapted, then to test them.
Following the tests, the team came out in favour of the "PRTG" tool, which I had to install and fully
implement in the network, including configuring and securing the SNMP protocol on the supervised
devices.
This document also presents the Royal Library of Belgium, their IT department, my training supervisor
and the relational aspect of the internship.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
9 Rapport
Introduction Dans le cadre de ma dernière année de « bachelier en informatique et systèmes orientation réseaux
et télécommunications option sécurité », j’ai été retenu comme stagiaire dans le service informatique
de la Bibliothèque royale de Belgique pour une période de treize semaines.
Mon rôle dans ce service a été de réaliser une étude de mise en place d’un outil de monitoring, de
tester diverses solutions et de donner mes recommandations quant à celle qui sera la plus adaptée au
cahier des charges établi au long du stage, et aux attentes du personnel.
Suivant les délais de réalisation de cette partie, il me sera aussi demandé de réaliser la mise en
production de la solution choisie, demandant donc des réflexions en termes de seuils des alertes de
monitoring, mais aussi de la meilleure façon de superviser des périphériques de manière sécurisée.
Ce rapport de stage décrira mon parcours dans ce service, en commençant par la présentation de la
Bibliothèque royale de Belgique, sa localisation, et son service informatique.
Le corps du document s’attellera ensuite à relater l’ensemble des travaux réalisés pendant le stage, de
l’analyse et l’inventorisation du réseau de la Bibliothèque et de ses besoins en termes de monitoring
jusqu’à l’implémentation de la solution de supervision choisie au terme de mes multiples analyses.
Viendra ensuite une description de ce que ce stage m’a apporté au niveau relationnel et humain au
travers des échanges avec mon maître de stage et les employés du service ICT de la Bibliothèque royale
de Belgique, et enfin une conclusion générale qui clôtura ce document.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
10 Rapport
Présentation de l’entreprise La Bibliothèque royale de Belgique est la bibliothèque scientifique nationale de l’État fédéral belge,
elle est donc la mémoire littéraire et scientifique du pays et contient, entre autres :
Toutes les publications imprimées en Belgique
Toutes les publications publiées par des auteurs belges
Livres historiques et précieux
Manuscrits
Journaux
Estampes
Monnaies
Médailles
Partitions
Musique
...
La Bibliothèque héberge aussi diverses activités :
Centres de recherche
o Center for American Studies
o Archives et Musée de la Littérature
Expositions permanentes
o Librarium
o Palais de Charles de Lorraine
Expositions temporaires
Salles de conférence
Concerts
…
À l’opposite des bibliothèques classiques, la Bibliothèque royale de Belgique est une bibliothèque de
consultation. Les divers ouvrages présents dans la Bibliothèque ne sortent donc pas de l’enceinte du
bâtiment, mais doivent être consultés dans diverses salles de lectures dédiées au type d’élément
choisi.
En sus de tout cela, la Bibliothèque prend un tournant numérique et offre (ou offrira) ainsi :
Son catalogue en ligne : OPAC (Online Public Access Catalog)
o Lecture de ses éléments : Belgica
o Lecture de journaux : BelgicaPress
o Dépôt légal via Internet : E-Dépôt
Un service de digitalisation de tous les éléments de la Bibliothèque : DIGIT
Archivage du web
…
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
11 Rapport
Service ICT Le service informatique de la Bibliothèque royale de Belgique comprend une dizaine d’employés,
chacun avec un rôle officiel ou officieux distinct. Celui-ci est chargé de tenir en état de fonctionnement
optimal le réseau, de le maintenir à jour (hardware, software, sécurité) et d’offrir des ressources aux
lecteurs (connecté en LAN autant qu’en WAN) et autres services de la Bibliothèque royale de Belgique.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
12 Rapport
Il n’existe pas de Disaster Recovery Plan, car la mission de la KBR n’est pas de fournir un service ICT, ils
pourraient donc se permettre d’avoir plusieurs jours sans réseau sans que ça n’en impacte la mission
de la KBR.
Par contre, ils disposent de back up complet de toutes les données de la Bibliothèque (livres, estampes,
serveurs, …) qu’ils ne peuvent pas perdre.
Une partie du service ICT a une dizaine d’années de retard technologique en termes d’applications et
de serveurs (ils sont actuellement, par exemple, en train de migrer progressivement Exchange 2007
vers 2016) et la moitié de leurs switches datent d’environ 2004 surtout au niveau catalogue où le
système ressemble aux années 80, les menus sont sans souris, … Ils essayaient toutefois, dans les
limites de temps de travail et budgétaires, de renouveler tout le matériel et les logiciels tous les 5 ans.
Il n’y a pas de standardisation entre les différents services de la KBR, ni de charte interne, ce qui fait
que la plupart des services travaillent différemment de leur côté. Il est donc difficile pour les
administrateurs système de faire efficacement leur travail, ne pouvant, par exemple, pas garantir une
gigue et une sécurité optimale du réseau en réprimandant un utilisateur sur son utilisation d’Internet.
Localisation Entrée pour le public
Mont des Arts, 1000 Bruxelles
Adresse postale
Boulevard de l’Empereur 4, 1000 Bruxelles
+32 (0)2 519 53 11
Figure 1 : Plan d'accès à la Bibliothèque royale de Belgique
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
13 Rapport
Organigramme simplifié
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
14 Rapport
Maître de stage Xavier Delor est originaire de Lignes (Ath) et a fait un master en informatique à l’UMons (appelée UMH
à l’époque). Il a été embauché à la Bibliothèque royale de Belgique peu de temps après ses études, en
mars 2004, en tant que gestionnaire système.
Quelques années plus tard, il est devenu manager de tout le service informatique et a effectué en
2014, une formation de 240 heures sur le management, puis une autre de 13 jours en 2017.
Son rôle de manager, en plus de la gestion des besoins du personnel, comprend trois rôles distincts :
Budget informatique
Son premier rôle est d’évaluer les dépenses en fonctionnement et en investissement du service.
Il est aussi chargé d’évaluer la tendance des dépenses (par exemple, de plus en plus de programmes
passent par une stratégie commerciale de location au lieu de l’achat, la location d’abonnement
supplante donc progressivement l’achat de logiciel).
Coordinateur
Il faut près d’une année pour recruter quelqu’un à l’état, il est donc chargé d’évaluer les besoins en
personnel à long terme.
Il est aussi chargé de chercher des salons (Infosecurity, …), des présentations de produits (Viavi,
NetCrunch, Skype for Business, …) voire des formations (maintenance d’un client Windows, …)
adaptées aux besoins du service ou du personnel.
Gestion des projets
Il est aussi chargé de définir, accepter et coordonner les projets de la Bibliothèque royale de Belgique.
De nouveaux projets, établis en concertation avec le reste du service ICT en fonction des
avancées technologiques ou des besoins en fonction de projets des autres services de la
Bibliothèque.
Transposer les plans stratégiques (venant des projets qui viennent de l’état, de la direction ou
des autres services de la KBR) en plan opérationnel (exploitable par le personnel ICT).
Objectifs du stage Les objectifs du stage, tels qu’établi par le cahier des charges initial 1 sont de réaliser :
Une analyse des besoins en termes de supervision du réseau et parc informatique de la
Bibliothèque royale de Belgique
Une étude de marché des solutions de supervision
L’installation, test et configuration de différents produits de supervision afin de proposer la
(ou les) solution la (les) mieux adaptée(s) pour l’entreprise
L’implémentation de la solution choisie
1 Voir annexe 3 : Cahier des charges
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
15 Rapport
Réalisation du stage
Plateforme de test Un laptop et divers accessoires, ainsi qu’un accès VPN m’ont été confiés pour la durée de mon stage
afin de réaliser celui-ci. Les premiers tests ont été effectués en machine virtuelle sur ce portable, mais
ses performances se sont montrées, dès les premiers tests, trop limitées pour de la virtualisation.
Pour pallier à ce problème, un serveur2 a été mis à mon entière disposition. Après l’avoir installé dans
un rack libre, j’ai pu le configurer entièrement suivant mes besoins : RAID, système d’exploitation,
interfaces réseau, Hyper-V, …
Analyse des besoins
Inventaire du réseau La majorité de l’infrastructure de la Bibliothèque royale de Belgique ayant une documentation
incomplète, voire inexistante ou mal archivée, mon stage a débuté par l’analyse de chaque élément
des armoires réseau de la salle serveur, ainsi que de ceux éparpillés dans le bâtiment. J’ai ainsi repris
un fichier partiellement édité afin d’y répertorier, dans la mesure du possible, tous les éléments
constituant chaque rack, leurs types, marques, numéros de modèle, de série, d’inventaire, …
Cette tâche a été longue et n’a évidemment pas été la plus palpitante de mon stage, mais elle a eu le
mérite de me faire prendre conscience de l’importance vitale d’avoir un réseau entièrement
documenté et correctement archivé. En plus des divers points vus et utilisés en cours, j’ai pu constater
plusieurs avantages flagrants de faire sa documentation, grâce à cette expérience.
Connaissance de l’infrastructure : Une documentation complète et bien archivée permettra à qui de
droit (nouveaux employés, stagiaires, acteurs externes, …) de bénéficier d’une vue globale des
éléments constitutifs du réseau, de leur rôle et implémentation.
Gain de temps :
Pour les employés, dont toutes les informations nécessaires à la réalisation de leur travail sont
facilement et rapidement disponibles, au lieu de devoir chercher manuellement ces
informations à chaque fois.
Pour les nouveaux employés, stagiaires, acteurs externes, … qui ne devront pas devoir passer
des jours à la réaliser par eux-mêmes pour avoir les informations requises à leur travail.
Menaces de sécurité : La documentation étant indisponible, des protocoles non sécurisés de couche
2 et 7, reconnus comme des « menaces de sécurité majeures à absolument désactiver ou à en
restreindre l’utilisation aux interfaces où ils sont indispensables » sont activés sur le réseau et
régulièrement utilisés afin d’y retrouver manuellement des éléments le constituant.
Disaster Recovery Plan : Pas de reconstruction d’infrastructure réseau envisageable sans
documentation, tout serait à recommencer « from scratch », engrangeant des pertes de temps et
d’argent importantes.
2 Voir annexe 4 : Documentation technique – Plateforme de test
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
16 Rapport
Inventaire du monitoring Après l’inventaire du réseau et grâce aux premiers Auto Discovery de Nagios, j’ai commencé à réaliser
un inventaire du monitoring, répertoriant chaque périphérique, ses nodes et ses probes qui sont ou
seront monitorées. Une analyse des éléments à monitorer en fonction de chaque type de périphérique
et de serveur a ainsi été réalisée.
Cet inventaire devait être initialement réalisé une fois puis utilisé globalement, indépendamment de
la solution de monitoring, mais au fur et à mesure des analyses de ces dernières, ceci s’est montré
irréalisable pour diverses raisons.
Connaissances personnelles : Les probes étant des éléments spécifiques (matériel, protocoles,
services, applications, …) à monitorer sur chaque périphérique, ceux-ci étaient régulièrement modifiés
(ajoutés ou supprimés du monitoring) en fonction des connaissances acquises et observations lors de
mon stage.
Solutions de monitoring : Les possibilités de monitoring de chaque solution étant totalement
différentes, tant en nom des probes qu’en nombre de possibilités, il est vite apparu évident qu’avoir
un inventaire de monitoring général, applicable à chaque solution testée était impossible.
Par exemple, pour Nagios XI, une probe (services) ne comprend qu’un seul élément (Capacité d’un
disque dur, …) tandis qu’une probe (senseur) pour PRTG, suivant le cas, en contiendra plusieurs
(Capacité d’un disque dur + vitesse d’écriture + temps de lecture, …)
Pour pallier à ces problèmes, j’ai dû réaliser au final plusieurs inventaires de monitoring :
Celui effectué lors des tests sur Nagios qui était imaginé pour être global et universel
Un inventaire différent par solution de monitoring analysée, qui reprend la base de celui de
Nagios, mais où sont uniquement modifiés les probes sur les périphériques testés
Un inventaire final3 sur la solution de monitoring choisie et implémentée sur le réseau
Ce même problème rend très difficile l’estimation théorique des besoins en termes de probes pour les
solutions de monitoring ayant un modèle économique par capteurs.
Étude de marché Afin de rechercher des solutions de monitoring adaptées à notre cahier des charges, j’ai principalement
utilisé divers réseaux sociaux comme moteur de recherche pour trouver des noms en fonction du
retour utilisateur et de leur popularité au sein de la communauté, et non seulement en fonction du
référencement des moteurs de recherche « mainstream », de plus en plus influencés par le
référencement payant.
En utilisant les réseaux sociaux, et en particulier Twitter comme moteur de recherche, j’ai aussi eu un
aperçu plus direct du support technique et des délais de réponse, que ce soit par la communauté ou
par les marques éditrices de ces solutions.
Après avoir découvert plusieurs noms de solutions de monitoring pouvant éventuellement subvenir à
nos besoins, Google a évidemment été utilisé afin de trouver plus facilement de la documentation
technique et commerciale.
3 Voir annexe 9 : Inventaire du monitoring final
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
17 Rapport
Le Magic Quadrant « Network Performance Monitoring and Diagnostics » publié le 21 février 2018 a
lui aussi été utilisé afin de sélectionner des solutions de monitoring.
Salon Infosecurity J’ai aussi pu me rendre au salon « Infosecurity.be, Data & Cloud Expo 2018 » se déroulant à Brussels
Expo les 14 et 15 mars. Outre l’enrichissement personnel et professionnel sur les thèmes abordés par
le salon et les différents exposants, j’ai pu y réaliser diverses choses pour mon projet de stage.
Découvrir d’autres solutions de monitoring, moins connues du grand public
Rassembler des informations techniques sur ces solutions et le monitoring en général, ainsi
que demander des démonstrations en live
Établir des contacts professionnels
Demander des offres de prix et négocier des réductions
Analyse des solutions de monitoring Pour pouvoir tester les différentes solutions de monitoring retenues de la manière la plus objective et
uniforme possible, une procédure de test visant à vérifier plusieurs points identiques sur chacune des
solutions a été établie après les premières analyses. Cette procédure a été régulièrement enrichie au
fur et à mesure des tests en fonction des atouts ou carences majeures détectées lors des analyses.
Cette procédure se veut variée et couvre l’Auto Discovery, de multiples aspects de l’interface, ainsi
que le monitoring de deux serveurs Windows type (un contrôleur de domaine et un serveur de
virtualisation), d’un serveur Linux type (web), des firewalls, du VPN, de chaque switches et de xFlow.
Afin de ne vérifier que le produit en question et pas les ajouts indépendants des développeurs, cette
procédure ne teste que les options natives, mais mentionne les plug-ins et la réactivité de la
communauté.
Shinken Icinga 2 Zabbix Nagios XI PRTG NetCrunch Viavi Observer Platfom Netwrix Datadog
Interface
Monitoring réseau V V V V V V V X X
Auto Discovery du réseau X X X V V V ? ? ?
2 terminaux de monitoring V V V V V V ? ? ?
Interface web V V V V V V ? ? ?
Interface de gestion simple et intuitive X X V V V V ? ? ?
Budget maximum ? ? ? V V V X ? ?
Utilisateur viewer (read-only) ? ? ? V V V ? ? ?
Prédictibilité de pannes ? ? ? X V ? ? ? ?
Analyse des comportements inhabituels ? ? ? X V ? ? ? ?
Gestion des alertes (corrélation, escalation,…) ? ? ? X V V ? ? ?
Serveur de centralisation des logs ? ? ? X X ? ? ? ?
Analyseur de flux réseau ? ? ? X V V ? ? ?
Système de ticket interne ? ? ? X V ? ? ? ?
Elements
Windows Server 2012 et 2016 ? ? ? N N N ? ? ?
Ubuntu 12.04 et 16.04 ? ? ? N N/P N ? ? ?
Hyperviseur Hyper-V ? ? ? X N N ? ? ?
Serveurs web (MySQL, Apache, PHP, requêtes HTTP) ? ? ? N N N ? ? ?
Contrôleur de domaine (Active Directory, DHCP, DNS) ? ? ? N N N ? ? ?
Switches HP Procurve ? ? ? x N N ? ? ?
Microsoft Exchange (Backup, envoi de mail) ? ? ? N N N ? ? ?
Firewall Palo Alto ? ? ? P x I ? ? ?
VPN Cisco ASA ? ? ? P N ? ? ? ?
Dell EMC Isilon ? ? ? P N/H x ? ? ?
Imprimantes Ricoh ? ? ? P N ? ? ? ?
Access point Aerohive ? ? ? I I I ? ? ?
Sondes environnementales ? ? ? I I ? ? ? ?
Bancontact ? ? ? ? ? ? ? ? ?
Caisses ? ? ? I I ? ? ? ?
Caméras ? ? ? I I ? ? ? ?
UPS APC ? ? ? P N ? ? ? ?
Pointeuses ? ? ? ? ? ? ? ? ?
Badge ? ? ? ? ? ? ? ? ?
Players ? ? ? I I I ? ? ?
Mcafee ? ? ? P N N ? ? ?
Symantec Backup Exec ? ? ? P ? N ? ? ?
Veeam One ? ? ? X X X ? ? ?
V = OK X = NOK N = NATIF P = PLUGIN I = ICMP H = Hardware ? = Information non trouvée ou test non réalisé
Mu
st-H
ave
Nic
e-to
-hav
eM
ust
-Hav
eN
ice-
to-h
ave
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
18 Rapport
Nagios XI Nagios XI est plébiscitée par ses utilisateurs comme l’une des solutions de supervision les plus
puissantes du marché. Nagios XI est en réalité une interface de gestion supplantée sur son
prédécesseur, Nagios Core, qui demandait une configuration via scripting.
Nagios Core, qui reste la base de la solution est basé sur Linux, open source, et a une communauté
parmi les plus importantes.
Out of the box, Nagios ne peut pas superviser beaucoup d’éléments … Mais la communauté fait ici part
intégrante du logiciel et de son marketing. A la question « Est-ce que Nagios peut monitorer cet
élément ? », les développeurs répondent « Oui, si plug-in ». De même, avec une communauté si
énorme, l’assistance via un forum gratuit ou d’autres sites se trouve facilement.
Les plug-ins faisant part intégrante de Nagios, ces derniers seront inclus aux tests, en plus des options
natives.
Figure 2 : Nagios - alertes
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
19 Rapport
Procédure de test
Tâches Etat Notes
Serveurs OK
Switches OK
AP OK
Management OK
Imprimantes black OK
Imprimantes color OK
SLZ OK
Caméras OK
Prikklok OK
Hanwell OK
Signage OK
VLAN 15 NOK Problème réseau, non lié au monitoring
OSX, OSA OK
VLAN 25 NOK Problème réseau, non lié au monitoring
DMZ OK
Modification d'une node ajoutée par l'AutoDiscovery NOK
Recherche complexe ToDo
Facilité de l'interface (IP/FQDN,…) OK
Suppression d'une node : PC client OK Services puis Host
Gestion des alertes : Imprimantes temporairement éteintes OK Downtime + acknowledgment persistent
Gestion des alertes : acknowledgment, mass/bulk acknowledgmentOK
Gestion des plugins OK
Ajout manuel d'une node : switch via wizard / template OK
Ajout de probes sur une node : Ports uplink sur un switch OK
Suppression de probes sur une node : Ports sur un switch OK Impossible de voir l'état d'un probe en même temps que de le gérer
Probes : Informations système d'un switch NOK Via plugin, non testé
Ajout manuel d'une node : imprimante via wizard / template OK
Monitoring d'un toner : Toner cyan OK Ok via plugin Nagios Exchange
Ajout manuel d'une node : VPN via wizard / template OK
Probe : Interface DMZ OK SNMP
Probe : Interface Management SNMP SNMP
Probe : Mémoire OK Ok via plugin Nagios Exchange
Probe : CPU NOK
Probe : température NOK
Probe : Sessions NOK Seulement sessions TCP+UDP
Ajout manuel d'une node : Interface management 1 OK
Ajout manuel d'une node : Interface management 2 OK
Probe : Charge CPU OK Ok via plugin Nagios Exchange
Probe : Mémoire NOK
Probe : Espace disque NOK
Probe : Température OK Ok via plugin Nagios Exchange
Probe : Ventilateur OK Ok via plugin Nagios Exchange
Probe : Etat du failover OK Ok via plugin Nagios Exchange
Ajout manuel d'une node : Serveur Linux OK
Probes SNMP : Infos système et serveur web OK Processes, Infos systèmes
Probes via agent : Infos systèmes et serveur web OK Processes, services, infos systèmes
Probes SSH : Infos systèmes et serveur web NOK Pas d'auto détection
Services Linux OK
Processus Linux OK
Probes HTTP OK
Ajout manuel d'une node : Windows Server 2012 R2 OK
Probes SNMP : Infos système et Hyper-V OK Processes, Infos systèmes
Probes WMI : Infos système et Hyper-V OK Services, processes, Infos systèmes et alertes via logs Windows
Probes SSH : Infos systèmes et serveur web NOK Pas d'auto détection
Services Windows OK
Processus Windows OK
Probes : Status des cartes RAID HP NOK Plugin Nagios Exchange disponible mais non fonctionnel
Probes : Hyper-V NOK Pas de capteur natif ni via Nagios Exchange
Ajout manuel d'une node : Windows Server 2012 R2 OK
Probes WMI : Infos système et rôles OK Services, processes, Infos systèmes et alertes via logs Windows
Services Windows OK
Processus Windows OK
Probes : Status des cartes RAID HP NOK Plugin Nagios Exchange disponible mais non fonctionnel
Probes : Active Directory OK LDAP
Probes : DHCP OK
Probes : DNS OK
Firewall Palo Alto PA-500 NOK
Switch Core NOK
Switch stack serveur NOK
Network Auto Discovery
Interface
Imprimante [prn-10-36]
VPN Cisco ASA [vpn-srv01]
Firewall Palo Alto PA-500
Switches
xFlow
Disponible uniquement sur Nagios Network Analyser
Serveur DC Windows [dc-srv01]
Serveur web Ubuntu [intweb-srv01]
Serveur Hyper-V Windows [mon-srv01]
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
20 Rapport
Compte-rendu des tests
Network Auto Discovery
La fonction d’Auto Discovery de Nagios est disponible dans un menu à part entière, où est affichée une
liste de toutes les tâches Auto Discovery et diverses informations : sous-réseau scanné (la recherche
se faisant uniquement sur IP/masque), date du dernier scan, prochaine exécution, hôtes découverts
et nouveaux hôtes découverts depuis le dernier scan. Nous pouvons, via ce menu, afficher tous les
hôtes découverts pour une tâche et les probes choisies par Nagios en fonction du type détecté,
relancer la tâche ou la supprimer. En ouvrant une tâche, il est possible de n’afficher que les nouveaux
hôtes détectés ou tous, puis de de sélectionner les nodes et/ou probes à ajouter au monitoring.
Figure 3 Nagios - Auto-Discovery
En termes de découverte, l’Auto Discovery fonctionne bien et découvre tous les hôtes disponibles sur
les sous-réseaux choisis et les enregistre par IP, mais aussi par leur nom FQDN, s’il l’a découvert.
En revanche, la détection du type de node et de probes est automatique et non configurable et est la
plupart du temps erronée. De nombreuses probes inexistantes seront alors rajoutées au monitoring
par Nagios, ce qui engendra beaucoup d’alertes, et de travail de suppression de ces dernières dès que
la faute sera confirmée. Les types de node sont aussi très souvent erroné, il est donc, par exemple,
impossible d’utiliser l’Auto Discovery pour les switches du réseau, car ceux-ci sont reconnus comme
des systèmes Linux, ils ne sont donc pas monitorés comme des switches mais comme des serveurs, les
ports ne sont donc pas détectés.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
21 Rapport
Figure 4 Nagios - Auto-Discovery d'un switch
Interface
Toujours avec l’exemple des switches, il est impossible de modifier un type de node autodétecté : un
switch détecté en tant que serveur l’est et le restera, nous serons donc obligés de tous les supprimer,
et de les rajouter manuellement un par un via le wizard adapté.
Figure 5 Nagios - wizards de création
Nagios ajoute les nodes via leur IP ainsi que leur nom via FQDN s’il l’a détecté. De ce fait, les recherches
sont aisées, car il sera possible de trouver un node ajouté par FQDN via son adresse IP uniquement par
exemple. Dans son ensemble, la fonction de recherche est très performante et permettra de réaliser
des recherches complexes et multiples (recherche de tous les hôtes d’une plage IP, hôtes ou services
via un mot,…).
Figure 6 Nagios - Hôte
L’interface de Nagios en elle-même est cependant très lourde à utiliser, car elle est décomposée en
deux parties. Une partie « monitoring » où il sera possible de voir les états, graphiques et alertes des
hôtes et des services, mais où il sera impossible de configurer quoi que ce soit, et une autre, basée sur
le mode Core des anciennes versions (ici, Core Configuration Manager) où il ne sera possible que de
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
22 Rapport
faire l’inverse, à savoir uniquement modifier hôtes/services, mais pas voir leur état en même temps.
De même, les hôtes/services sont décomposés, dans chaque « mode » en deux menus distincts, il n’est
donc pas possible de voir l’état des services d’un hôte dans le menu « hôtes », ce qui alourdit encore
plus l’interface utilisateur.
Figure 7 : Nagios - CCM hosts
L’Auto Discovery ne permettant que de définir un sous-réseau à analyser, de nombreux hôtes non
voulus pourraient être ajoutés au monitoring. Pour supprimer ces derniers, la procédure est encore
une fois très lourde. Après avoir constaté le problème en mode monitoring, il faudra basculer en CCM,
rechercher les hôtes en question, supprimer tous leurs services via le menu adéquat, puis finalement
aller dans le menu « hôtes » pour le supprimer, puis appliquer le changement.
Autre cas concret : les imprimantes qui sont monitorées, mais dont certaines sont temporairement
éteintes par les usagers. Celles-ci engendrent un grand nombre d’alertes, à la fois pour l’hôte et les
services down, il est donc nécessaire de les désactiver. Ceci est possible assez facilement via un menu
dédié dans lequel nous pourrons sélectionner plusieurs hôtes et les définir en « downtime » pour une
durée définie. Ces dernières seront toujours trouvables dans les hôtes et services down, mais ne
génèreront pas d’alertes.
Figure 8 : Nagios - Imprimantes en downtime programmé
La seconde méthode est de les gérer comme toutes les autres alertes qui sont des faux positifs ou ne
sont pas résolues par le staff IT : en les notant comme « acknowledged ». Ce mode de gestion est le
même sur toutes les solutions de monitoring et permet de ne plus être alerté durant une certaine
plage de temps pour une ou plusieurs alertes, d’un hôte ou d’un service au lieu de les supprimer
totalement du monitoring.
Nagios dispose d’une gestion des downtime et acknlowedgment assez complètes, il sera donc possible
de choisir plusieurs options (basé sur un délai de temps, jusqu’au prochain statut up ou persistent)
pour les acknowledgment, d’hériter le downtime aux enfants, …
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
23 Rapport
Figure 9: Nagios - Mass acknowledgments and dowtime scheduling
Que ce soit pour la gestion des alertes, des downtime ou du monitoring, Nagios contient divers menus
permettant la gestion en masse de manière assez aisée à l’aide de checkbox.
Plugins
Le principal atout de Nagios est sa très grande communauté et ses nombreux plug-ins disponibles sur
Nagios Exchange, mais même si ces derniers sont en effet très nombreux, tous ne sont pas
fonctionnels : Nagios étant assez vieux sur le marché, les plug-ins le sont aussi, il y en a donc de
nombreux qui sont toujours disponibles, mais non mis à jour et donc plus fonctionnels.
Leur implémentation est elle aussi très lourde, car comprend plusieurs étapes :
Upload via le menu « Monitoring Plugins » du CCM
Vu que le fonctionnement d’un plug-in n’est pas garanti, la seconde étape est d’accéder au
serveur Nagios en mode console et d’y effectuer les premiers tests en live.
Figure 10 Nagios - Test d'un plugin en CLI sur le serveur
Enfin, si les tests sont concluants, nous pouvons reprendre la commande précédemment
testée et l’ajouter à Nagios via le menu « Commands » du CCM. Ce menu permet d’ajouter
une commande à la fois et d’y définir plusieurs variables.
Figure 11 Nagios - Commande
Enfin, nous pouvons intégrer le plug-in en cherchant un hôte via l’onglet « services » du CCM,
clonant la probe du ping, pour finalement la modifier en lui donnant un nom adéquat, y
intégrant la commande ainsi que divers arguments dans les variables précédemment définies.
Pour vérifier le fonctionnement du plug-in intégré sur Nagios, il faut maintenant quitter le
mode CCM pour retourner en monitoring, chercher la probe nouvellement créée, et forcer son
actualisation afin de vérifier son fonctionnement.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
24 Rapport
Figure 12 Nagios - Plugin implémenté
Switches
L’ajout d’hôtes individuels se fait à l’aide d’une sélection de nombreux wizard en fonction du type de
périphérique. Les switches et routeurs s’ajoutent à l’aide du wizard « Network Switch / Routeur ».
Ce wizard est peu performant et ne permettra que de monitorer le ping du switch, l’état et la bande
passante de chaque port. Il détecte toutefois tous les ports du switch, leurs vlan ainsi que les trunks
HP, quel que soit leur état. En laissant tout par défaut et donc en ajoutant tout au monitoring, de
nombreuses alertes seraient donc générées par les ports non branchés.
Les ports peuvent être affichés par numéro, nom ou description. Il ne détecte cependant pas le type
de switch, ni son hostname, ni l’état système sans plug-in dédié.
La modification future du monitoring des ports du switch se fera comme précédemment vue :
Pour supprimer un port down car non branché, il faudra tout d’abord afficher les services de
ce switch dans le monitoring et confirmer le statut, puis ensuite aller chercher ces ports dans
le CCM et les supprimer manuellement.
L’ajout de nouveaux ports à monitorer en revanche se fait en relançant ce wizard.
Figure 13 Nagios - Wizard switch/router
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
25 Rapport
Imprimante
Nagios dispose bien d’un wizard dédié aux imprimantes, mais celui-ci est limité aux imprimantes HP, il
existe donc plusieurs façons d’ajouter la nôtre :
Wizard « Generic Network Device » qui découvrira son FQDN et ne monitorera que le ping
Wizard « SNMP » qui découvrira son FQDN mais aucun service à monitorer automatiquement
Auto Discovery, qui découvrira les protocoles standard d’un périphérique réseau (http/s,
NetBIOS, Ping, Telnet/SSH/RDP) ainsi qu’Internet Printing Protocol.
Un plug-in pour les imprimantes Ricoh est disponible et permet de tester plusieurs données hardware
tels que
Compteur de page imprimée
Toner avec des alertes en fonction du % restant, par toner (fonction testée)
Manque de papier
Hardware (CPU,RAM,…)
Figure 14 Nagios - Proof of concept : Imprimante
VPN Cisco ASA
Nagios n’ayant pas de wizard dédié à ce VPN, il faudra encore une fois tester d’autres wizard plus
génériques afin de répondre à nos attentes.
Dans ce cas, le VPN a été ajouté à l’aide de l’Auto Discovery qui ne détectait que le ping et SSH, puis à
l’aide du wizard dédié aux switches et routeurs, par son IP de gestion, afin d’avoir la surveillance de
ses ports.
Tous les plug-ins disponibles pour cet équipement ont ensuite été testés, et il n’a été possible que de
récolter les informations suivantes :
RAM
Sessions TCP+UDP
Figure 15 Nagios - Proof of concept : VPN Cisco ASA
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
26 Rapport
Firewall Palo Alto PA-500
L’interface de gestion de chaque firewall a été ajoutée par l’Auto Discovery, qui n’a découvert que le
ping, SSH et HTTPS, puis encore une fois à l’aide du wizard dédié aux switches et routeurs afin de
monitorer toutes les interfaces disponibles à cet instant sur chaque pare-feu.
Un plug-in très complet a ensuite été implémenté afin de surveiller ces paramètres :
Charge CPU
Sessions utilisées
État du cluster HA (failover)
Température
État des ventilateurs
Disponibilité
Figure 16 Nagios - Proof of concept : Firewall Palo Alto
Serveur web Ubuntu [intweb-srv01]
L’ajout d’un serveur peut se faire via divers wizard adaptés, qui listent eux-mêmes tout ce qu’il y a à
monitorer sur un hôte avec le protocole choisi, mais il sera aussi possible d’entrer nous-mêmes des
noms, de services ou des commandes. Il est possible de monitorer un serveur Linux à l’aide de trois
wizard, donc trois protocoles : « Linux Server » qui utilise l’agent NRPE propre à Nagios, « Linux SNMP »
et « SSH Proxy ».
Linux Server
Informations système
o Ping
o APT Update Status
o Load et statistiques CPU
o Mémoire RAM et SWAP
o Nombre de fichiers ouverts
o Nombre d’utilisateurs loggés
o Nombre de processus en cours
o Utilisation des disques (uniquement /)
Services
o SSH
o Cron
o Rsyslog
o Apache2
o Mysql
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
27 Rapport
o Sendmail
o Dovecot
Processus
o Sendmail
Linux SNMP
Les mêmes informations systèmes que NRPE, mais il identifie toutes les LVM
Pas de monitoring des services
Une liste complète de tous les processus en cours sur le serveur
SSH Proxy
Ping
Pas de détection, Nagios permet demande d’entrer des requêtes SSH
Outre les services et processus liés au fonctionnement d’un serveur web qu’il est nécessaire de
monitorer (Apache, MySQL, PHP, …), Nagios dispose de plusieurs wizard permettant de tester le
fonctionnement direct du serveur en effectuant des requêtes spécifiques.
http
http transaction
Website
Website Defacement
MySQL Server
MySQL Request
Figure 17 Nagios - Proof of concept - serveur web Linux
Serveur Hyper-V Windows [mon-srv01]
L’ajout d’un Windows Server se fait aussi à l’aide de wizard dédié, au nombre de quatre cette fois :
« Windows Server » qui utilise un agent propre à Nagios, « Windows SNMP », « Windows WMI » et
« SSH Proxy ».
Windows Server
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
28 Rapport
N’a pas été testé car WMI dispose de toutes les informations monitorables et est intégré à
chaque Windows, il est donc inutile d’utiliser un agent.
Windows SNMP
Informations système
o Ping
o CPU
o Mémoire physique et virtuelle
o Utilisation des disques
Services
o 33 détectés
Processus
o 38 détectés
Windows WMI
Informations système
o Ping
o CPU
o Mémoire
o Page File
o Utilisation des disques
Services
o 147 détectés
Processus
o 63 détectés
Event logs
o Alerte en cas de nouvelles entrées dans le journal des évènements
Ce serveur étant un serveur Hyper-V, les services et processus liés à ce dernier et aux machines
virtuelles ont été ajoutés au monitoring. Il n’existe cependant pas d’options natives ni de plug-ins
dédiés à un monitoring approfondis d’Hyper-V.
Le monitoring du hardware de ce serveur a aussi été envisagé, mais Nagios ne dispose pas non plus
d’options natives, et les plug-ins de Nagios Exchange utilisent les software HP installés sur l’hôte, mais
étaient non fonctionnels.
Figure 18 Nagios - Proof of concept : Serveur Windows Hyper-V
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
29 Rapport
Serveur contrôleur de domaine, DNS, DHCP, Active Directory [dc-srv01]
Outre les points identiques vis-à-vis du serveur Hyper-V, il sera possible sur le contrôleur de domaine
de monitorer les services et processus liés à ces activités, mais aussi d’effectuer des requêtes avancées
vers ces différents services à l’aide de wizard natif à Nagios.
LDAP
DHCP
DNS Query
Figure 19 Nagios - proof of concept : Serveur contrôleur de domaine
xFlow
Nagios XI ne permet pas d’analyser les flux xFlow sans le serveur « Nagios Network Analyser ».
Conclusion
La devise de Nagios est « Est-ce que Nagios peut superviser cela ? Oui, si plug-in ». Force est de
constater que cette devise est vraie, il y a de nombreux plug-ins pour beaucoup de choses, mais ces
extensions sont souvent anciennes et pas à jours, il faut donc perdre beaucoup de temps à trouver le
bon plug-in et faire de l’essai erreur afin de trouver LE plug-in fonctionnel.
À l’exception de l’ajout d’hôtes via wizard et l’Auto Discovery, toutes les autres opérations réalisables
sur Nagios XI sont très lourdes et l’interface peu ergonomique. De même, l’Auto Discovery permettra
en effet de trouver tous les hôtes du réseau en appliquant des profils déterminés en fonction du type
détecté, mais ceux-ci étant souvent mal détectés, le temps d’implémentation en est d’autant plus
allongé.
Nagios XI, à l’aide de ses plug-ins, permet donc un monitoring complet d’un SI, mais, à cause de la
lourdeur de son interface et de la pauvreté de son interface, celui-ci est trop long à implémenter et ne
conviendra pas à notre cahier des charges.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
30 Rapport
Zabbix Zabbix est un logiciel open source et basé sur Linux, qui se veut être le concurrent direct de Nagios.
Procédure de test
Aucun élément de la procédure n’a réussi.
Compte-rendu des tests
Network Auto Discovery
L’auto Discovery de Zabbix fonctionne en scannant un sous-réseau IP, mais celui-ci ne fait que pinger
toute la plage, et affiche une liste des résultats en affichant l’IP des adresses trouvées, leur FQDN, s’ils
sont intégrés au monitoring ou non, l’uptime et, évidemment, le ping.
La fonction s’arrête là (pas de propositions de probes par hôte, pas de scan des ports, …) et il ne sera
pas possible via cette liste d’ajouter un hôte au monitoring.
Figure 20 Zabbix - Auto-Discovery
Interface
Des tests d’ajout de serveur Linux et Windows ont été exécutés en suivant plusieurs procédures
trouvées sur Internet. Ces procédures étaient supposées scanner les hôtes ajoutés et ajouter des
probes automatiquement en fonction des ports ouverts et du template choisis, mais aucune procédure
n’a apporté de résultat.
De même, après ajout, il n’y avait aucun message, ni de succès, ni d’erreur, ni de barre de progression
quelconque. La documentation disait simplement d’attendre jusqu’à quelques heures et de revenir
voir le résultat.
Conclusion
Face à cette interface si peu intuitive, à la difficulté de réaliser des actions de base, et à l’utilité
discutable de l’Auto Discovery, cette solution de monitoring n’a pas été retenue.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
31 Rapport
PRTG PRTG, pour « Paessler Router Traffic Grapher », Paessler étant le nom de l’entreprise, est un logiciel
de supervision basé sur Windows.
Sa publicité est plutôt noble, mais celui-ci est reconnu par le public comme une des meilleures
solutions de monitoring.
Sa philosophie est de disposer de tous les éléments requis pour superviser notre réseau « out of the
box », mais sa popularité lui a permis d’établir une bonne communauté. Il dispose donc de nombreux
articles à son sujet, de quelques scripts et plug-ins additionnels, ainsi que d’une base de connaissance,
d’un forum et de documentation très bien alimentés et référencés sur Google, permettant une
recherche et une assistance rapide et optimale.
Ils disposent aussi d’une forte présence sur les médias sociaux, ainsi que d’un support très réactif.
Figure 21 PRTG - Alertes
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
32 Rapport
Procédure de test
Tâches Etat Notes
Serveurs OK
Switches OK
AP OK
Management OK
Imprimantes black OK
Imprimantes color OK
SLZ OK
Caméras OK
Prikklok OK
Hanwell OK
Signage OK
VLAN 15 NOK Problème réseau, non lié au monitoring
OSX, OSA OK
VLAN 25 NOK Problème réseau, non lié au monitoring
DMZ OK
Modification d'une node ajoutée par l'AutoDiscovery NA Pas nécéssaire
Recherche complexe ToDo
Facilité de l'interface (IP/FQDN,…) NOK
Suppression d'une node : PC client OK
Gestion des alertes : Imprimantes temporairement éteintes OK Auto-acknowledgment
Gestion des alertes : acknowledgment, mass/bulk acknowledgment OK
Gestion des plugins OK
Ajout manuel d'une node : switch via wizard / template OK Pas de wizard individuel
Ajout de probes sur une node : Ports uplink sur un switch OK
Suppression de probes sur une node : Ports sur un switch OK
Probes : Informations système d'un switch OK
Ajout manuel d'une node : imprimante via wizard / template OK Pas de wizard individuel
Monitoring d'un toner : Toner cyan OK Toutes les infos hardware en une probe
Ajout manuel d'une node : VPN via wizard / template NA Pas nécéssaire
Probe : Interface DMZ OK SNMP
Probe : Interface Management OK SNMP
Probe : Mémoire OK
Probe : CPU OK
Probe : température NOK
Probe : Sessions OK Sessions et liste des utilisateurs en ligne / hors ligne
Ajout manuel d'une node : Interface management 1 OK
Ajout manuel d'une node : Interface management 2 OK
Probe : Charge CPU OK SNMP
Probe : Mémoire OK SNMP
Probe : Espace disque OK SNMP
Probe : Température NOK
Probe : Ventilateur NOK
Probe : Etat du failover NOK
Ajout manuel d'une node : Serveur Linux OK
Probes SNMP : Infos système et serveur web OK Infos système et applications
Probes via agent : Infos systèmes et serveur web NA Pas d'agent
Probes SSH : Infos systèmes et serveur web OK Infos système
Services Linux NOK Plugin disponible, non testé
Processes Linux NOK
Probes HTTP OK
Ajout manuel d'une node : Windows Server 2012 R2 OK
Probes SNMP : Infos système et Hyper-V OK Infos système, services
Probes WMI : Infos système et Hyper-V OK Services, infos système, alertes via logs Windows, Windows Update,...
Services Windows OK
Processus Windows OK
Probes : Status des cartes RAID HP OK
Probes : Hyper-V OK Sensors pour l'hôte Hyper-V et chaque VM
Ajout manuel d'une node : Windows Server 2012 R2 OK
Probes WMI : Infos système et rôles OK Services, infos système, alertes via logs Windows, Windows Update,...
Services Windows OK
Processus Windows OK
Probes : Status des cartes RAID HP OK
Probes : Active Directory OK LDAP et AD Replications
Probes : DHCP NOK Non fonctionnel durant le test
Probes : DNS OK
Firewall Palo Alto PA-500 OK
Switch Core OK
Switch stack serveur OK
Network Auto Discovery
Interface
Switches
Imprimante [prn-10-36]
VPN Cisco ASA [vpn-srv01]
Serveur web Ubuntu [intweb-srv01]
Serveur Hyper-V Windows [mon-srv01]
Serveur DC Windows [dc-srv01]
xFlow
Firewall Palo Alto PA-500
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
33 Rapport
Compte-rendu des tests
Network Auto Discovery
L’affichage du monitoring sur PRTG se fait via des groupes personnalisables. Ces groupes ont plusieurs
utilités : tout d’abord, ils servent de dossiers dans lesquels sont stockés nos hôtes, dans l’ordre et le
classement de notre choix. Secondement, ils servent de template pour tous les hôtes de ce groupe en
leur faisant hériter les informations d’identifications des différents services nécessaires pour les
senseurs (SSH, Windows, base de données, …) mais aussi d’autres informations comme la gestion des
alertes, les droits d’accès par les différents groupes d’utilisateurs PRTG, la localisation, …
Finalement, c’est aussi dans les paramètres de ces groupes qu’est défini l’Auto Discovery.
Contrairement à Nagios, une fois l’Auto Discovery lancé, il n’est plus possible de l’arrêter, et il ajoute
tout ce qu’il trouve automatiquement (nodes et probes) tout seul…
Heureusement, cet outil est ici très performant et détectera un grand nombre de probes sur chaque
node, surtout au niveau du matériel. Ainsi, si par exemple les interfaces LAN des serveurs ne se verront
dotées que des capteurs par défaut pour chaque type de serveur (Ping, HTTPS, SMTP, RDP pour un
serveur Exchange), un grand nombre d’interfaces de management auront une détection complète :
marque du fabricant, adresses MAC, numéros de série, et, en fonction de la marque, du type de
périphérique et des accès disponibles, un très grand nombre de capteurs ajoutés automatiquement :
Ping, interfaces réseau, mémoire, disques physiques et une sonde telle que « SNMP HP System
Health » qui affichera virtuellement tous les paramètres hardware : contrôleurs RAID, ventilateurs,
alimentation, températures,… Ainsi, grâce aux nombreux fabricants supportés par PRTG, l’auto
détection des informations systèmes et matérielles des switches HP, serveurs Dell et HP et UPS APC
est réalisée de manière automatique et sans problèmes.
Dans les cas où une détection complète des senseurs d’une node a été faite, celle-ci a toujours été
correcte, et, de manière générale, il n’y a eu aucun senseur faussement créé, quel que soit le type de
périphérique.
Figure 22 PRTG - Création d'un Auto-Discovery
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
34 Rapport
Interface
L’interface de PRTG, une fois prise en main, se révèlera très simple et intuitive à utiliser. Toutes les
actions de gestion et d’ajout d’hôtes se font via l’onglet « device », dans lequel nous trouvons notre
liste des hôtes, classée par groupe. Tous les paramètres (informations d’identifications, permissions,
alertes, …) sont configurés par groupe et sont automatiquement hérités au descendant, par défaut.
Pour un réseau simple, tout pourrait donc être configuré uniquement sur le groupe « probe locale »,
qui désigne notre serveur PRTG.
Figure 23 PRTG - Interface "Device"
Toutes ces actions, ainsi que la visualisation des graphiques et des alertes peuvent se faire via un menu
horizontal dynamique en fonction du groupe ou périphérique sur lequel nous nous trouvons, ou via
simple clic droit sur un item. Il sera aussi possible de la même manière de supprimer, cloner,
renommer, actualiser, changer d’emplacement, … un groupe, hôte ou senseur.
Les opérations en masses sont aussi très aisées à utiliser, un menu de gestion est disponible afin de
changer les paramètres d’un ou plusieurs éléments à la fois. Il sera aussi possible de sélectionner tous
les capteurs d’un device ou d’une recherche via des checkbox afin de les supprimer ou actualiser par
exemple.
Figure 24 PRTG - Sélection de senseurs
L’outil de recherche de PRTG lui fait cependant défaut et n’est pas intuitif. Celui-ci ne permet que de
rechercher un seul élément à la fois (dans tous les éléments de PRTG au choix, y compris dans les logs,
tickets, …) mais ne permet pas de faire de recherches spécifiques, ni de rechercher plusieurs éléments
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
35 Rapport
à la fois. Il sera cependant possible d’afficher, par exemple, tous les senseurs « RDP » ayant été auto
découvert, et de tous les supprimer en une seule action. La barre de recherche est aussi disponible à
plusieurs endroits : dans le menu principal, permettant de rechercher dans tout PRTG, ainsi que dans
chaque groupe ouvert, permettant de ne rechercher que dans celui-ci, ce qui n’est pas intuitif non plus.
Si l’Auto Discovery est très performant, celui-ci n’aura détecté, avec les options par défaut, certains
hôtes que par leur FQDN, et engendre de multiples problèmes :
Il sera impossible de les retrouver via l’outil de recherche en tapant leur adresse IP, celle-ci
n’existant pas pour PRTG.
En cas de « disparition » de l’entrée dans le DNS, un périphérique apparaitra down, alors que
ce n’est pas le cas.
Certains senseurs ne sont pas utilisables sans adresse IP statique définie.
L’acknowledgement des alertes est aussi utilisable très simplement, elle se fait via le même menu
latéral qui permet de supprimer ou actualiser un élément après en avoir coché un, plusieurs ou tous.
Il sera alors possible de définir le senseur comme acknowledged pour un laps de temps, toujours mais
pas « jusqu’à un certain événement ». PRTG ne disposant toutefois pas de fonctions de gestion des
downtime, les imprimantes éteintes devront être gérées en définissant l’auto-acknowledgement du
ping de chaque machine, ce qui permettra de mettre en pause tous les autres capteurs de ladite
machine par cascade. Le menu de gestion, permet de faire cela pour plusieurs hôtes d’un groupe en
même temps.
Figure 25 PRTG - Auto acknowledgment des imprimantes éteinte
Plugins
Ce n’est pas l’argument de PRTG, mais celui-ci permet aussi d’exécuter des scripts pour certains cas
spécifiques, et dispose d’une bibliothèque de plug-ins. Cette bibliothèque est peu fournie
(actuellement 43 scripts par Paessler, 46 scripts par des utilisateurs contre 236 scripts natifs), mais a
l’avantage que chaque plug-in n’y est ajouté qu’après vérification : tous les plug-ins présents sont donc
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
36 Rapport
fonctionnels. Leur installation se fait, en général, simplement en les déplaçant dans le dossier
approprié sur le serveur PRTG ou l’hôte à monitorer.
Switches
L’ajout d’hôtes individuels est un Auto Discovery, mais pour une seule IP ou FQDN. Il sera bien sûr
possible, de le désactiver, ou d’en avoir un plus détaillé, où il ajoutera divers capteurs de PDU en plus
des capteurs de protocoles et de services.
L’Auto Discovery a découvert les informations matérielles (CPU, mémoire, ping) ainsi que les états et
la bande passante de chaque port sur chaque switch, mais PRTG n’ajoute que les ports branchés lors
de la découverte au monitoring. Chaque port est ajouté via la sonde «SNMP Traffic » qui permet de
surveiller l’état et la bande passante d’un port, ainsi que via la sonde « SNMP RMON » qui permet une
analyse détaillée du type de paquet qui transite.
Figure 26 PRTG - Senseur "SNMP RMON"
L’ajout de ports après l’Auto Discovery, se fait via le bouton « Recommend Now » qui relance un Auto
Discovery, ou via l’ajout d’un senseur à la fois, sur chaque périphérique. PRTG dispose de plus de 200
senseurs de tout type, allant du simple ping au monitoring de machines virtuelles. Il est bon de noter
cependant que l’ajout de certains senseurs en ajoute en réalité plusieurs sur le périphérique (ex. 10
senseurs RMON pour 10 ports d’un switch), tandis que d’autres en intègreront plusieurs en un seul
senseur.
Figure 27 PRTG - Menu d'ajout de senseur
La suppression de senseurs se fait en quelques clics via case à cocher.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
37 Rapport
Figure 28 PRTG - Suppression de senseurs
Imprimante
Comme tout, les imprimantes sont ajoutées automatiquement avec une multitude de senseurs en
fonction de l’imprimante.
Ping
Interfaces réseau
RAM
http
Temps d’impression d’une page
Nombre de pages imprimées
Un senseur additionnel “SNMP Printer” existe et fourni, en un seul senseur, une multitude de données
hardware, dont l’état de chaque toner. Ce senseur fait double emploi avec celui du nombre de pages
imprimées.
Figure 29 PRTG - Senseur "SNMP Printer"
VPN Cisco ASA
PRTG étant partenaire avec Cisco, le support du VPN Cisco ASA est optimal. Avec l’Auto Discovery et
les senseurs natifs, il est possible de monitorer, pour notre cas :
Ping
Interfaces DMZ et Management
CPU (Utilisation et downtime, par CPU)
Mémoire (Downtime et utilisation, par mémoire)
Connections (par type)
Utilisateurs (Nom AD des clients connectés en ligne ou hors ligne, depuis l’ajout du senseur)
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
38 Rapport
Figure 30 PRTG - Proof of concept : VPN Cisco ASA
Firewall Palo Alto PA-500
Palo Alto n’est officiellement pas supporté par PRTG, il n’y a donc pas de capteurs natifs dédiés à cette
marque. Il est cependant possible d’utiliser SNMP afin de monitorer plusieurs éléments de nos
firewalls.
Ping
Interfaces réseau
Charge CPU
Utilisation des disques
Mémoire
HTTPS
Figure 31 PRTG - Proof of concept : Firewall Palo Alto
Serveur Hyper-V Windows [mon-srv01]
Si les informations d’identifications dans le groupe parent (ou individuellement lors de l’ajout du
device) sont correctes, PRTG trouvera une très, très grande multitude de probes pour chaque serveur,
comprenant chacune de multiples informations tellement détaillées qu’il serait impossible de toutes
les décrire ici.
Attention que l’Auto Discovery est réalisé via tous les protocoles dont PRTG dispose des informations
d’identifications. Dans ce cas, de nombreux doublons sont donc ajoutés par défaut, car PRTG ajoute
tout à la fois via WMI, SNMP classique, et les senseurs SNMP HP, ce qui donnera un gros travail de tri,
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
39 Rapport
voire de recréation de senseurs dans certains cas sur chaque serveur, si WMI et SNMP sont tous les
deux activés.
Ping
Cartes réseau
Cartes réseau virtuelles
Uptime
Charge CPU
Pagefile
Mémoire physique
Mémoire virtuelle
Disques, partitions et volumes (Utilisation, temps de lecture, …)
HTTPS
RDP
Status de Windows Update (mise à jour à faire, …)
HP System Health (informations hardware sur les serveurs HP)
Figure 32 PRTG - Senseur "HP System Health"
Mais aussi des senseurs propres au type de serveur, Hyper-V dans ce cas :
Switch (cartes réseau virtuelles) Hyper-V
État de chaque machine virtuelle Hyper-V
Hyper-V Host Server
Figure 33 PRTG - Senseur « Hyper-V Host Server »
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
40 Rapport
En plus de tout cela, il est possible de rajouter des senseurs natifs afin de monitorer l’état des services
via WMI, les redémarrer automatiquement en cas de problèmes, et soit monitorer uniquement l’état
du service, soit récupérer des informations détaillées. Il est aussi possible nativement de monitorer les
processus, mais il faudra entrer chaque nom manuellement dans ce cas.
Figure 34 PRTG - Proof of concept : Serveur Hyper-v
Serveur contrôleur de domaine, DNS, DHCP, Active Directory [dc-srv01]
Outre les points identiques vis-à-vis du serveur Hyper-V, il sera possible sur le contrôleur de domaine
de monitorer les services et processus liés à ces activités, mais aussi d’effectuer des requêtes avancées
vers ces différents services à l’aide de différents senseurs natifs.
LDAP
Active Directory Replication
DNS (Requête DNS vers un enregistrement de type définissable)
DHCP (non fonctionnel lors du test)
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
41 Rapport
Figure 35 PRTG - Proof of concept : Serveur contrôleur de domaine
Serveur web Ubuntu [intweb-srv01]
Tout comme pour les serveurs Windows, l’Auto Discovery individuel est très performant, mais génère
un grand nombre de senseurs en doublons. Ceux-ci sont disponibles en SNMP et SSH.
Un grand nombre de senseurs sont ici aussi créés, mais aucuns liés à l’utilisation du serveur.
Ping
Interfaces réseau
Charge CPU
LVM
Mémoire physique
Mémoire virtuelle
Mémoire swap
Disponibilité
Nombre de processus actifs
http/s
Disques physiques (Nombre d’accès, charge, downtime, vitesse de transfert, données
transférées, …)
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
42 Rapport
Espace disque
Inodes libres
Pour monitorer les services fournis par ce serveur, la philosophie de PRTG est de faire des requêtes
approfondies en fonction du type de serveur (ici, des transactions http par exemple) au lieu de
simplement tester le fonctionnement des services. Il existe donc un senseur pour le test de base de
données via des requêtes personnalisables, et une multitude pour de tests http. Il existe aussi un
senseur pour tester PHP, mais il n’est pas natif.
Curieusement, si PRTG dispose de deux senseurs pour monitorer les services Windows (un via WMI et
un via SNMP), il n’en existe nativement (disponible sur Script World) aucun pour Linux, quel que soit
le protocole.
Figure 36 PRTG - Proof of concept : Serveur web Linux
Fonctionnalités supplémentaires
xFlow
PRTG dénomme xFlow tous les protocoles d’analyse de flux basés sur Netflow (jFlow, sFlow, IPFix,…),
et leur intégration est simple. Il sera possible de visualiser le trafic par protocole défini sur une période
d’un quart d’heure par défaut, ainsi que le trafic entre des hôtes.
Figure 37 PRTG - Senseur "xFlow"
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
43 Rapport
Analyse de comportement
PRTG conserve les graphiques et données des senseurs afin d’analyser leur comportement sur une
période de temps donnée et d’en établir une utilisation de référence moyenne. Ainsi, si l’utilisation
actuelle diffère trop de cette moyenne de référence, PRTG pourra donner une alerte « Unusual » sur
un senseur.
Tickets
PRTG dispose d’un système de ticket interne, permettant, entre autres, d’assigner des éléments du
monitoring à des utilisateurs internes. Il est possible de remplacer ce système de ticket par un autre
supporté par PRTG afin de créer les tickets dans celui-ci et/ou dans PRTG.
De même, des boutons sont disponibles partout afin d’envoyer des éléments du monitoring ou des
alertes directement par mail ou d’ouvrir un ticket avec ceux-ci.
Conclusion
PRTG est, grâce à son grand nombre de senseurs natifs, une solution de monitoring très performante.
L’interface devient rapidement simple et intuitive, toutes les actions de gestion sont centralisées par
groupes, et les options de gestion en masse sont, elles aussi, bien implémentées.
L’Auto Discovery est très performant et permet d’ajouter automatiquement un grand nombre de
senseurs très détaillés, que ce soit des protocoles, des applications, mais surtout des informations
matérielles. Même l’Auto Discovery pour l’ajout d’un hôte individuel est possible. En revanche, si cette
fonction est très performante, celle-ci ajoute tout automatiquement, dont un très grand nombre de
senseurs qui font double voire triple emploi.
Les senseurs de PRTG sont en général plus adaptés à la supervision d’information matérielle, de
paquets et d’applications partenaires. Leur philosophie est que cette solution est un package complet
et qu’il vaut mieux tester un serveur via des requêtes complètes et en profondeur, comme une
transaction http pour un serveur web, mais il est regrettable qu’il ne soit tout de même pas possible
de superviser les services nécessaires à un serveur web sous Linux nativement.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
44 Rapport
NetCrunch NetCrunch est un logiciel de supervision de réseau polonais, dont la force est sa représentation
cartographique du réseau. Il est vanté par ses développeurs comme tels :
Demande peu de ressources
Interface intuitive, simple à utiliser
Automatisé
Très simple à mettre en place en demandant peu de temps
« Trouble-free », le programme subit diverses procédures de tests afin d’éviter les bugs
Sa présence communautaire en ligne est cependant très faible, et l’entièreté de sa documentation «
NetCrunch Guide » n’est recensée qu’en une seule page web. Le référencement étant mal optimisé et
la communauté absente, toutes les recherches de documentation et assistance se feront via ce guide.
Procédure de test
Les tests ont été abandonnés à cause de la trop grande présence de bugs.
Résultat des tests
Auto Discovery
L’Auto Discovery de NetCrunch se déroule en deux étapes distinctes : la première ouvre une fenêtre
dans laquelle nous pourrons entrer plusieurs sous-réseaux IP à scanner, et en exclure une IP, ou une
plage IP. Cette fenêtre nous incite fortement à y entrer, en une seule fois, toutes nos plages IP à
scanner afin de ne pas devoir répéter cette action de nombreuses fois.
Ce faisant, j’ai déjà expérimenté le premier bug de NetCrunch. La tâche a freezer dès le premier scan
de l’étape 2 et n’a rien ajouter au monitoring pendant plusieurs heures, et aucun bouton « annuler »
n’était disponible. Les services Windows de NetCrunch étant trop nombreux, j’ai jugé qu’il était plus
rapide de redémarrer complètement le serveur afin d’interrompre cet Auto Discovery.
Après avoir entré la plage à scanner et toujours dans la première étape, NetCrunch va scanner cette
dernière pour afficher une liste des hôtes (identifiés par leur IP + hostname si détecté), dans laquelle
il sera possible de sélectionner ou désélectionner les hôtes voulus.
Une fois cette procédure terminée, l’étape 2 se lance en tâche de fond. Il s’agit d’un Auto Discovery
qui se chargera de détecter les services des hôtes choisis, mais qui sera, cette fois, automatique et sans
invite de confirmation.
L’Auto Discovery est simple, mais lourd et long à se réaliser, et le résultat est plutôt moyen. Les hôtes
sont correctement identifiés via les informations SNMP (IP, FQDN, hostname, localisation si définie,
nom du matériel, type, …) mais les services monitorés ne suivent pas cette tendance.
Par exemple, les imprimantes ne seront monitorées que par des services de base (Wins, SNMP, Ping,
FTP, HTTP), aucun lié à leur type. Les serveurs sont un peu mieux identifiés et sont dotés de probes liés
à leur utilisation (LDAP, DNS pour le contrôleur de domaine), mais aussi de nombreuses autres probes
qui ne seront pas forcément utiles (paquets TCP, processus, TOUS les services par WMI, …). Les
switches sont dotés de tous les ports et VLAN automatiquement ainsi que des services réseau de base,
mais aussi de probes liées au matériel comme « HP ProCurve » qui donne des informations sur la
température, l’alimentation, les ventilateurs, … Mais pas mémoire, processeur, …
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
45 Rapport
La détection de nodes est donc très bonne et complète, mais celle des probes ne suit pas cette
tendance et ajoute beaucoup trop d’éléments automatiquement (tous les services WMI,…), qui ne
nous seront pas forcément utiles, et consommeront par conséquent trop de ressources réseau et
serveur.
Interface
NetCrunch dispose bel et bien d’une interface web, mais celle-ci est très lente (affichage des items, …)
et limitée en fonctionnalité. Elle ne convient pas à la gestion et ne permet quasiment que des actions
de « viewer ». La gestion du monitoring se fait via une console lourde à installer sur chaque machine,
et à mettre à jour à chaque update de NetCrunch, la rétrocompatibilité n’étant pas permise.
L’interface ressemble donc évidemment plus à un gros programme lourd qu’à une interface web. Ainsi,
la plupart des actions se font via une toolbar de software classique (file, edit, view, …) et une sidebar
qui contiendra les éléments de l’Atlas (nom donné à la base de données des éléments supervisés)
suivant le classement de notre choix, ou via type de périphérique. Sur un sous-réseau scanné, nous
aurons une liste de nos périphériques, et à chaque clic, une nouvelle fenêtre s’ouvrira : une pour voir
les éléments monitorés du périphérique, une pour les modifier,…
NetCrunch, comme PRTG, dispose de plusieurs probe matérielle (APC, HP ProCurve,…), mais ceux-ci
ne sont pas formatées et renvoient les données et graphiques de la MIB fournie par le constructeur de
manière brute. Par exemple, si PRTG renvoie pour un APC « Last Battery Test Status : Failed »,
NetCrunch renvoie « upsAdvBatteryReplaceIndicator : 2.00 »…
Figure 38 Netcrunch - Lourdeur de l'interface
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
46 Rapport
Fonctionnalités supplémentaires
Physical Segments
Netcrunch dispose d’un outil de mappage du réseau très intéressant et performant. De manière
automatique, celui-ci analyse la table d’adresses MAC de chaque switch (ainsi que STP et CDP en
option, la recherche se fait uniquement sur la couche 2 donc) et réalise une carte interactive des
segments physiques du réseau.
Il sera ainsi possible d’obtenir une carte globale des switches du réseau comprenant leur hiérarchie, le
pourcentage d’utilisation de la bande passante de chacun et l’état des éléments.
Figure 39 Netcrunch – Proof of concept : Physical segments
Plus intéressant encore, il sera possible de sélectionner un segment défini et d’obtenir une vue
détaillée des connexions du switch. Ainsi, en étant sur le segment appartenant au core switch, nous
pouvons voir des boites identifiées par les numéros des ports du switch et des liaisons entre celles-ci
et le switch, affichant la bande passante en upload et download. Lesdites boites sont des liens vers les
autres niveaux hiérarchiques du réseau, et il sera ainsi possible de voyager jusqu’à un switch final et
d’y voir chaque périphérique connecté et ajouté au monitoring, sur chaque port du switch, et toujours
les liens vers les autres switches. Chaque boite étant un lien, il sera possible d’accéder au monitoring
d’un périphérique final directement par ce menu.
Figure 40 Netcrunch - Physical segments : switch
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
47 Rapport
Crashes 10.1
IT’S NOT A BUG, IT’S A FEATURE
La page « troubleshooting » de Netcrunch revendique qu’il est « trouble-free » et qu’il passe par
diverses procédures de test et de développement permettant d’éviter les bugs, mais cette expérience
a été tout le contraire. Dès les premiers tests, Netcrunch s’est montré lent, instable et plantait souvent,
rendant son utilisation presque impossible.
En effet, le service « Netcrunch server » s’éteignait très régulièrement (plusieurs fois par heure, ou par
jour), même en IDLE. Après de nombreuses heures de recherche et tests de résolution de ce problème
(rendue encore plus difficile, car Adrem, confiant en la fiabilité de son programme, enregistre des
« rapports de bugs bien gérés par le système », mais pas de crash dumps), j’ai finalement configuré
PRTG pour qu’il monitore ce service, et le redémarre automatiquement.
Figure 41 Netcrunch - Instabilité du service serveur
Ne trouvant pas de réelle résolution à ce problème, j’ai ouvert un ticket au support d’Adrem, celui-ci
m’a répondu, seulement quelques heures plus tard :
« Ceci était un problème connu dans NC 10.1. Cependant, la version 10.2 est sortie
hier et devrait résoudre ce problème. Merci de mettre à jour votre NetCrunch et
vérifier si tout est OK. »
Me rendant sur la page dédiée aux mises à jours de la console de NetCrunch, il m’est apparu que ce
dernier avait en effet ouvert un ticket interne notifiant la mise à jour du programme… il y a une
trentaine de minutes seulement… Et la mise à jour était impossible à réaliser sur la console. Nouveau
mail au support pour ce problème, avec cette fois une réponse dans la demi-heure :
« Oui, nous avons le même problème. Il devrait être réglé bientôt.
Merci de télécharger la nouvelle version par le portail client et mettez là à jour.»
Mais je n’étais pas au bout des surprises : la mise à jour « manuelle » comporte bien le message « votre
Atlas et vos paramètres de monitoring seront conservés », mais après la mise à jour … Tout avait
disparu. Plutôt que de vérifier les backups automatiques du programme, j’ai préféré effectué une clean
install.
Résumons : NetCrunch Server en version 10.1 (sortie le 1er février 2018) crashe régulièrement sur
« certains systèmes ». Ce problème étant corrigé par NetCrunch 10.2 (sorti le 21 mars), le support me
conseille de mettre à jour le programme … Action qui est impossible via NetCrunch, car buggée, elle
aussi… On repassera pour le logiciel « trouble-free » qui crashe sur une version en production depuis
près de deux mois et dont la fonctionnalité de mise à jour ne fonctionne pas.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
48 Rapport
Crashes 10.2
IF IT’S NOT WORKING, STOP DOING IT
Après une réinstallation propre du serveur NetCrunch et de sa console sur le client, j’ai recommencé
les tests à zéro. Si le service « NetCrunch Server » ne s’arrêtait cette fois plus incessamment, de
nombreux nouveaux bugs rendaient l’utilisation de la console impossible. La première étape de mes
tests étant toujours l’Auto Discovery, nous pouvons dire que je commence par la même occasion par
un stress test.
Ces Auto Discovery / Stress test fonctionnaient correctement au début, mais dès les 300 nodes
dépassés, la musique était totalement différente. La console et le serveur ne faisaient qu’avoir des
timeout, erreurs inconnues ou crash de la console lors de nouveaux Auto Discovery ou ajout d’hôtes,
rendant les opérations impossibles et les tâches effectuées perdues, selon le type de bug.
J’ai encore une fois passé de nombreuses heures à tenter de résoudre le problème via diverses
méthodes, sans succès. Parmi ces méthodes :
Reboot
Analyse de l’observateur d’évènements
Analyse des erreurs
Analyse de paquets
Arrêt de tous les services des autres applications installées, et des VM
Installation d’une nouvelle interface LAN, permettant d’avoir la console sur une interface, et
le monitoring sur une autre
En plus de tous ces problèmes, nous pouvons remarquer une intrusion flagrante d’AdRem (et
probablement une récupération massive de données en background), constatée sur mon poste client
ainsi que sur le serveur.
Figure 42 Netcrunch - Consommation de ressource et instabilité de la console client
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
49 Rapport
Conclusion
Étant donné ces nombreux bugs critiques de l’application résolus après seulement près de deux mois
par les développeurs, je ne peux que déconseiller cette solution, même si ses fonctionnalités
pourraient être intéressantes.
En effet, leur publicité mensongère de « trouble-free » mise à part, qui peut garantir que la version
10.3 n’aura pas de nouveau un problème similaire, rendant notre serveur de monitoring en production
inutilisable durant des mois ?
Comparatif des solutions de monitoring testées
Zabbix Nagios XI PRTG NetCrunch
Utilisation de l'Auto Discovery + ++ + ++
Performance de l'Auto Discovery --- + +++ =
Interface web + ++ +++ --
Facilité de gestion --- - ++ NA
Facilité de lisibilité des éléments et alertes NA + +++ -
Interface intuitive --- - +++ -
Gestion des utilisateurs NA = + NA
Gestion des alertes (corrélation, escalation,…) NA --- + NA
Gestion des alertes (donwtime, acknowledge,…) NA ++ = NA
Fonctionnalités supplémentaires (xFlow, maps,…) NA NA + ++
Performance (Interface, lenteur, scans,…) + ++ -- ---
Communauté et assistance -- ++ ++ --
Durée d'implémentation (estimation) NA - ++ NA
Ressenti personnel -- - ++ ---
Légende : de --- à +++, +++ étant le meilleur, NA : fonctionnalité non expérimentée
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
50 Rapport
Implémentation de la solution de monitoring
Cahier des charges Au fur et à mesure des réunions, de la découverte du réseau et de l’analyse de solutions, j’ai pu établir
un cahier des charges comprenant les éléments à monitorer ainsi que les attentes du personnel sur la
solution de monitoring à implémenter.
Solutions de supervision
Must-Have Nice-To-Have
Auto Discovery du réseau Prédictibilité de pannes
2 terminaux de monitoring Analyse des comportements inhabituels
Interface web Gestion des alertes (corrélation, escalation,…)
Interface de gestion simple et intuitive Serveur de centralisation des logs
Budget de 10.000 € HTVA au maximum pour la première année
Analyseur de flux réseau
Utilisateur viewer (read-only) Système de ticket interne
Monitoring réseau
Éléments à superviser
Must-Have Nice-To-Have
Windows Server 2012 et 2016 Imprimantes
Ubuntu 12.04 et 16.04 Access point Aerohive
Hyperviseur Hyper-V Sondes environnementales
Serveurs web (MySQL, Apache, PHP, requêtes HTTP)
Bancontact
Contrôleur de domaine (Active Directory, DHCP, DNS)
Caisses
Switches HP Procurve Caméras
Microsoft Exchange (Backup, envoi de mail) Players
Firewall Palo Alto Mcafee
VPN Cisco ASA Symantec Backup Exec
Dell EMC Isilon Veeam One
UPS
Pointeuses
Badge
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
51 Rapport
Best practices Serveur physique ou virtuel ?
Un serveur de monitoring doit être un serveur physique et non un serveur virtualisé, pour diverses
raisons :
Si l’hôte de virtualisation rencontre des problèmes (matériel, crash de l’hyperviseur,
surcharge, …), le monitoring afficherait des nombreuses alertes, alors que ce serait lui la cause.
Dans le pire des cas, le monitoring complet pourrait être arrêté.
Certaines solutions de monitoring, suivant leur implémentation, pourraient être très
gourmandes :
o En bande passante, il faudrait donc de multiples interfaces réseau afin de pallier à ce
problème
o En accès disque, ce qui pourrait ralentir toutes les autres machines virtuelles du cluster
ou y créer des bugs
Tous les professionnels rencontrés lors de l’Infosecurity m’ont toutefois confié que, non officiellement,
leur solution fonctionne sans problème en virtualisé, même pour des serveurs supervisant de grands
parcs informatiques. C’est toutefois peu optimal, très risqué, déconseillé, voire interdit à partir d’un
certain nombre de probes, certaines solutions allant jusqu’à annuler le support en cas de problème
avec un serveur de monitoring opérant en environnement virtualisé.
Frais de maintenance ?
Le modèle économique de la plupart des solutions de monitoring est similaire et comprend deux types
de frais :
Frais de licence : Donne accès à une licence, qui comprend un nombre maximal de nodes ou probes
supervisables. Hormis cette restriction, une licence donne un accès complet et sans limites de temps
au produit (suivant les CGU).
Frais de maintenance : En plus des frais de licence, il faudra annuellement payer des frais de
maintenance logicielle (souvent offert la première année). Ces frais donnent droit à ces avantages :
Sécurité : Le logiciel sera régulièrement tenu à jour, ce qui limitera l’exposition à des risques
de sécurité en ayant un logiciel non à jour.
Mises à jour : Les éditeurs publient régulièrement des mises à jour, offrant des correctifs de
bugs, améliorations ou nouvelles fonctionnalités majeures ou mineures.
Support : Les frais de maintenance donnent souvent droit à un support par mail en cas de bugs
ou de difficultés à mettre en place un élément.
Il est par conséquent obligatoire d’être toujours couvert par la maintenance, et de tenir n’importe quel
logiciel toujours à jour, ne serait-ce que pour ne pas exposer à des failles de sécurité un logiciel qui
contient des tonnes d’information sur tous les éléments du réseau en temps réel, des mots des accès
privilégiés aux serveurs en SSH, accès Windows, SNMP, …
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
52 Rapport
Défaillance du serveur de monitoring ?
Si PRTG et Netcrunch ajoutent automatiquement le serveur local au monitoring avec des probes
relativement approfondies, celles-ci n’auraient que peu d’intérêt en cas de réelle défaillance du
serveur.
En effet, si le serveur hébergeant la solution de monitoring subissait une panne, tout le monitoring
deviendrait inaccessible lui aussi, sans pouvoir connaître l’état de ses probes.
PRTG offrant une licence gratuite jusqu’à 100 senseurs, ma recommandation serait d’héberger celle-
ci dans une machine virtuelle, qui ne serait chargée que de superviser le serveur physique de
monitoring et ses services de manière approfondie.
Choix de la solution de monitoring Suite à mes tests et analyses des solutions de monitoring ainsi que des présentations à l’équipe et
divers débats, le manager a finalement suivi ma recommandation et a acheter une licence d’un an et
5000 senseurs pour PRTG, mes premières estimations étant qu’on aurait besoin d’entre 2200 et 2800
senseurs afin de monitorer correctement tous les éléments du réseau.
Le choix de la licence 5000 au lieu de 2500 permet d’être évolutif, et de pouvoir éventuellement
monitorer tous les ports des switches au lieu de seulement les ports d’uplink comme actuellement. De
même, si nous avions pu avoir un monitoring du réseau correct avec 2500 capteurs, certains éléments
ou certains périphériques jugés comme non vital à monitorer sur PRTG par l’équipe (imprimantes,
access point, sondes RDP, …) auraient dû être supprimé afin de libérer des senseurs.
Déploiement de PRTG La seconde partie de mon stage a donc été d’implémenter PRTG dans le réseau, et de configurer les
périphériques supervisés.
Installation
Il a été décidé d’installer PRTG sur un autre serveur4 disponible, au modèle identique à celui que j’ai
eu pour mes tests, mais aux performances matérielles moindres. Celui-ci avait cependant un contrat
de maintenance toujours en cours, le choix était logique vu d’un aspect financier. J’ai ensuite dû
installer ce serveur sous Windows Server 2016 Standard, avec les pilotes officiels fournis par HP pour
Windows Server 2012 R2.
Pour la configuration du RAID, j’ai suivi les recommandations de PRTG et fait avec les disques qui
étaient à ma disposition. Paessler recommandant un RAID 10 de 500 Go d’espace disque pour une
année de monitoring avec 2500 senseurs, je n’ai pu réaliser que la configuration suivante.
Array OS : 2 disques de 146 Go en RAID 1, donnant une partition de 136 Go.
Array PRTG : 6 disques de 146 Go en RAID 10, donnant une partition de 410 Go.
Une grande partie de la configuration du monitoring ayant déjà été faite lors de la phase de test et la
phase d’attente de décision, j’ai réalisé un backup de PRTG afin de l’importer sur le nouveau serveur.
Cette étape a été réalisée rapidement et sans problèmes en suivant la documentation de PRTG.
4 Voir annexe 5 : Documentation technique – Serveur en production
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
53 Rapport
Les backups n’étant pas automatisés, j’ai ensuite réalisé des backups manuels lors de remplacement
du matériel du serveur pour raison de défaillance.
Configuration de SNMP
Une des étapes du déploiement du serveur de monitoring dans le réseau de la Bibliothèque royale de
Belgique a été la configuration de SNMP sur chaque périphérique l’utilisant, ces derniers étant
configurés en SNMPv2 avec la communauté « public » pour la plupart, ou avec une configuration non
fonctionnelle pour d’autres.
Préalablement, j’ai effectué des recherches afin de déterminer quelle est la manière la plus optimale
et sécurisée à ce jour de configurer SNMP. Ce protocole véhiculant énormément d’informations sur
chaque périphérique et permettant même de les configurer, il était recommandé de toujours utiliser
le mode le plus sécurisé possible, et de disposer de plusieurs comptes SNMPv3 (ou communautés
SNMPv2) par criticité des périphériques. Si possible, il est aussi recommandé de renforcer la
configuration de SNMP en désactivant les fonctionnalités non utilisées : trap et paramétrage via SNMP
dans notre cas étant donné que nous ne faisons que du polling, et de configurer l’IP du serveur PRTG
comme étant le gestionnaire SNMP (NMS), afin que le périphérique n’envoie ses PDU SNMP qu’à cette
IP.
Après la création d’un premier modèle de configuration, suivi d’une réunion afin de valider entre
autres ce modèle de sécurité SNMP, il est apparu que j’allais finalement configurer un compte par
groupe de périphérique pour plus de simplicité (kbr-servers, kbr-network, kbr-peripherals et kbr-
management), et avoir la même clef d’encryption de contenu AES sur tous ces comptes.
J’ai ensuite généré des clefs de sécurité pour chaque compte, répondant aux exigences de sécurité
actuelles :
24 caractères, majuscules, minuscules, chiffres, caractères spéciaux
Clef d’authentification SHA-1
Clef d’encryption du contenu AES
J’ai configuré la localisation et le contact SNMP pour chaque périphérique par la même occasion, en
respectant la syntaxe choisie par l’équipe.
La configuration SNMPv3 s’est faite via les interfaces web ou console de chaque périphérique utilisant
ce protocole, ou via un script de configuration pour les switches me permettant de les configurer en
SNMPv3 et de supprimer leur précédente configuration SNMPv2 de manière plus efficace.
Problèmes rencontrés
Switches
Au cours de cette étape, j’ai rencontré plusieurs problèmes. Une dizaine de switches avaient un
firmware très ancien (08.xx, datant de 2006), qui ne permet pas l’utilisation d’AES. Pour pallier à ce
problème, j’ai créé un compte dédié à ces switches et généré d’autres clefs pour celui-ci, cette fois
avec le protocole non recommandé « DES » pour l’encryption des données au lieu d’AES.
De même, 3 switches « de bureau » ne permettaient pas l’utilisation de caractères spéciaux dans les
clefs, j’ai résolu ce problème de la même façon, en créant un 3e compte « kbr-network-a3100 » pour
eux.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
54 Rapport
Second problème, SNMPv3 ne fonctionnait pas sur deux switches en version 10.50. Pour confirmer
que le problème venait bien de cette version de la version du firmware, j’ai eu à ma disposition un
switch de modèle identique en version 08.XX. SNMPv3 fonctionnait bien sur cette version. Je l’ai
ensuite mis à jour vers 10.50 où SNMPv3 ne fonctionnait plus, puis vers la dernière version du firmware
où SNMPv3 fonctionnait à nouveau.
Dell Idrac
La configuration de SNMPv3 sur les interfaces de management de serveur de Dell n’a pas abouti,
malgré un grand nombre d’heures passées à tenter de le résoudre. Ainsi, diverses versions des iDRAC
ont été testées, diverses clefs de sécurité en faisant varier les nombres de caractères, en mettant des
symboles ou non, divers protocoles de sécurité … J’ai même pris contact avec le service client dédié
aux professionnels, qui n’a pas su m’aider non plus.
Ce problème a été contourné en utilisant SNMPv2, mais avec une communauté respectant les
recommandations actuelles. Cette communauté est donc commune aux iDRAC uniquement, et est une
chaine de caractère générée, contentant 24 caractères, chiffres, lettres, majuscules et symboles.
Autre problème, une grande partie des Idrac étaient inaccessibles à cause d’un défaut de
configuration. Ces interfaces nécessitaient une réinitialisation complète par le BIOS, mais ces serveurs
sont en production et ne peuvent donc pas être arrêtés dans les heures de travail.
Imprimantes
Le parc d’imprimante étant trop varié en marques, types, années de mise en service et date de la
dernière mise à jour, trop de problèmes empêchaient l’utilisation de SNMPv3. Celui-ci n’était pas
disponible sur toutes les imprimantes, ou avait des restrictions en termes de clef de sécurité (limite de
caractère à 12, pas de symboles …) ou ne fonctionnait simplement pas sur les Ricoh.
Pour pallier à ce problème, il a été choisi d’utiliser SNMPv2 avec une communauté commune à tout le
parc d’imprimantes, qui est une clef alphanumérique de 8 caractères générée avec des majuscules,
mais sans symboles.
Print Server Windows
Après avoir configuré une première fois les imprimantes de la manière la plus optimale, nous nous
sommes rendu compte que les imprimantes ne fonctionnaient plus. Un grand nombre de problèmes
étaient liés à la reconfiguration de la communauté SNMP sur les imprimantes.
Le serveur d’impression Windows utilise SNMP pour définir l’état des imprimantes (statuts,
toner, …) et, la communauté de chaque port étant resté en « public », le serveur ne savait plus
contacter les imprimantes et les a toutes passées en « hors-ligne », rendant l’utilisation des
imprimantes impossible.
o Pour résoudre ce problème, il fallait soit désactiver SNMP, rendant l’utilisation des
imprimantes possible, mais le serveur n’affiche plus leurs états. La seconde solution a
été de définir la bonne communauté au lieu de « public ».
Malgré la modification de la bonne communauté sur les imprimantes Ricoh et le port associé
sur le serveur d’impression, le problème persistait. Ces imprimantes permettant un
paramétrage « poussé » de SNMP, je les avais sécurisées au maximum, y compris en
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
55 Rapport
définissant l’IP de PRTG en tant que gestionnaire SNMP, les PDU SNMP n’étaient donc pas
envoyées au serveur d’impression malgré le réglage de la bonne communauté.
o Pour résoudre ce problème, j’ai reconfiguré chaque Ricoh afin de désactiver la
restriction du gestionnaire SNMP, rendant l’envoi de PDU SNMP possible sur
n’importe quel périphérique.
Il est impossible d’ajouter une nouvelle imprimante dotée d’une communauté autre que
« public » au print server, celui-ci l’ajoutant à l’aide de cette communauté par défaut.
Ne permets pas l’utilisation de SNMPv3
Sondes Même si l’auto discovery de PRTG est très performant et ajoute automatiquement la plupart des
sondes adaptées sur le périphérique en fonction de son type et des identifiants fournis, j’ai dû
supprimer les sondes découvertes en doublons, inutilisées ou inutilisables, puis ajouter manuellement
un grand nombre de sondes natives, telles que :
Les sondes permettant de voir les statuts matériels de chaque imprimante
Les sondes pour chaque imprimante sur le serveur d’impression, permettant d’avoir la même
vue pour chaque imprimante sur PRTG que sur le print server
Les sondes matérielles (santé du serveur, disques physiques, interfaces réseau, …) sur les
interfaces de management des serveurs
Les services adaptés en fonction de chaque serveur Windows par WMI
Les disques durs physiques, logiques et l’état des Hyper-V SAN via SSH
Les sondes utiles pour le serveur Exchange 2010 (latence, queue, état, …)
Les URL des sites web locaux, permettant de vérifier la disponibilité de ces derniers ainsi que
l’état du service web sur les serveurs Linux par la même occasion
Afin de superviser des éléments non repris dans les sondes natives ni dans le script world de Paessler,
j’ai aussi dû créer des senseurs SNMP custom. Pour se faire, il a fallu récupérer l’OID de l’élément
voulu, lui donner un nom et un type de donnée.
Parmi les types de données, il est soit possible d’utiliser les types prédéfinis (CPU, pourcentage,
nombres, …) ou de créer des « lookups », qui permettent d’associer un numéro retourné par l’OID a
un message ou une alerte (Ex : « 1 » retournera « good », « 5 » retournera « down »).
L’autre méthode d’ajout de sondes personnalisées est en récupérant sur le web (ou en créant) des
librairies SNMP, qui font en quelque sorte la même chose que les sondes « SNMP custom », mais dans
un fichier «.lib » à importer sur le serveur PRTG. Il faudra ensuite ajouter les sondes voulues via des
cases à cocher dans le senseur « SNMP Library ».
Parmi ces sondes personnalisées, j’ai créé :
CPU, mémoire, ventilateurs et températures des switches
Sondes de température externe connectées aux APC
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
56 Rapport
Nodes du storage :
État des disques physiques, associés à un lookup 5créé en fonction des valeurs fournies par la
documentation d’Isilon 8.
Sondes de température
Santé
Vitesse des ventilateurs
Performances du système de fichier et des protocoles actifs
Cluster du storage :
Santé
État du cluster
Numéro d’identification des nodes en ligne, hors ligne et configurées
Alertes PRTG permet une intégration avec des groupes Active Directory, nous avons donc créé un groupe pour
les administrateurs avec permission d’administration et un autre groupe pour l’helpdesk et d’autres
personnes qui ont les accès à tout, mais en read only.
Ces deux groupes reçoivent des notifications par mail après 600 secondes (5 minutes) d’un senseur en
état « down » et un mail récapitulatif s’il y en a plus de 5, puis un nouveau mail quand le senseur en
question redevient en état up.
Afin d’éviter de recevoir des mails non voulus, l’équipe a décidé de reconfigurer les seuils de certains
senseurs ou même de désactiver les notifications pour certains senseurs ou périphériques :
Windows Update Status
Pagefile
Imprimantes
APC health de l’APC Storage
Supervision des serveurs Linux Si la supervision des serveurs Windows est complète, celle des Linux l’est moins. En effet, certains
serveurs ne sont pas à jours et sont incompatibles avec les senseurs permettant de surveiller leur état
(CPU, Mémoire, espace disque, inodes).
De même, PRTG ne dispose pas de senseurs natifs permettant de surveiller l’état des daemon (services)
Linux, mais dispose d’un script sur le Script World, et d’une autre solution plus simple dans leur base
de connaissance. Il est donc possible de surveiller facilement les daemons Linux grâce à Powershell
(script) ou SNMP, dont l’installation sur les serveurs Linux aurait permis de monitorer aisément chaque
service lié à leur utilisation ainsi que de monitorer d’autres informations plus en détaillées qu’avec
SSH.
Ces deux options ont cependant été refusées par l’équipe, il m’a été demandé de faire deux tâches à
la place :
Attendre que les administrateurs réseau réalisent un « work around » grâce à un script.
Envoyer un mail aux développeurs leur demandant les IP des sites hébergés sur ces serveurs
Linux, et superviser leur état via une requête HTTP basique sur PRTG.
5 Voir annexe 8 : Lookup pour les disques Isilon
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
57 Rapport
La première tâche n’a pas été terminée donc pas implémentée avant la fin de mon stage, et la seconde
ne permet que de vérifier l’état du service Apache, pas des autres services d’un serveur web (base de
données, PHP, …).
Documents annexes
Knowledge base
J’ai réalisé un document6 recensant chaque problème majeur rencontré lors des différentes étapes de
l’implémentation de PRTG ainsi que leur(s) résolution(s).
Configuration des périphériques et procédures
Afin que le personnel ICT de la Bibliothèque royale de Belgique puisse reproduire la configuration
SNMP effectuée par mes soins sur les éléments du réseau, j’ai réalisé un document7 reprenant les
scripts et configurations effectués sur les périphériques disposant d’options configurables.
Ce document contient aussi des procédures afin d’ajouter sans problèmes de nouveaux périphériques
au réseau avec une configuration SNMP complète et des notes utiles en cas de remplacement ou
déménagement de matériel.
Inventaire du monitoring
Comme vu précédemment, j’ai réalisé différents inventaires du monitoring au cours de ce stage,
contenant les éléments à superviser en fonction de chaque solution de monitoring testée et de mes
connaissances du réseau.
J’avais aussi prévu de réaliser un inventaire final sur la solution déployée contenant tous les éléments
supervisés, mais PRTG permettant d’exporter des rapports plus ou moins détaillés (listes avec ou sans
graphique, données, détails, …) des senseurs pour les périphériques ou groupes voulus, j’ai décidé qu’il
serait une perte de temps de recréer manuellement la même chose dans un classeur Excel.
Au lieu de ça, j’ai créé un inventaire8 moins détaillé, mais plus concret. La structure de ce classeur est
basée sur les groupes principaux de la structure créée dans PRTG et comprend :
Les noms et adresses IP de chaque élément supervisé
Des informations utiles (OS, Modèle, Localisation, …)
Les protocoles de supervision utilisés
Le nom de l’utilisateur SNMPv3 ou de la communauté SNMPv2 configuré
Les types de senseurs utilisés (Ex : Disk Free, Load Average et Mem Info sur un serveur Linux)
Une feuille supplémentaire nommée « seuils » contient les senseurs dont nous avons modifié les seuils
ou l’intervalle de scan et leurs valeurs.
6 Voir annexe 6 : Knowledge base 7 Voir annexe 7 : Configuration des périphériques et procédures 8 Voir annexe 9 : Inventaire du monitoring final
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
58 Rapport
Relationnel
Compétences acquises Bien qu’ayant de bonnes compétences dans les technologies utilisées grâce à mes formations scolaires
et personnelles, ce stage, surtout grâce à mes deux collègues administrateurs réseau, a été riche en
expérience.
En effet, disposant de leur expertise et de toutes les ressources et accès de la Bibliothèque, j’ai pu
analyser un réseau d’entreprise de grande taille, y découvrir de nombreux outils d’administrations
système, serveurs, best practices, … Ainsi que littéralement vivre le métier d’administrateur réseau en
partageant leur quotidien, voire en les assistant ponctuellement.
Ledit réseau étant cependant si vaste et comprenant tant de technologies liées à la gestion d’une
bibliothèque qu’il m’a fallu de nombreuses semaines pour m’y habituer.
Relation avec les employés Même si, comme partout, les différents employés ne sont pas toujours d’accord avec les méthodes de
travail des autres et qu’il y a parfois des différends, l’ambiance dans le service ICT de la Bibliothèque
royale de Belgique est très amicale. Tout le monde n’arrive pas à la même heure et ne travaille pas
dans le même bureau voire la même aile, mais nous nous saluons tous chaque matin, voire parlons et
faisons des pauses ensembles.
Il m’a fallu un certain temps d’adaptation à la vie en entreprise, mais je n’ai rencontré aucun problème
de communication avec les autres acteurs de l’entreprise. La communication professionnelle n’est pas
toujours optimale dans le service ICT, mais l’ambiance et la communication amicale l’est toujours.
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
59 Rapport
Suivi du travail J’ai partagé un bureau avec les deux administrateurs réseau : Jonathan Galand, qui s’occupe de la
partie serveur et dont il lui a été assigné la tâche de m’aider, et Yves De Preter, qui s’occupe de la partie
stockage. Il m’était ainsi aisé d’obtenir de l’aide ou des conseils pour la réalisation de mon projet, il me
suffisait de parler ou même de leur envoyer des mails en cas de télétravail d’un de nous trois.
Loin des clichés du stagiaire soumis que l’on isole dans un petit bureau au loin du personnel et qui sera
en charge des photocopies et du café, j’ai eu la chance d’être pleinement intégré au service en étant
perçu, non pas seulement comme un simple stagiaire, mais presque comme un administrateur
système à part entière. Cette position perçue m’a permis de découvrir la vie en entreprise presque
comme un vrai employé : respect de la hiérarchie, les administrateurs système étant mes collègues et
mon maître de stage étant mon chef, qui prend les décisions après discussions avec l’équipe et dont il
faut les respecter, …
En dehors des échanges plus techniques avec les sys admins, il m’était possible de me rendre dans le
bureau de Xavier Delor, mon maître de stage afin d’obtenir de l’aide dans son rôle de manager du
service ICT : Facilités de la Bibliothèque, présence au travail, cahier des charges de mon projet,
discussion quant aux solutions et à leur licensing, …
Une partie des réunions se déroulant toutes les 2 à 3 semaines entre les 2 administrateurs système et
le manager m’était réservée afin que je m’exprime quant à l’avancement de mon projet, voire le
présente. Ces réunions servaient aussi à ce que l’on se prononce sur des éléments à ajouter ou modifier
du cahier des charges, ou à réaliser dans mon projet.
Planification du travail J’ai planifié mon travail grâce à un tableau de bord Trello, partagé avec mon maître de stage. Chaque
liste de celui-ci représente une étape du stage, et chaque carte une tâche spécifique. Dans ces cartes
sont détaillées les différentes tâches sous forme de checklist dont les éléments sont annotés et
commentés au besoin. Ainsi, la liste « Déploiement » contient une carte « SNMPv3 » comprenant, sous
forme de checklist, les divers types de périphériques configurés en SNMPv3. Par exemple, cette carte
contient une checklist « switches » reprenant les switches configurés, éventuellement annotés et/ou
commentés en cas de problème de configuration.
Figure 43 Tableau de bord Trello lors de la dernière semaine de stage
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
60 Rapport
Conclusion À l’occasion de ce stage, j’ai pu découvrir la vie en entreprise et le travail aux côtés d’administrateurs
réseau, observant le quotidien de ce métier. Ce stage m’a apporté énormément d’expérience, tant sur
le plan personnel et humain que professionnel, ce qui constituera un atout majeur pour mon avenir.
Tous les éléments de mon cahier des charges du stage ont été réalisés. Ainsi, j’ai pu réaliser un
inventaire du réseau et des éléments à superviser dès le départ de mon stage. Au terme de diverses
réunions et de ces inventaires, j’ai ensuite rédigé un cahier des charges des « must-have » et « nice-
to-have » tant en termes de programme de monitoring que d’éléments à superviser.
Ce cahier des charges m’a permis de réaliser une étude de marché et de sélectionner plusieurs
solutions à tester :
PRTG
Netcrunch
Nagios XI
Zabbix
En accord avec mes recommandations, l’équipe s’est ensuite prononcée en faveur de PRTG, dont j’ai
réalisé l’installation sur un serveur en choisissant le RAID adapté, puis l’implémentation dans le réseau
en y ajoutant tous les périphériques et éléments à superviser grâce à des senseurs natifs ou pensés et
créés par mes soins dans le cas où les senseurs permettant de monitorer des éléments importants du
réseau n’étaient pas disponibles.
Les possibilités de supervision natives sont tout de même très complètes, et il existe de nombreux
capteurs « avancés » que nous n’avons pas utilisés, mais qu’il pourrait être utile d’implémenter. Parmi
les éléments qu’il pourrait être opportun d’ajouter au monitoring, je peux citer :
Vérification des bases de données à l’aide de requêtes personnalisées
Tests de sites HTTP avancés (connexions, transaction,…)
Supervision des services Linux
Au cours de l’implémentation, j’ai aussi dû rechercher la meilleure méthode de configuration de SNMP,
et configurer ce protocole sur les périphériques l’utilisant.
Afin de fournir toutes les informations utiles à la configuration de PRTG et du monitoring en général à
l’équipe ICT, j’ai aussi réalisé divers documents annexes :
Base de connaissance
Configuration des périphériques et procédures
Inventaire du monitoring (éléments supervisés et comptes SNMP configurés sur chaque
périphérique)
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
61 Rapport
Lexique Acknowledge : Acquitter une alarme.
Node : Un périphérique réseau. En licensing, une node = une adresse IP/FQDN.
Est aussi appelé :
Hosts / hôtes sur Nagios XI
Devices / périphériques sur PRTG
Probe sur PRTG (c’est le serveur hébergeant PRTG)
NRPE : Software disponible sur Nagios XI, permettant de superviser un serveur Linux avec agent.
PDU : Protocol Data Unit, format d’une donnée sur n’importe quelle couche du modèle OSI.
Probe : Un élément supervisé.
Est aussi appelé :
Services sur Nagios XI
Capteurs
Sensors / Senseurs sur PRTG
Sonde
Processus : Programme en cours d’exécution.
Référencement : Terme décrivant l’optimisation d’un site web ou d’un mot clef sur les moteurs de
recherche et les médias sociaux. Il en existe deux types principaux :
SEO : Référencement naturel (optimisation des pages, mots-clefs, liens, visites, …)
SEA : Référencement payant (Argent dépensé sur Google Adwords, dans le cas de Google)
Services : Programme fonctionnant en arrière-plan, daemon Unix.
SI : Système d’information, terme désignant l’entièreté de l’infrastructure d’une entreprise, ses
serveurs, périphériques, logiciels, …
SNMP : Simple Network Management Protocol, protocole universel et standardisé de supervision de
tout périphérique réseau. Les versions actuellement utilisées sont les versions v2c (Les informations
transitent en clair, pas de sécurité, il fonctionne par nom de communauté définissable) et v3
(Fonctionne par authentification, toute la PDU est encryptée).
Les données peuvent être récupérées de deux manières différentes :
Polling : Le serveur envoie les requêtes au client monitoré.
Traping : Le client monitoré envoie les informations au serveur.
SSH : Protocole de connexion sécurisé.
WMI : Protocole de supervision Windows.
xFlow : Nom générique donné par Paessler aux protocoles d’analyse de flux réseau. Parmi eux,
NetFlow (Cisco), sFlow (HP), jFlow (Juniper), IPFIX (standard), …
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
62 Rapport
Bibliographie
Cours MANDOUX D., Connecting networks, Haute École en Hainaut à Mons, Année académique
2017-2018
MANDOUX D., Télécommunications et réseaux 1, Haute École en Hainaut à Mons, Année
académique 2011-2012
Livres Douglas R. Mauro & Kevin J. Schmidt., Essential SNMP, O’Reilly, Sebastopol, 2001
Documents électroniques Hewlett Packard Enterprise Support Center, [en ligne] ;
https://support.hpe.com
How to Install, [en ligne] ;
https://www.howtoinstall.co/
Knowledge base - Paessler, [en ligne] ;
https://kb.paessler.com/
Documentation – EMC Isilon OneFS, [en ligne] ;
http://doc.isilon.com/onefs/8.0.0/help/en-us/
Evilrouters, [en ligne] ;
http://evilrouters.net/
Solarwinds, [en ligne] ;
https://thwack.solarwinds.com
Documentation - Ubuntu, [en ligne] ;
https://doc.ubuntu-fr.org/
Répertoire des plugins - Nagios, [en ligne] ;
https://exchange.nagios.org
Manuel – Paessler, [en ligne] ;
https://www.paessler.com/manuals/prtg
Encyclopédie libre - Wikipedia, [en ligne] ;
https://fr.wikipedia.org/
HEH Catégorie technique Etude de mise en œuvre d’un outil de monitoring Rapport de stage Section informatique Bibliothèque royale de Belgique Thomas Delcampe Année académique 2017-2018
63 Rapport
Annexes
Liste des annexes Annexe 1 : Lettre de motivation Annexe 2 : C.V Annexe 3 : Cahier des charges Annexe 4 : Documentation technique – Plateforme de test Annexe 5 : Documentation technique – Serveur en production Annexe 6 : Knowledge base Annexe 7 : Configuration des périphériques et procédures Annexe 8 : Lookup pour les disques Isilon Annexe 9 : Inventaire du monitoring final