Communauté francophone de la supervision. J eudis du libre B ruxelles 02 septembre 2010

Transcription

1 Communauté francophone de la supervision J eudis du libre B ruxelles 02 septembre 2010

2 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é : 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

3 La communauté M issions Blo g Wiki Forums Forge

4 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

5 La communauté L'équipe Olivier JAN Olivier LI KIANG CHEONG David GUENAULT Ludovic VALENTIN Jean GABES Romuald FRONTEA U

6 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

7 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

8 R appel : quoi superviser? Environnement Matériel Réseau Système Bases de données Services (HTTP, SMTP, LDAP...) Applications Sécurité

9 Les outils de supervision

10 Les outils de supervision

11 Les outils de supervision

12 Les outils de supervision

13 Les outils de supervision

14 Les outils de supervision

15 R épartition des solutions

16 R épartition des solutions

17 PUB

18 Les dérivés

19 I nnovations et perspectives

20

21 Check M K

22 Check M K Système de check hybride actif/passif I nventaire automatique des services A gent pour Windows et Linux Extensible

23 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.

24 M ultisite

25 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

26 I ls font confance à livestatus

27 I ls font confance à livestatus

28 I ls font confance à livestatus Nagios Business Process AddOns

29

30 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

31 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

32 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

33 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.

34 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

35 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».

36 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

37 Les realms ( royaumes)

38 Les realms ( royaumes)

39 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

40 Merci!