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

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


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


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.


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.


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.


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

…


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.


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


13 Rapport

Organigramme simplifié


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


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


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


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


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


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


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


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


Probes WMI : Infos système et rôles OK Services, processes, Infos systèmes et alertes via logs Windows

Services 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]


20 Rapport

Compte-rendu des tests


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.


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


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, …


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.


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


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


26 Rapport


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


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


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


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


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


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


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


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.


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.



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.


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


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


OSX, OSA OK


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



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


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


Probes : Status des cartes RAID HP OK

Probes : Hyper-V OK Sensors pour l'hôte Hyper-V et chaque VM


Probes WMI : Infos système et rôles OK Services, infos système, alertes via logs Windows, Windows Update,...

Services 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


Interface

Switches

Imprimante [prn-10-36]

VPN Cisco ASA [vpn-srv01]



Serveur DC Windows [dc-srv01]

xFlow



33 Rapport



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


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


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


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.


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)


38 Rapport

Figure 30 PRTG - Proof of concept : VPN Cisco ASA


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


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,


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 »


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)


41 Rapport

Figure 35 PRTG - Proof of concept : Serveur contrôleur de domaine


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, …)


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"


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.


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, …


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


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


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.


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


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


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


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, …


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


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.


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


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


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


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


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.


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


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)


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), …


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/


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

Bachelier en informatique et systèmes Stage en entreprise fileHEH Catégorie technique Etude de...

Documents

Transcript of Bachelier en informatique et systèmes Stage en entreprise fileHEH Catégorie technique Etude de...