Étude de cas : supervision avec OMD (Open Monitoring Distribution)

Étude de cas : supervision avec OMD (Open
Monitoring Distribution)1
Hugo Étiévant
École Normale Supérieure de Lyon
Direction des Systèmes d’Information
15 parvis René Descartes
69342 Lyon Cedex 07
Résumé
OMD (Open Monitoring Distribution) est une distribution dédiée à la supervision qui intègre tous les
outils nécessaires. Elle repose sur l'outil Check_MK qui propose un paradigme différent des outils de
supervision du marché : diminuer la bande passante en exploitant un agent installé côté client, détecter et
inventorier automatiquement les services disponibles sur un hôte, une grande flexibilité dans la
configuration basée sur des règles dynamiques, la délégation de droits.
Nous détaillerons le projet de refonte de la supervision à l'ENS de Lyon. L'aspect humain étant au cœur
des métiers techniques, on verra comment la mise en place de nouveaux outils impacte les procédures de
service et la collaboration entre informaticiens d'une DSI. Un retour d'expérience sera fait sur la base de
deux ans de fonctionnement de la plateforme de supervision de l'ENS de Lyon.
Mots-clefs
OMD, Check_MK, Nagios, supervision, hypervision, métrologie, sonde, gestion de projet, M4P
1 Supervision
La supervision consiste à réaliser une mesure de la disponibilité des services du SI. Ces mesures sont
réalisées à l’aide de sondes qui interrogent les services à distance depuis un serveur de supervision
(supervision active) ou via la collecte réalisée directement par des agents déployés sur les équipements
surveillés (supervision passive). Les problèmes détectés donnent lieu à la levée d’alertes qui sont visibles
par des opérateurs dans une interface de visualisation. Les relevés de disponibilité des services supervisés
permettent de vérifier les niveaux de services contractuels (Service Level Agreement 2). Les chaines de
liaisons entre services permettent d’analyser les causes mères à l’origine des pannes constatées (Root
Cause Analysis3).
Associée à la métrologie système, la supervision permet de faire de la prévision de montée en capacité
(Capacity planning), ce qui en fait un outil d’hypervision. Des tableaux de bord intelligents associés à la
cartographie permettent de superviser les activités métiers avec une granularité de haut niveau (Business
Activity Monitoring).
1
Une version longue de cet article est disponible en ligne : http://cyberzoide.developpez.com/supervision/
Accord de niveau de service. Contrat de qualité de service entre un prestataire et un client fixant un engagement de niveau de
disponibilité pour un service avec d’éventuelles pénalités en cas de non-respect. Par exemple, un niveau de disponibilité de 99%
pour un site web. Dans le cadre de la supervision, une alerte pourra être remontée en cas de non-respect d’un SLA.
3
Le concept de dépendance permet de mieux exprimer la complexité du SI et d’éviter une avalanche de notifications sur des
services défaillants alors qu’une cause racine est en jeu.
2
JRES 2015 - Montpellier
1/13
2 Projet de nouvelle plateforme de supervision
2.1
Description du contexte et de la méthode
Dans le cadre d’une réorganisation institutionnelle 4 (fusion de trois établissements d’enseignement
supérieur et de recherche), nous devions remettre à plat nos outils et mettre en œuvre une nouvelle
plateforme de supervision.
Les outils de supervision antérieurement utilisés étaient : Centreon Standard5 (supervision), Munin6
(métrologie) et What’s Up Gold7 (supervision et métrologie). Ces plateformes étaient obsolètes,
incomplètes et incohérentes avec l’état réel du SI d’où une perte d’efficacité dommageable au
fonctionnement des services parfois critiques de l’établissement.
Le projet a été mené selon les canons du domaine, en suivant la méthode M4P 8 élaborée conjointement
par les membres de l’Université de Lyon9 dont l’ENS de Lyon était acteur.
2.2
Objectifs
Ce projet mené par la DSI consistait à mettre en œuvre une plateforme unique offrant de bonnes
performances en remplacement des divers systèmes de supervision antérieurs.
Les objectifs définis étaient les suivants :
̶
être alerté des incidents avant les utilisateurs
̶
améliorer la réactivité des équipes de la DSI face aux incidents
̶
connaître à chaque instant l’état des serveurs de la DSI
Les bénéfices attendus étaient :
̶
disposer d’une plateforme unique standardisée, gérée par une seule équipe, et offrant des
performances correctes
̶
disposer d’une organisation adaptée : des périmètres bien établis entre les équipes de la DSI
(chacune ayant délégation sur ses serveurs pour en paramétrer la supervision) et également
vis-à-vis d’utilisateurs extérieurs à la DSI qui pourront consulter l’état des services dont ils
dépendent
̶
dans le cadre de l’urbanisation du SI, cet outil permettra d’avoir une vue de l’étendue de
l’infrastructure de serveurs de l’ENS et de les dénombrer plus facilement, il peut aider à la
communication interne
2.3
Acteurs et organisation projet
Une étape préliminaire d’évangélisation des membres de la DSI a permis de rappeler les concepts de la
supervision, et son impact positif sur le travail de chacun.
Les membres de la DSI ont été associés très tôt au projet et ont participé activement à la définition du
périmètre du projet et à la collecte des besoins. Chaque équipe ayant des besoins différents, il était
L’École normale supérieure de Lyon (ENS de Lyon) a été créée à partir de la fusion de l’ENS Lettres et Sciences Humaines et
l’ENS Sciences en janvier 2010. Puis l’Institut national de recherche pédagogique (INRP) a intégré l’ENS de Lyon en décembre
2010.
5
https://www.centreon.com
6
http://munin-monitoring.org
7
http://www.whatsupgold.com
8
Méthode de Pilotage de Projets et de Portefeuille de Projets, voir la documentation : https://m4p.ens-lyon.fr/
9
L’université de Lyon (UdL) est une Communauté d’universités et établissements (Comue) qui fédère onze établissements
d’enseignement supérieur et de recherche de Lyon et Saint-Étienne ainsi que le CNRS. L’ENS de Lyon en est un membre fondateur.
4
JRES 2015 - Montpellier
2/13
indispensable de mettre sur pied une organisation projet adéquate. Ainsi, un correspondant a été désigné
dans chacune des quatre équipes de la DSI10.
De nombreuses réunions ont permis de cerner le périmètre du projet et l’ensemble des besoins des
équipes. Une conciliation finale a permis de borner et de prioriser les besoins selon un schéma classique
MoSCoW11.
2.4
Périmètre et besoins
Le périmètre du projet était le suivant : superviser les équipements, systèmes, bases de données et
applications gérés en propre par la DSI.
Constatant que les plateformes existantes à l’ENS réalisaient de la supervision mais aussi de la
métrologie et considérant que les outils du marché sont duaux, ce projet incluait par extension également
la métrologie (c’est-à-dire l’historique d’indicateurs numériques avec représentation graphique). Il
s’agissait de métrologie de caractéristiques systèmes et non pas de la métrologie de flux réseaux.
Étaient inclus dans le périmètre : tous les serveurs physiques et virtuels, les applications métiers, les
SGBD, les sites web, les équipements de stockage (SAN), les infrastructures de virtualisation et les
équipements réseaux (routeurs, switches, bornes wifi, liaisons laser et radio), les sondes de température
des salles serveurs et certains onduleurs.
2.5
Choix de la solution
Le choix de la solution a été un processus long et rigoureux qui a amené à réaliser une étude de marché
(43 outils recensés), puis à les filtrer en fonction de critères objectifs (prix, licence libre, ancienneté et
activité du projet) et à les confronter à nos besoins fonctionnels particuliers (58 items après une étude de
besoins au sein de la DSI).
Les meilleurs outils sélectionnés ont d’abord été Shinken et Icinga, tous deux compatibles avec
l’écosystème Nagios. Nous avons donc réalisé deux maquettes sur la base de ces deux ordonnanceurs,
associés avec deux solutions d’interfaces web : Shinken/Check_MK et Icinga/Truck.
Les deux maquettes ont été testées par la DSI sur une période d’un mois à l’aide d’un plan de tests
incluant des scénarios basiques.
Un besoin fort exprimé par la direction de la DSI était la possibilité d’une délégation maximale auprès des
personnels de la DSI dans l’utilisation et le paramétrage de l’outil de supervision. Dans cette optique
d’autonomie des personnels, c’est Check_MK qui offrait la meilleure interface et la meilleure
productivité. Si on s’était placé dans l’optique d’une centralisation de la configuration par un seul
administrateur et d’un haut niveau technique de personnalisation de la configuration, alors nous aurions
préféré Thruk. Quant aux solutions de base : Shinken et Icinga elles étaient assez comparables, compte
tenu de nos besoins.
La DSI a donc fait le choix du couple Shinken/Check_MK, deux projets complémentaires développés en
Python.
Il s’est avéré au cours du projet que la problématique du choix de la solution de supervision est en
fait une problématique d’intégration d’outils (reporting, cartographie, métrologie, BAM, interfaces
web…) et de sondes. En effet, l’écosystème autour de Nagios est foisonnant et nécessite un travail
d’analyse aussi important que le choix de la solution de supervision brute.
La DSI de l’ENS de Lyon est organisée en cinq équipes : SRS (Systèmes, Réseau et Sécurité), SGP (Service de Gestion de Parc et
assistance aux utilisateurs), Appli (Applications métiers et bases de données du SI), TICE (Technologies de l'information et de la
communication pour l'enseignement), PIL (Pôle Informatique de Laboratoire).
11
Méthode permettant d’exprimer facilement la priorisation des besoins en utilisant les modaux de langue anglaise : must, should,
could, won’t.
10
JRES 2015 - Montpellier
3/13
L’étude ayant initialement porté sur les superviseurs, s’est rapidement étendue sur l’ensemble de
l’écosystème. Deux thèmes ont été particulièrement approfondis : la métrologie et la génération de
graphes, ainsi que les interfaces de visualisation et d’administration nécessaires pour garantir l’autonomie
des opérateurs.
Le travail d’intégration des outils pour former une plateforme homogène a été relativement important.
2.6
Procédures et usages
Le test des maquettes a été l’occasion de l’élaboration d’un plan de formation à destination des membres
de la DSI.
L’autonomie des opérateurs pouvant représenter un risque si elle n’est pas maîtrisée, des procédures
précises d’usage de la plateforme ont été conçues en concertation.
2.7
Reprise de l’existant
Un des besoins forts était la reprise des données : la liste des serveurs et services déjà supervisés devait
être reprise sur la nouvelle plateforme sans avoir à tout ressaisir. Dans un premier temps, l’ensemble des
hôtes a été repris à l’aide de scripts, certains services de base automatiquement inventoriés et un travail de
vérification manuelle a été entrepris collectivement.
Ensuite, un lourd travail d’inventaire des hôtes et services manquants a été réalisé par toutes les équipes
afin de compléter les données de la nouvelle plateforme et refléter la réalité du SI.
3 Plateforme technique et son évolution
La plateforme installée initialement repose sur le couple Shinken/Check_MK :
̶
serveur physique costaud
̶
système d’exploitation Debian 7.1
̶
superviseur Shinken 1.2.4
̶
plugins Nagios (paquet nagios-plugins)
̶
interface Check_MK 1.2.2p2 + Livestatus + BULK Mode with NPCD
̶
génération de graphiques PNP4Nagios 0.6.19 + RRDcacheD
̶
cartographie NagVis 1.7.1
̶
NRPE
Chacun de ces composants a été installé et configuré séparément, mais dans l’optique de fonctionner
ensemble. Le travail d’intégration a été important (18 jours-hommes de préparation des deux maquettes et
6 jours-homme d’installation de la plateforme de production).
Après un an de vie, et après plusieurs mises à niveau logicielles successives, nous avons été confrontés à
la difficulté de maintenir cette architecture complexe. Le coût d’exploitation s’est révélé être assez élevé
et les performances parfois dégradées sur certaines opérations (statistiques et historiques d’alertes). De
plus, des fuites mémoires et bugs Python rendaient parfois notre plateforme instable.
Nous avons alors décidé de nous orienter vers un choix d’intégration différent, sans changer nos choix
fonctionnels et sans perdre notre configuration ainsi que nos données.
Nous avons donc migré vers la distribution OMD qui fournit notamment Shinken et Check_MK ainsi que
tout l’écosystème que nous connaissions déjà.
Par ailleurs, le superviseur Shinken a malheureusement évolué de façon à devenir incompatible avec notre
écosystème Nagios, ce qui nous a amené à un choix drastique : le remplacer par l’original, Nagios.
À ce jour, notre plateforme repose sur les outils suivants :
JRES 2015 - Montpellier
4/13
̶
Debian 7.1
̶
NRPE
̶
OMD 1.21
̶
Nagios Core 3.5.0
̶
Check_MK 1.2.4p5
̶
NPCD 0.6.24
̶
RRDtool 1.4.8 + RRDcacheD 1.4.8
̶
PNP4Nagios 0.6.24
̶
NagVis 1.8
̶
plugins Nagios (paquet nagios-plugins)
4 OMD
OMD12 (Open Monitoring Distribution) est une distribution 13 dédiée à la supervision. OMD intègre tous
les outils nécessaires : ordonnanceur, interface web utilisateur et administrateur, interface mobile, outil de
métrologie système, wiki, gestion de tickets, outil de cartographie. OMD est compatible avec
l'écosystème Nagios, elle représente une étape de plus dans l'évolution des outils de supervision, se
rapprochant de l’hypervision. Outre l’intégration des outils dans une seule distribution, OMD simplifie le
déploiement d’instances différentes afin de superviser différentes entités14. Ces outils ont été optimisés
pour une meilleure efficacité avec notamment le module NPCD15, le cache RRD16, un volume TMPFS17
pour les résultats de sondes et un frontal web qui réduit les accès disques.
Le rythme des sorties de mises à jour stables est d’une à deux par an. Elle intègre les dernières versions
des outils intégrés. Des compilations quotidiennes sont également disponibles, mais pas exemptes de bug.
OMD est avantageuse pour qui souhaite une plateforme de supervision complète et performante à
moindre coût.
Le schéma d’architecture montré en Figure 1 explicite l’intégration des différents composants de la
distribution.
12
http://omdistro.org
Le terme « distribution » sur lequel communique OMD ne s’emploi pas ici au sens « distribution Linux », mais plutôt sous le sens
d’un package Linux incluant divers outils fortement intégrés entre eux.
14
Cette fonctionnalité est particulièrement pratique lorsqu’on vend par ailleurs des prestations d’hébergement de solution de
supervision, comme le fait l’éditeur de Check_MK.
15
Nagios-Perfdata-C-Daemon : ce programme fournit un mode asynchrone dans le traitement des données de performance de
Nagios, ce qui en améliore les performances notamment pour les plateformes gérant un grand nombre d’hôtes et de services.
16
Round-Robin database : système de base de données de taille fixe réalisant la sauvegarde de données cycliques issues du
monitoring de services. Le cache RRDcached est un programme qui intercepte et place en mémoire les données avant écriture dans
les bases RRD afin de soulager les performances d’accès disque.
17
Temporary File System : système de fichier temporaire dont les données sont stockées en mémoire et non sur un support disque
physique afin de soulager là encore les performances du serveur.
13
JRES 2015 - Montpellier
5/13
Figure 1
Le déploiement d’OMD en remplacement de notre architecture a résolu les problèmes de performances
nés de notre volonté initiale de maîtriser l’intégration de tous les outils. De ces bienfaits résulte une
meilleure expérience utilisateur pour les opérateurs de la plateforme.
5 Check_MK
5.1
Présentation
Check_MK18 est un composant essentiel de OMD. C’est une surcouche de l’outil de supervision Nagios
(et de ses forks). Il propose une interface web de consultation (Multisite) et une interface web
d’administration (WATO). La configuration de Check_MK est stockée dans des fichiers de configuration
sous un format spécifique (mais lisible). Elle est traduite et poussée à destination de Nagios. Check_MK
pilote le démarrage et le rechargement de la configuration de Nagios.
Il propose un paradigme différent des outils de supervision du marché : diminuer la bande passante
utilisée en exploitant une super sonde passive installée côté client, détecter et inventorier
automatiquement les services disponibles sur un hôte, une grande flexibilité dans la configuration basée
sur des règles dynamiques, la délégation de droits.
Il est capable d’interroger les nœuds soit avec l’aide d’un agent local à déployer ou via SNMP. Il propose
un module Livestatus capable d’interfacer directement le cœur de Nagios pour consulter l’état de la
supervision.
Il simplifie la délégation de droits au sein d’une DSI pour la configuration de la supervision. L’interface
d’administration permet de ne pas avoir à éditer directement les fichiers de configuration.
18
http://mathias-kettner.com/check_mk.html
JRES 2015 - Montpellier
6/13
5.2
Mécanismes de supervision active et passive
Le schéma Figure 2 illustre les méthodes les plus couramment employées pour superviser un service.
Figure 2
Le schéma Figure 3 détaille le fonctionnement de Check_MK :
Figure 3
Check_MK est capable de réaliser un inventaire automatique des services disponibles sur un hôte à
superviser. Si un service est inconnu de Check_MK, il est possible de l’enrichir via un système de greffon
et de le packager pour le partager sur une plateforme communautaire 19. L’inventorisation fonctionne soit
19
Check_MK Exchange : http://mathias-kettner.com/check_mk_exchange.php
JRES 2015 - Montpellier
7/13
via le protocole SNMP par la détection d’OID 20 connus pour les équipements de type boite noire, ou bien
via l’utilisation d’un agent à déployer sur l’hôte pour les serveurs Linux et Windows.
En dehors de ce mécanisme intégré à Check_MK, il est possible d’utiliser les sondes compatibles avec
Nagios. Cette compatibilité facilite grandement le travail des opérateurs qui n’ont pas besoin de
redévelopper des sondes.
Les sondes exploitant le protocole NRPE21 de Nagios qui permettent de réaliser la supervision passive en
déployant directement une sonde sur l’hôte à superviser peuvent également être utilisées avec Check_MK
qui dispose d’un composant MRPE22 équivalent. L’hôte héberge alors un agent Check_MK ou tout autre
agent compatible NRPE comme par exemple NSClient++23.
5.3
Configuration basée sur les règles
Les hôtes (« host ») à superviser sont organisés en dossiers (« folder ») organisés hiérarchiquement. Les
dossiers sont caractérisés par un nom (« name »), un parent (« parent ») et des étiquettes (« host tags ») et
sont associés à des groupes de contacts (« permissions »). Les hôtes disposent des mêmes caractéristiques
(en plus d’une adresse IP) et héritent par défaut de celles du dossier qui les héberge.
Le paramétrage de la supervision et l’utilisation de sondes sur un ou des hôtes sont basés sur des règles de
configuration (« Rule-Based Configuration »). Une règle est régie par ses conditions d’application et son
paramétrage. Les conditions d’application déterminent son périmètre d’action, c'est-à-dire les hôtes sur
lesquelles elle va s’appliquer. Tout comme un hôte, une règle est classée dans un dossier. Les sousdossiers héritent des règles des dossiers parents. Les hôtes rangés dans un dossier subissent les règles
s’appliquant à ce dossier. Les conditions peuvent être : explicites (liste déterminée d’un ou plusieurs hôtes
dont le nom est spécifié) ou dynamiques via des étiquettes (le périmètre d’application est calculé
automatiquement en fonction des étiquettes). Le paramétrage permet de moduler le comportement de la
sonde et de ses seuils d’alertes. Ce modèle de configuration basé sur des règles est très puissant et permet
d’appliquer une même configuration à de multiples hôtes en un seul clic.
La Figure 4 ci-dessous, montre le fonctionnement du module de règles dynamiques proposé par
Check_MK :
Object Identifier : identifiant unique d’une ressource présentée par un agent SNMP et stockant une information relative à l’état de
l’équipement consulté.
21
Nagios Remote Plugin Executor
22
MK's Remote Plugin Executor
23
https://www.nsclient.org
20
JRES 2015 - Montpellier
8/13
Figure 4
Notre plateforme utilise actuellement près de 270 règles dont 70 liées à des sondes Nagios externes.
5.4
Utilisateurs et rôles
La possibilité de gérer un grand nombre d’utilisateurs ayant des rôles différents est une autre
fonctionnalité intéressante, dans un mode de fonctionnement collectif. Chaque fonction de Check_MK est
liée à une capacité qui peut être attribuée ou refusée à un rôle. Les utilisateurs peuvent se voir attribuer un
rôle particulier et être associés à un ou des dossiers via des groupes de contacts. La flexibilité permet à un
groupe de réunir des utilisateurs ayant des rôles différents. Les utilisateurs ne voient que les hôtes
rattachés aux dossiers liés aux groupes dont ils sont membres.
Grâce au modèle de permissions de Check_MK, nous avons pu donner accès à notre plateforme de
supervision à un public très large, tout en n’attribuant que les droits nécessaires à leurs missions.
5.5
Interface web
L’interface web de consultation de Check_MK est appelée Multisite (« multi » car elle permet la
consultation d’une configuration distribuée sur plusieurs serveurs de supervision).
Cette interface présente un tableau de bord (« dashboard ») en page d’accueil avec la liste des alertes en
cours. Une barre permanente propose un synopsis de l’état de la supervision avec une granularité haute.
Un moteur de recherche permet de retrouver un hôte ou un service.
Multisite permet de personnaliser les vues pré-définies et d’en créer entièrement de nouvelles. Cette
personnalisation est réalisée dans l'interface web, en combinant sources de données (services, hôtes,
évènements, groupes…), modèles, filtres, tris, regroupements, et liens hypertextes vers d’autres vues. La
flexibilité et la simplicité sont les maîtres mots de cette interface. Les composants de l’interface peuvent
être étendus via Python en utilisant des greffons.
Un filtre avancé permet de restreindre les éléments affichés en fonction d’un grand nombre de critères
comme le dossier, les étiquettes, l’appartenance à un groupe, le type de sonde utilisée, etc.
JRES 2015 - Montpellier
9/13
La combinaison de la personnalisation des vues et des filtres est très puissante et permet de ne présenter à
l’écran que l’information recherchée sans qu’elle soit noyée dans la masse. Les pages résultantes peuvent
faire l’objet d’un marque-page pour être retrouvées instantanément.
L’ergonomie du Multisite a beaucoup contribué à l’adoption de Check_MK par les utilisateurs.
L’interface web d’administration WATO (Web Administration TOol) intégrée à Multisite permet de
réaliser entièrement le paramétrage de Check_MK sans avoir à mettre le nez dans les fichiers de
configuration.
5.6
Alertes
Les sondes peuvent retourner un état évalué explicitement (le service fonctionne ou pas) ou bien renvoyer
une valeur numérique qu’il convient d’évaluer en fonction du contexte (par exemple : tel pourcentage de
stockage occupé). Dans ce dernier cas, il faut paramétrer les seuils d’alertes (valeurs WARN et CRIT)
permettant de fixer le statut du test en fonction des valeurs constatées. Certaines sondes peuvent proposer
des modèles de fixation des seuils d’alertes assez complexes, qu’il convient de tester finement avant de
mettre en production. Estimer le bon seuil en fonction du service et de l’hôte est un art difficile, le résultat
final résulte souvent de tâtonnements. La chasse aux faux positifs est une tâche importante lors de la mise
en production d’une plateforme de supervision.
Les alertes sont visualisées sur l’interface web de consultation de la supervision (Multisite), les vues
peuvent être personnalisées pour générer une alerte sonore dans le navigateur. D’autres méthodes d’alerte
sont disponibles : les notifications par mail ou l’installation d’un client lourd sur le poste de travail.
5.7
Client Nagstamon
Nagstamon24 est un client lourd multiplateforme pour Nagios, compatible avec l’API 25 de Check_MK.
Inspiré du greffon « Nagios Checker » pour Firefox, il sur-imprime à l’écran les alertes et propose
également un signal sonore.
Très utilisé dans nos équipes, il respecte les permissions des utilisateurs, permet un certain niveau de
filtrage dans les résultats et le déclenchement d’actions utilisateur. C’est une alternative crédible pour les
opérateurs n’ayant pas le profil administrateur. Cet outil simple a été largement adopté à la DSI et
également mis en place auprès d’équipes externes.
Figure 5 - exemple d'interface avec Nagstamon
5.8
Monitoring et graphes
Le monitoring permet la génération de graphiques représentant l’évolution de valeurs que certaines
sondes mesurent. Ces graphes ont plusieurs bénéfices :
̶
24
25
La représentation visuelle de l’évolution d’une valeur (charge CPU, température) est plus
parlante qu’un état sans historique.
https://nagstamon.ifw-dresden.de/
Check_Mk fournit un service web REST permettant d’interroger Multisite
JRES 2015 - Montpellier
10/13
5.9
̶
L’évolution sur le court et long terme permet intuitivement de réaliser du Capacity
Planning et donc de provisionner l’ajout de ressources sur un serveur.
̶
L’utilisation conjointe de NPCD et de RDDcacheD introduit un retard de quelques minutes
dans l’apparition des données dans les graphes générés par pnp4nagios, dans la pratique
cela ne s’est pas montré préjudiciable.
̶
L’affichage des seuils d’alertes dans les graphes permet de se représenter les évènements
ayant générés des alertes et évite la consultation des historiques.
̶
Les trous qui apparaissent dans les graphes représentent les interruptions réseaux et
électriques, ce qui nous a aidé a posteriori à mieux cerner les plages horaires des pannes
subies, en complément des historiques d’évènements.
̶
La faculté de représenter plusieurs courbes sur le même graphe permet d’associer des
données présentant une similitude en un seul coup d’œil et évite de naviguer dans plusieurs
pages.
̶
PNP4Nagios permet de représenter les données sur de multiples échelles de temps et de
zoomer sur une plage de temps personnalisée, cette fonctionnalité est très plébiscitée.
Notification
Check_MK dispose d’un puissant système de notification. Les notifications peuvent être envoyées par
mail en texte brut ou HTML enrichi, y compris avec des graphes ou par SMS. Tout changement de
paramétrage est immédiatement pris en compte sans redémarrage.
Chaque utilisateur peut paramétrer la façon dont il va recevoir des notifications, grâce à l’usage de filtres
limitant les changements états, les hôtes et les services pour lesquels il veut être notifié ainsi que les
périodes de temps (« timeperiod ») de réception. Il peut paramétrer plusieurs méthodes distinctes de
notification simultanées selon ses besoins.
Ce mode d’alerte est particulièrement indiqué pour les anomalies requérant une information immédiate
d’un opérateur dont l’organisation du poste de travail privilégie la messagerie au détriment des
applications et du navigateur.
Pour éviter les tempêtes de mails, les notifications sont désactivées au global et ne sont activées qu’au cas
par cas pour des besoins très spécifiques.
6 Retour d’expérience
Notre plateforme est utilisée au quotidien par 20 personnes au sein de la DSI, 2 personnes en
bibliothèque, 2 équipes de la sécurité, et 3 personnes en informatique de laboratoire. Elle a rapidement été
adoptée et plébiscité par ses utilisateurs à l’issu d’un cycle de formation interne.
Nos indicateurs26 : nous supervisons 830 hôtes et 9160 services au sein d’une entité (une seule instance
OMD).
Le fonctionnement de Check_MK basé sur les règles a poussé à l’organisation suivante : classement des
hôtes en grands dossiers et spécialisation par étiquettes. Quelques groupes d’hôtes et de services
complètent le dispositif.
6.1
Intégration au SI
Le serveur de supervision est installé selon les normes de la DSI (OS Debian, puppetisation 27,
administration par clés SSH, etc.) et administré par l’équipe système et réseau.
26
27
A l’écriture de cet article le 10 septembre 2015.
Puppet (https://puppetlabs.com/) est un outil de gestion centralisée de la configuration de serveurs
JRES 2015 - Montpellier
11/13
Un serveur de test permet de tester les nouveaux plugins, les changements de configuration système et les
changements impactant fortement la configuration applicative de OMD.
Initialement, les comptes utilisateurs de connexion à l’interface web de la plateforme de supervision
étaient personnels et l’authentification déléguée à l’annuaire LDAP de l’établissement. Nous avons fait
machine arrière et créé un compte par équipe. En effet, en raison de contraintes de service, en cas
d’absence d’un agent, une autre personne, au sein de la même équipe, doit pouvoir réaliser les mêmes
opérations et donc avoir la même interface personnalisée et les mêmes bookmarks. De plus, en cas de
panne, la dépendance de la supervision à l’annuaire LDAP risquait de compliquer l’accès à la supervision.
6.2
6.2.1
Procédures d’usage
Bonnes pratiques
Un ensemble de bonnes pratiques a été élaboré conjointement pour aider les opérateurs à utiliser au mieux
la plateforme :
̶
Inventaire automatisé : ne pas superviser systématiquement tous les services découverts
mais uniquement ceux pertinents
̶
Règles : positionner les règles au plus près des feuilles de l’arbre des dossiers et spécifier
les conditions d’application les plus strictes possible via les étiquettes
̶
Sondes : appliquer le meilleur paramétrage afin de tester les cas courants d’erreurs et tester
la sonde avant de la déployer en production
̶
Alertes : paramétrer des niveaux d’alertes légitimes et raisonnables afin d’être informé des
problèmes pertinents sans surcharger l’interface des opérateurs d’alertes insignifiantes
̶
Permissions : appliquer des permissions utilisateurs adéquates sur les dossiers et les hôtes et
veiller à limiter les intersections de périmètre entre équipes
̶
Conventions de nommage : des normes de nommage des nœuds permettent de normaliser le
contenu des données
̶
Commentaires : les opérateurs commentent les règles créées et les acquittements envoyés
̶
Administration : seul un petit groupe d’administrateurs peut intervenir sur le système de la
plateforme, la mettre à niveau, réaliser des restaurations et modifier les permissions
utilisateurs
Toute intervention majeure doit respecter la règle des « 3 C » : Conception
Communication.
6.2.2
+ Concertation
+
Cycle de vie
La plateforme est vivante et accueille sans cesse de nouveaux hôtes, tandis que d’autres disparaissent,
alors que certains voient leurs applications et leurs spécifications changer. Il est donc nécessaire de gérer
au quotidien le cycle de vie : naissance, évolution et mort des hôtes supervisés. C’est le pôle Système
administrant de la plateforme de supervision qui gère cet aspect-là. Les autres équipes gèrent l’évolution
du paramétrage de la supervision des services et des hôtes qui les intéressent. Pour chaque hôte, une seule
équipe est responsable de sa supervision. Cette séparation des rôles permet aux équipes de travailler en
bonne intelligence.
6.3
Bilan humain
L’association très tôt dans le projet de toutes les équipes a permis à tous de se sentir concernés par le
projet. La réelle prise en compte des besoins spécifiques de chaque équipe et la désignation d’un
correspondant du projet dans chacune d’elle a été le moyen de créer une émulation positive pour la bonne
marche du projet. L’écoute attentive des retours d’expériences suite au test des maquettes a permis
d’éviter des sorties de route dommageables. Ce projet a mis les membres de la DSI au cœur du projet.
JRES 2015 - Montpellier
12/13
M4P fourni un cadre de référence pour la gestion de projet et des documents types qui sont une aide
précieuse pour le chef de projet. Le respect de la méthode M4P et l’attention portée aux aspects humains
du projet ont été un gage de réussite. Les retours des équipes sont positifs et les opérateurs ont pleinement
pris en main le dispositif.
7 Conclusion
Check_MK est un produit très intéressant qui répond bien au besoin d’une autonomie de multiples acteurs
concernés par la supervision au sein d’une DSI et est adapté aux grosses entités. OMD est une distribution
performante proposant une intégration réussie d’un écosystème complet dédié à la supervision.
La gestion de l’exploitation des systèmes et des applications étant au cœur des métiers des différentes
équipes d’une DSI, la supervision n’est pas qu’une problématique technique, c’est aussi un défi
organisationnel. Le soin apporté dans la gestion d’un projet de mise en place d’une plateforme de
supervision et le respect d’une méthodologie rigoureuse permettent d’éviter de nombreux écueils et est
gage de succès.
Tout projet a une fin mais la gestion opérationnelle de la plateforme continue et connaitra d’autres
évolutions avec l’intégration de nouveaux composants et des mises à niveau logicielles…
Bibliographie
1. Pourquoi superviser ? Brand-Foissac, Olivier. Marseille : Mathrice/CNRS, 2009.
2. Supervision, monitoring, métrologie, capacity planning à la sauce Open Source. [En ligne]
Communauté Francophone de la Supervision Libre. http://www.monitoring-fr.org/.
3. Kettner, Mathias. Check_MK. Check_MK. [En ligne] [Citation : 1 10 2015.] http://mathiaskettner.com/check_mk.html.
JRES 2015 - Montpellier
13/13