CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA1 Monitoring interne aux sites Christine Leroy (CEA/DAPNIA) Sylvain Garrigues (LAPP/IN2P3)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA2 plan Pourquoi les outils de monitoring Bilan des outils utilisés sur les sites EGEE Deux exemples: –Lemon –Nagios + Cacti Conclusions

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA3 Un logiciel dit de “monitoring” doit permettre de remplir ces objectifs : –prévenir les incidents par extrapolation des données fournies, –agir rapidement dès qu'un système est noté en erreur, –permettre l'analyse “post mortem” d'un problème grâce aux informations collectées. objectifs

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA4 objectifs

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA5 Questionnaire au sysadmin des sites EGEE - Questions liées aux outils : –Outils graphique –Alarmes (O/N) –Comment sont testés les services? –facilité de prise en main –Licence, gratuité –Avantages/Inconvénients - Questions liées aux sites –Le site est-il monitoré –Quels sont les plans futurs –Monitorer quoi ?

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA6 Résumé des outils utilisés sur les sites EGEE

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA7 Résumé des outils utilisés sur les sites EGEE

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA8 Résumé des outils utilisés sur les sites EGEE

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA9 Résumé des outils utilisés sur les sites EGEE

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA10 Lemon Christine Leroy À partir des slides de Miroslav Siket, Dennis Waldron, Murthy Chandragir and Rotishva Sharma. CERN-IT/FIO-FD.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA11 Plan Fonctionnalités Structure Métriques Alarmes Visualisation Web Installation

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA12 Lemon – LHC Era Monitoring Lemon ( est un système de monitoring client/serveur actuellement disponible pour Linux et Solarishttp://cern.ch/lemon Lemon fait partie de la boite à outils ELFms ( comme quattor et LEAF (avec lesquels il n’a aucune dépendance)ELFmsquattorLEAF Fonctionnalités de Lemon: –Système de monitoring distribué jusqu’à ~10k machines et 500 métriques –Monitoring software, Hardware, DB, VO jobs –Interface WEB –Facilite la détection d’erreur et la prévention de problèmes –Exécute des actions correctives et envoie des notifications –Les données de monitoring sont stockées de façon pérennes. –Offre un Framework pour la création de nouvelles sondes. –Système d’alarmes (avec Oracle) –GridIce est basé sur lemon

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA13 Lemon - composants Lemon contient les composants: –Sensors (Sondes : une sonde est capable de mesurer un ensemble de métriques). –MSA (Monitoring Sensor Agent - edg-fmon-agent: l'agent est responsable du lancement et de la configuration des sondes, du scheduling des mesures et de collecter les valeurs de chaque métrique à un temps T). –Monitoring Repository (un daemon qui reçoit les métriques) –Monitoring Repository Backend (stockage) –LRF (Lemon RRD tool Framework – outil de caching et de présentation web) –Correlation Engines (permet à l’administrateur de définir un ensemble de règles qui seront exécutées par le système. Ces règles déterminent les conditions d’exceptions et décrivent les actions à exécuter). –Lemon Client (outil pour récupérer les données) –LAS (Lemon Alarm System – Génération d’alarmes) –lemon-host-check pour vérifier l’état des exceptions sur les machines, permet enabling/disabling des alarmes/exceptions

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA14 Lemon - schema Correlation Engines Web browser Lemon CLI User Monitoring Repository TCP/UDP SOAP Repository backend SQL Nodes Monitoring Agent Sensor RRDTool / PHP apache HTTP Sur chacun des nœuds monitorés, un agent de monitoring communique avec des sondes qui mesurent un ensemble de métriques. Ces mesures sont conservées en cache sur la machine cliente et transférées au repository central. Ce repository peut utiliser une base de données pour stocker les données de monitoring ou des flat files. Pour visualiser les données il existe une interface web graphique qui utilise PHP et RRDTool: les données du Repository sont récupérées via une application Python et stockées dans rrd, par nœud, par cluster ou par services.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA15 Sensor (MS) et Sensor Agent (MSA) MSA est le cœur du système de monitoring, ce processus tourne sur chaque nœud surveillé, il a pour tache de déclencher et collecter les mesures des sondes (sensor) et les transmettre au Repository (MR) MSA contrôle la fréquence et l’état des sondes L’état de l’agent MSA est loggé dans le fichier /var/log/edg-fmon- agent.log file sur chaque machine. Possibilité d’écrire ses propres sondes (bash, c++, perl,…) une sonde peut avoir le code pour mesurer la métrique : ‘% d’espace disque libre’, si il y a plusieurs disques à monitorer, une instance de la métrique est nécessaire pour chaque disque.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA16 métriques M é triques mesur ée s (environ 500): –Etats: OS, disk DMA, RPM ok?, ethlink,… –Daemons: sshd, ntpd, syslogd, … alive –Taille des fichiers: /etc/nologin, /afs/cern.ch,… –Sécurité: sshd md5chksum,… –Performance: Utilisation CPU, utilisation de la mémoire, bande passante réseau utilisée,… –Divers: nombre de jobs par VO, température,… (

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA17 Copy d’ecran

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA18

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA19 Alarmes Automatic Recovery Action –Pour des valeurs définies de métriques un “actuator” peut être appelé avec des actions prédéfinies –Exemple: ssh daemon dead – action /sbin/service sshd start –Définition: métrique X, champs Y valeur référence Z => appel de l’actuator peut être ==,,regexp, range, etc.. En cas de succès l’action est loggée, sinon l’action est exécutée jusqu’à un nombre de fois égal à max –Chaque occurrence est loggé dans le Monitoring Repository Lemon Alarm System –Actuellement en production au CERN, nécessite Oracle ou Oracle XE (gratuit mais limité à 4GB => historique des données pour 100 machines = 100 jours):

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA20 Visualisation Web LRF est utilisé pour récupérer depuis le MR (Monitoring Repository) les métriques mesurées, et les stocker en fichier rrd sur le disque pour être visualisées rapidement. RRD est l’acronyme de Round Robin Database : RRD est un système pour stocker et visualiser des données temps-séries (bande passante réseaux, charge CPU…). Les données stockées sont compactes et ne risquent pas d’augmenter au cours du temps. Les machines sont groupées par : –Définition CDB [configuration database] –Cluster : l’administrateur peut définir ses clusters –Type de Hardware –Racks L’interface Web est écrite en PHP, elle permet le display des données et une vue générale.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA21

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA22

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA23

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA24

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA25 Installation / tutorial L’installation de Lemon se fait en trois étapes: 1.Installation du Serveur 2.Installation du Client 3.Installation de l’interface Web instructions: Installation avec Quattor Tutorial 9 Oct 2006:

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA26 Nagios + Cacti La supervision au LAPP Sylvain Garrigues (LAPP/IN2P3)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA27 Rappel (rapide) sur Nagios Projet GNU GPLv2 : gratuit et ouvert (Unix/Linux) Supervision services réseau (Ping, telnet, SSH, LDAP, DNS…) Autres « métriques » locales (CPU, disques…) par installation de sondes sur les serveurs (Windows/Unix) : –NRPE (Nagios Remote Process Execution) : Nagios commande au NRPE du client d’exécuter localement une commande et récupère le résultat –NCSA (Nagios Client Check Acceptor) : Le plugin envoie le résultat de commandes locales (i.e. : crontab) pour alerter Nagios Alertes (mail, pager, WinPopup, sms etc…) Adapté pour réseaux petits/moyens/gros jusqu’à plusieurs milliers de métriques : processus assez léger, archi. distribuée possible Gestion des dépendances/hiérarchie (ex : si un switch ne répond plus, l’état du matériel connecté dessus n’est pas HS mais inconnu)  X alertes liées à 1 problème

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA28 Rappel (rapide) sur Nagios (2) Couplé avec serveur Web + CGIs (consultation, gestion, édition rapports etc…) Historique peut être couplé avec BDD (PgSQL/MySQL) ou non (« logs » pour une installation + légère) Configuration par fichiers texte –Beaucoup d’options  complexe au début –Utilisation de modèles (« templates ») pour structurer (i.e. : modèles switch/Windows/Unix/imprimantes/…) –Séparation des droits par utilisateur (i.e. : contacts ≠ suivant le matériel/modèle) Au final, plutôt pratique et puissant… après quelques heures d’investissement (lire la doc!)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA29 Pourquoi Nagios ? Choix de Nagios au LAPP guidé par : –Supervision réseau sans installation sur les matériels (ex : SSH, Ping, DHCP, DNS, LDAP, HTTP, valeurs SNMP…) –Possibilité de surveiller de nombreux paramètres sur systèmes Windows/Unix…grâce aux nombreux plugins disponibles (cf. site Nagios Exchange) –Création aisée de nouveaux scripts (batch, perl, …) pour adapter aux besoins particuliers –Alertes notamment par mail et Popup Windows –Présence d’une carte du site supervisé –Plutôt léger (Au LAPP : « petite » machine virtuelle Linux) –Création de rapports et historiques –Accès avec privilèges

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA30 Schéma simplifié du comportement de Nagios lors du passage d’un service de l’état up à down: NB : Le passage de l’état down à up suit la même logique. yes noyes no Comment fonctionne Nagios ? (1) check service x (host y) service is alive ? wait Foreach (service, host) : wait check host y host is alive ? Host_counter : max reached ? Service Down Alert Service_counter : max reached ? Host Down Alert wait (Explication du schéma page suivante)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA31 Comment fonctionne Nagios ? (2) On déclare des machines et leurs services à surveiller (Ping, SSH, etc…). Nagios supervise chaque service en tentant une connexion toutes les n minutes (n paramétrable par service/machine). Si un service ne répond pas, Nagios vérifie si la machine (« host ») répond au ping : il détermine ainsi si le problème est situé sur ce service en particulier ou s’il s’agit d’un problème général de l’hôte. Nagios teste le service m fois (m paramétrable, >1 pour éviter les fausses alertes) avant d’entrer dans la phase d’alerte. En fonction des règles définies (type d’alerte, contact, service critique ou non, heure de l’alerte…) Nagios émet ou non une alerte concernant l’hôte et/ou le service en cause. Nagios peut également être paramétré pour effectuer des actions correctives (commande, redémarrage de service etc…).

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA32 Mise en situation : exemple d’alerte Nagios Tray est un client léger Windows qui surveille l’état de Nagios. En cas d’alerte, une fenêtre apparaît sur le poste de travail. Ici 2 problèmes apparaissent et sont liés : Le service « ping-reseau-lapp » sur la borne sans-fil « airport » est en état critique et la borne ne répond plus au ping (statut « down »). A défaut d’un autre service à surveiller sur certains matériels, le service « ping- reseau-lapp » a été déclaré sur certains matériels réseaux. Options de ce service : commande=check_ping / vérification toutes les 2mn / 3 tentatives avant alerte par mail / contact=support réseau. Nagios teste ce service. Comme il n’a pas de réponse, il tente de pinguer la machine avant de la déclarer « Down » ainsi que son service.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA33 Interface web : vue détaillée d’un « host »

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA34 Interface web : la carte La carte permet d’avoir la topologie du réseau (pas toujours très lisible en mode automatique). Il est possible d’indiquer les coordonnées de chaque objet manuellement, l’image du fond etc… ou d’utiliser des plugins pour créer des cartes personnalisées.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA35 Interface web : vue générale

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA36 Interface web : affichage des problèmes Acknowledged

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA37 Création modèle « modele-switch » qui hérite des paramètres d’un modèle général « modèle » Extrait de config : déclaration d’un switch Création d’un groupe « switchs » qui regroupera les switchs. Création modèle « modele-extinfo- switch-cisco » qui contient des infos étendues (infos visuelles pour la carte) Création d’un matériel « cisco1 » héritant des propriétés du modèle « modele-switch ». Indiquer : nom, IP, parent(s), commentaires… (Éventuellement) on indique le modèle d’infos étendues pour les icônes de la carte + quelques options… modèle (« template ») instance

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA38 Extrait de config : les groupes Création d’un groupe de service « service-ssh- materiel-reseau » (permet de classer les services par groupes) Création d’un service SSH héritant du modèle générique « modele-service » (options générales, périodes de notification, parallélisation etc…). Ce service définit les options particulières au check SSH sur les switchs (intervalles, contact etc…) et appartient au groupe défini ci-dessus.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA39 Bilan Nagios Outil plutôt puissant qui remplit très bien son rôle au LAPP depuis juillet 2005 (alerte en cas de service/hôte « down »). Nécessite un peu d’investissement et d’affinage pour les paramètres. Moins adapté pour la gestion des graphes RRD (bien que des plugins existent).  Au LAPP, fonctionne de façon complémentaire avec Cacti (PHP + RRDTools + SNMP) beaucoup plus adapté pour générer et consulter facilement des courbes SNMP (trafic réseau, nb users, …)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA40 Cacti Projet Gnu GPL (libre et gratuit) pour Unix/Windows Frontend PHP pour créer/consulter des graphes RRD Tools Nécessite MySQL ou PgSQL Récupère données par scripts ou SNMP (net-snmp) / 5mn Nombreux plugins, « templates » etc… pour simplifier la gestion Droits d’accès consultation et modification

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA41 Cacti en quelques captures d’écran Accès protégé, (gestion des droits) pour consultation ou création de graphes Déclaration simplifiée des machines par interface web (utilisation de « templates ») et choix des graphes suivant le type d’hôte (machine Windows/Unix/Switch…)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA42 Cacti en quelques captures d’écran (2) Exemple de sélection des graphes suivant le type d’hôte (ex : borne sans-fil) Infos récupérées par SNMP : pas d’install locale mais activer le service SNMP (ex : partitions Windows)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA43 Cacti en quelques captures d’écran (3) Classement des graphes créés dans une arborescence (au goût de l’admin) On peut limiter l’accès en consultation/modif à des arborescences ou graphes particuliers.

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA44 Cacti en quelques captures d’écran (4) Exemple de consultation de graphes Nécessite un peu de CPU pour gérer les graphes RRD : un P4 2,4GHz traite > 300 graphes. Attention : Cacti n’alerte pas ! (Au LAPP  rôle de Nagios)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA45 Cacti en quelques captures d’écran (5) Mode Zoom pratique pour consulter certaines périodes Attention, graphes RRD  perte de précision au fil du temps

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA46 Cacti : en conclusion Outil pratique, prise en main aisée, pas de connaissance RRDTools nécessaire (génération automatique des graphes). Nbreux plugins disponibles en ligne, possibilité de créer ses propres graphes (en indiquant les OID SNMP)… Nécessite un peu de travail au départ pour mettre au point ses modèles (switchs/Windows/Unix etc…) et graphes associés. Rajout de nouveaux matériels très facile et rapide ensuite. Au LAPP : fonctionne sans problème majeur depuis août 2005 (complémentaire à Nagios)  Actuellement : 42 matériels/314 graphes (principalement trafic réseau/erreurs, %CPU, nb users…)

CEA DSM Dapnia Sédi Septembre 2006/ IN2P3 LAPP || Journee Informatique IN2P3 et DAPNIA47 Des questions ? Merci !