Communauté francophone de la supervision http://www.monitoring-fr.org J eudis du libre B ruxelles 02 septembre 2010
La communauté Historique 2007 : Olivier J A N publie ses notes de recherche autour de Nagios et la supervision opensource 2007 : premier contact avec Ethan Galstad et création du blog 2008 : deuxième contact avec Ethan et première idée de structuration d'une communauté. 2009 : R omuald F ronteau rejoint Olivier pour la mise en place des forums de support Nagios 2010 : Nagios-fr devient M onitoring-fr 2010 : J ean GA B ES rejoint l'équipe M onitoring-fr 2010 : Olivier LI K I A NG CHEONG rejoint l'équipe M onitoring-fr 2010 : Création de l'association loi 1901 lors des R M LL de B ordeaux
La communauté M issions Blo g Wiki Forums Forge
La communauté A ctivités F aire connaître le monde de la supervision opensource ( Salons, R M LL, J eudis du libre ) Communiquer avec les leaders des projets A ider à la mise en place de solutions de supervision opensource
La communauté L'équipe Olivier JAN Olivier LI KIANG CHEONG David GUENAULT Ludovic VALENTIN Jean GABES Romuald FRONTEA U
R appel : la supervision Une des fonctions de l'administration des SI Fonction clé de plusieurs normes et standards OSI System Management Overview [ISO-10040] ITIL
R appel : pourquoi superviser? Détecter les pannes avant l'utilisateur Réagir plus rapidement en cas d'incident Anticiper les problèmes Contrôler et rendre compte Pilotage de l'exploitation
R appel : quoi superviser? Environnement Matériel Réseau Système Bases de données Services (HTTP, SMTP, LDAP...) Applications Sécurité
Les outils de supervision
Les outils de supervision
Les outils de supervision
Les outils de supervision
Les outils de supervision
Les outils de supervision
R épartition des solutions
R épartition des solutions
PUB
Les dérivés
I nnovations et perspectives
http://mathias-kettner.de/check_mk.html
Check M K
Check M K Système de check hybride actif/passif I nventaire automatique des services A gent pour Windows et Linux Extensible
Livestatus M odule de courtage orienté performance Élimine les problématiques du mode distribué R emplace avantageusement Nagios.cmd I nterrogation des serveurs Nagios en mode local ou distant Langage d'intérrogation ( LQL) proche de la philosophie de SQL.
M ultisite
M ultisite Nouvelle console de supervision B asée sur livestatus Complétement paramétrable F iltres complexes A ctions de masse sur les résultats fltrés
I ls font confance à livestatus
I ls font confance à livestatus
I ls font confance à livestatus Nagios Business Process AddOns
http://www.shinken-monitoring.org/
Origine de Shinken A l'origine un simple poc afn de démontrer les axes d'amélioration de Nagios. F ace aux gardiens du temple, Shinken devient un projet à part entière. Développé par J ean GA B ES auteur de Nagios 3 pour la supervision et la métrologie
P ourquoi shinken? R épondre aux problématiques de performance A pporter une réponse simple à la supervision distribuée la haute disponibilité déploiement de confguration F ournir une solution de supervision indépendante de l'os
Shinken et Nagios Compatible avec la confguration Nagios I mplémentation des principaux modules de courtage en natif ( NDO, Livestatus, M erlin...) Compatible avec les interfaces Ninja, Thruk, Centreon, Nagvis... Compatible avec les plugins Nagios
A rchitecture Un fonction = 1 démon! A rbiter : Lit, découpe et déploie la confguration Schedulers : planife les vérifcations et c'est tout! P ollers : Exécute les vérifcations R eactionner : Gère les notifcations et les évènements B roker : R écupèrent les données et les exportent.
F onctionnement conf Mail Reactionner Broker Arbiter conf1 conf2 conf3 Scheduller1 check Data Scheduller2 check Data Poller1 ok Poller2 Critical Server Server Scheduller3 Poller3 DB
Haute disponibilité Tous les démons peuvent être redondés I l sufft de défnir des «spares» pour chaque type de démon pour que ceux ci soient alors automatiquement redondés. En cas de perte d'un démon le rôle est automatiquement repris par le «spare».
Equilibrage de charge ( distribué) L'équilibrage de charge entre les schedulers est automatique ( déterminé au découpage de la confguration) On peut éventuellement spécifer un «poid» pour les schedulers afn de moduler la taille de la confguration prise en charge par ceux ci
Les realms ( royaumes)
Les realms ( royaumes)
I ls manque quoi? Une vision moins technique de la supervision Supervision métier Découpler la supervision des services par rapport aux hôtes Supervision applicative Citrix Client lourd R eporting souple et avec une base de rapports conséquente Une console plus réactive, confgurable et prenant en compte les différents types de réseau et de terminaux Une ouverture aux CM DB
Merci!