Shinken Web UI version 2

Posted by on 15 Sep 2015 in Shinken | Commentaires fermés sur Shinken Web UI version 2

Après plusieurs mois sans activité, la nouvelle version de l’interface Web de Shinken a été publiée il y a quelques jours et mise à disposition de la communauté sur le site shinken.io. Cette nouvelle version est une refonte quasi complète de l’application Web UI (User Interface) qui améliore et enrichit les fonctionnalités des versions précédentes :

  • interface utilisateur moderne et responsive compatible avec la majorité des Web browsers
  • consultation en temps réel des données du framework Shinken (hosts, services, contacts, groups, timeperiods, …)
  • application opérationnelle dès l’installation
  • gestion des utilisateurs et de leur rôle
  • filtrage performant des ressources de supervision (hosts/services)
  • tactical views: worldmap, minemap, disponibilité, logs, …

Dans la suite de cet article, nous reviendrons sur les principales fonctionnalités de l’interface Shinken Web UI.

Read More

Compte-rendu Nantes Monitoring Meetup #2

Posted by on 9 Sep 2015 in Communauté, Conférences & Salons | Commentaires fermés sur Compte-rendu Nantes Monitoring Meetup #2

Les aficionados nantais (et des environs) du monitoring se sont retrouvés le 03 septembre à La Cantine d’Atlantic 2.0 pour un second meetup.

N’ayant pas reçu d’autres propositions, j’ai présenté un talk sur l’offre actuelle en matière de supervision Open Source. Il y a de quoi dire vu les mouvements stratégiques qui s’opèrent en ce moment dans ce domaine. Vous pouvez trouver la présentation sur Slideshare.

Read More

Sortie de la version 2.4 de Shinken

Posted by on 5 Mai 2015 in Communauté, Interviews, Shinken, Supervision | Commentaires fermés sur Sortie de la version 2.4 de Shinken

Shinken, le framework libre de supervision, est disponible en version 2.4. Monitoring-FR a interviewé Jean « naparuba » Gabes, fondateur et développeur principal de Shinken sur cette nouvelle version de Shinken. En comparaison des versions 2.0 et 2.2, cette version est une version de maintenance : peu de nouveautés, beaucoup de corrections de bug. Le cycle court enclenché par l’équipe de développement commence à prendre forme. Prévue à l’origine pour fin mars, cette nouvelle release sort certes avec un peu plus d’un mois de retard sur le planning prévu initialement mais seulement quatre mois après la précédente version, disponible le 16/01.

Rappelons dans un premier temps que Shinken n’est pas un « fork de Nagios » . Souvent présenté de cette façon, cela devient au fur et à mesure des avancées du logiciel de plus en plus éloignée de la réalité. En effet, à l’origine Shinken ne partait pas du code de Nagios, le terme fork peut donc être considéré comme erroné. Cependant, le but originel était bien de faire de Shinken une ré-implémentation des fonctionnalités de Nagios dans un langage de plus haut niveau (Python) avec une architecture plus performante. Par la suite, Shinken s’est développé et intègre des fonctionnalités non disponibles dans Nagios. Cela fait donc quelques années déjà que Shinken est plus qu’une simple ré-implémentation de Nagios. Quels sont les principaux points de cette nouvelle version? Comme toujours, il est nécessaire de bien comprendre l’architecture du logiciel afin d’appréhender le mieux possible les évolutions proposées dans une nouvelle version de celui-ci.

Rappels sur l’architecture

Shinken dispose d’une architecture de rupture face aux autres outils Libres de supervision. Shinken est composé de plusieurs démons, chaque démon ayant son propre rôle :

  • arbiter : lit la configuration, la sépare et l’affecte au(x) scheduler(s). Il vérifie régulièrement que le(s) scheduler(s) fonctionnent correctement et affecte la configuration d’un scheduler en panne à un autre scheduler. Il reçoit les actions de supervision (commentaire, acquittement, …) et les dirige vers le scheduler correspondant.
  • scheduler : gère une partie de la configuration. Dispatche les tests à effectuer sur les pollers et les actions sur les reactionners. Le scheduler est aussi responsable du traitement du résultat, de la corrélation et de l’activation des actions (notifications, reprise sur incident).
  • poller : lance les tests et transfère le résultat au scheduler. Un scheduler peut être associé à un domaine de supervision spécialisé (Windows par exemple) ou à un environnement (poller dédié à un site géographique par exemple).
  • reactionner : responsable de la notification et des reprises sur incident (« event handler »).
  • broker : responsable des données et de leur stockage. Il existe plusieurs brokers, chacun répondant à un besoin particulier : un broker dédié aux données de performance (pour Graphite par exemple) ou un broker dédié au stockage des données de supervision temps réel pour une interface web particulière.
  • receiver : reçoit les données de supervision passives et les transfert au scheduler correspondant.

Shinken dispose de sa propre interface appelée Shinken-UI mais il est courant de lui adjoindre d’autres (Thruk, Graphite, PNP4Nagios). Depuis quelques versions déjà, l’interface Shinken-UI ne fait plus partie de « Shinken » : cette interface est considérée comme un module complémentaire à Shinken et les codes de Shinken et Shinken-UI sont séparés, comme le sont aussi ceux des brokers. Donc lorsque l’on parle de « la version 2.4 de Shinken », on parle des démons présentés précédemment et non de l’interface.

Numéros de version de Shinken

Shinken sort en version 2.4. La version précédente était la version 2.2 et celle juste avant était la version 2.0. Où sont passées les version 2.3 et 2.1? Ces versions n’existent pas : dans les faits, elles ne sont pas releasées. Les développeurs de Shinken préfèrent sortir des versions x.y où y est pair. Cela se justifie car les versions impaires sont généralement considérées comme des versions de développement (donc instables) par les utilisateurs. Il n’y a pas de versions intermédiaires (en x.y.z) sauf si cela est vraiment nécessaire. Ce qui ne devrait pas changer suite à la mise en place du cycle de développement court.

Les changements de version majeure se font lorsque la compatibilité n’est plus assurée avec les modules ou lors d’un changement très structurant. La raison du passage de la version 1.4 à la version 2.0 est lié à la gestion des modules : ceux-ci ne sont plus livrés directement avec Shinken mais à part. Charge aux utilisateurs d’aller chercher les modules Shinken souhaités. Ce changement était très important et nécessitait une montée de version majeure. À priori, le prochain changement de version majeure devrait intervenir lorsque Shinken imposera une montée de version vers Python 3.X. Celle-ci ne devrait intervenir que lorsque la RHEL 5 commencera vraiment à disparaître et la décision sera prise en fonction des retours utilisateurs.

Les développeurs de Shinken ont à cœur de maintenir la compatibilité ascendante concernant les fichiers de configuration : les fichiers de configuration de la première version doivent pouvoir être utilisés sans aucune modification sur la dernière version. Même des fichiers de configuration Nagios doivent pouvoir fonctionner parfaitement sur Shinken. C’est grâce à la présence de nombreux tests unitaires que ceci est permis. Cela permet aux utilisateurs de Shinken de migrer vers la dernière version sans nécessiter de mise à jour de leurs fichiers de configuration, étape qui peut être fastidieuse et très risquée.

Nouveautés de la version 2.4

La maintenance de la configuration d’une plate-forme de supervision peut être complexe. Avec cette version 2.4, Shinken facilite un peu plus la gestion de la configuration en permettant aux responsables de la plate-forme d’exclure certains services d’un modèle lors de l’héritage. Ce point peut être complexe à comprendre et nécessite une explication. Pour éviter de devoir saisir plusieurs fois les mêmes éléments de configuration, Shinken permet à ses utilisateurs de saisir des « modèles d’équipement » (« packs » dans la terminologie Shinken) : ces modèles d’équipement sont reliés à des « modèles d’indicateurs de supervision ». Par exemple, on peut définir un « modèle Linux » auquel seront associés des modèles « CPU », « mémoire vive », « partitions », « processus cron démarré », … Lorsqu’un équipement hérite d’un modèle, il hérite de tous les éléments associés à ce modèle. S’il hérite de plusieurs modèles (exemple : Linux + Dell + MySQL + Apache) , il hérite de tous les indicateurs de chacun des modèles. C’est un gain de temps considérable. Cependant, dans certains cas, il est nécessaire qu’un ou plusieurs indicateurs de supervision ne soient pas associés automatiquement. C’est la nouveauté de cette version 2.4 : il est dorénavant possible d’exclure des indicateurs de supervision lors de l’héritage. Un cas simple pour comprendre plus facilement : un serveur Windows ne dispose pas de l’antivirus déployé sur tous les autres serveurs Windows car l’application qu’il héberge n’est pas compatible avec cet antivirus. Pour ce serveur spécifiquement, une ligne va être ajoutée afin d’exclure l’indicateur concerné.

L’un des points forts de Shinken est de pouvoir gérer plusieurs dizaines de milliers d’indicateurs de supervision. Afin d’éviter de saturer la mémoire vive du serveur, un travail a été réalisé par les développeurs afin d’optimiser la mémoire. Deux améliorations ont été apportées, l’une à l’arbiter et l’autre au scheduler. Un problème de fuite mémoire se posait lors de bascule sur l’esclave ou lors de retour sur le maître, dans le mode HA. Ce problème est corrigé.

Dorénavant, sudo n’est plus utilisé. Pour cela, Shinken utilise systemd : grâce à l’utilisateur Unix shinken, il est possible de redémarrer le service sans passer par sudo. systemd n’étant pas encore disponible sur toutes les plates-formes, Shinken continuera d’utiliser sudo là où cela s’avérera nécessaire.

Un travail de refactoring (« nettoyage« ) du code est entrepris au fur et à mesure des sorties de version. Cette version n’y échappe pas, bien au contraire et a fait l’objet d’adaptations afin de respecter au maximum les bonnes pratiques recommandées par Pep8. Suivre les bonnes pratiques permet de disposer d’un code identique partout : un développeur donné n’est pas gêné par la façon d’écrire du code des autres développeurs car tout le monde respecte le référentiel des bonnes pratiques. Le code est alors plus simple à analyser. La vérification des bonnes pratiques est faite à chaque modification de code et à l’aide d’outils dédiés.

Read More

Un cocktail de rentrée pour bien superviser votre site web

Posted by on 27 Août 2014 in Astuces, Nagios, Planet, Supervision | 1 comment

Après la gueule de bois des vacances, je vous propose de reprendre en douceur avec une recette de cocktail dont vous me direz des nouvelles ! 😉

Interne ou externe, telle est la question ?

Aujourd’hui, bon nombre d’entreprises confient l’hébergement de leurs sites web à des professionnels de la toile et de plus en plus externalisent certaines de leurs applications dans le cloud. L’avantage est que l’entreprise ne porte plus la responsabilité de l’interruption de service et le cloud peut avoir un attrait financier. D’un autre côté, elle perd en maîtrise de la surveillance, mesure de performance de ses applications externalisées. Le « hic » à tout ça, c’est que les entreprises sont obligés de faire confiance aux rapports fournis par leurs fournisseurs de service. Est-ce bien objectif ?

Des moyens pour les challengers existe avec de la supervision provenant de son propre S.I (check http via proxy, du robot scénarisé avec cucumber, watir, sélénium, …) mais ceci n’est pas ce qu’il y a de plus fiable. Ce contrôle n’est réalisé que d’un seul point et est biaisé par rapport à l’expérience de vos utilisateurs.

Et oui, il faut passer par le proxy, la connexion internet de l’entreprise qui peuvent eux-mêmes avoir une interruption de service et ainsi perturber les SLA. De plus, ceci ne correspond pas toujours au chemin réel pris par vos visiteurs ou utilisateurs.

Le moyen le plus sûr est l’abonnement à un service de supervision « Cloud »; gratuit éventuellement si les besoins sont modestes. Ce service va jouer un rôle d’arbitre entre le ressenti de l’entreprise et les données fournies par un professionnel de la toile. Ceci vous permettra de le challenger afin de contrôler si les engagements sont bien tenus.
Mais là, autre « hic », comme tous services cloud, une console de Supervision en ligne vous apportera l’inconvénient de ne toujours pas avoir une maîtrise totale sur les données produites par celle-ci. Vous bénéficiez de rapports « standardisés » fournit par ce service et qui ne correspondent pas forcément à votre besoin ou même votre métier.

Vous allez me dire : « Je veux avoir la maîtrise de mes données afin de pouvoir les traiter, corréler et représenter avec les solutions interne de mon entreprise !!! »

Et je vous réponds, maintenant c’est possible !

Comme certains d’entre vous ont pu le voir passer sur la toile ou les réseaux sociaux, l’équipe de Check My Website a publié il y a quelques temps un plugin de supervision pour plateforme « Nagios-like » (Nagios, Centreon, Icinga, Shinken), disponible sur github en libre téléchargement.
Check my We’bsite  est un service en ligne de supervision de sites, applications web se trouvant dans le cloud. Je vous laisse faire connaissance avec eux sur cet article
La console étant à l’heure actuelle en bêta ouverte au public avant la commercialisation du service, j’ai réalisé un test d’intégration d’une sonde « Check my Website » sur ma plateforme Nagios/Centreon.

S’abonner à Check my Website

Premièrement, il faut que créer un compte sur la console CheckMyWebsite.

Après, il vous suffit en 2/3 clics d’ajouter l’URL à superviser.
Une fois que la supervision de votre site est effective, direction votre plateforme de supervision « Nagios-like »

Installation & configuration de votre Supervision interne

Une fois le plugin « Check my Website » installé sur votre plateforme, vous n’avez plus qu’à configurer une commande Nagios qui appelle votre plugin et de mettre en place votre sonde.

2014-08-07_12h41_26

Vous avez maintenant vos données d’incidents et de performance qui remontent dans votre console interne. Le plugin remontent comme données de performance :

  • Temps de réponse des différentes « locations » d’où est interrogé le site Web
  • Temps de réponse moyen du site web
  • Temps de chargement de la page web (Mesure YSlow)
  • Notation YSlow

La cerise sur le gâteau

On pourrait se contenter déjà de ce qui a été fait, mais j’ai été poussé le vice plus loin encore. Utilisant CANOPSIS comme solution de dashboard, je me suis dit, « Pourquoi pas me faire un tableau de bord représentant l’activité de mon site sous surveillance ? »
Voici un résultat possible que j’ai produit avec les données de ma sonde Check my Website

2014-08-07_12h39_23
2014-08-07_12h39_38

 

Alors convaincu ?

Read More

Sondage 2012 : quelle est votre solution de supervision préférée ?

Posted by on 4 Sep 2012 in Supervision | 3 comments

En cette nouvelle rentrée, l’équipe Monitoring-fr vous propose un petit sondage pour voir un peu les tendances dans le monde francophone de la supervision Open Source.

Nous avons listé les applications les plus connues afin que tout le monde puisse y trouver son compte. Si jamais votre solution ne figure pas dans la liste, nous vous invitons à sélectionner la réponse « Autre » et de laisser un commentaire (plus bas) avec le nom de votre outil de supervision.

Read More