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 MoreSortie 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 MoreKaji : la supervision d’un nouveau genre
Depuis quelques mois un nouveau projet est né dans le monde de la supervision open source, ce nouvel arrivant s’appelle Kaji.
Kaji est un ensemble de paquets de supervision du même style que OMD (Open Source Monitoring Distribution) mais en mieux.
Le but de Kaji est de fournir une solution de supervision complète basée sur Shinken et Adagios mais pas que ! En effet d’autres solutions ont été intégrées à Kaji.
Les différentes solutions ont été packagées pour les distributions majeures:
- CentOS
- Debian
- Red Hat
- Ubuntu
Les dépots sont disponibles à l’URL suivante:
Alors elle est pas belle la vie ?
La version actuelle de Kaji (v 0.2) comprend les logiciels suivant:
- Shinken (2.0.3)
- Adagios (1.6.1)
- Pynag (0.9.1)
- Nagvis (1.7.10)
- Grafana (1.8.1)
- InfluxDB (lastest)
Ça vous donne envie de tester ? Allez je sais que vous n’allez pas résister 🙂
Vous utilisez Docker ou Vagrant ? Jetez un œil sur le repo Github du projet il y a tout ce dont vous avez besoin pour tester Kaji:
https://github.com/kaji-project/kaji-project
La documentation du project est assez complète, et je vous invite à la consulter.
Vous n’avez pas le temps de tester, allez donc jeter un œil à la démo en ligne. Les identifiants pour la démo sont:
- Utilisateur: kaji
- Mot de passe: kaji
Quand on voit l’intégration des différents outils dans Kaji, cela donne envie de voir les futures versions.
En tout cas ce projet à l’air très prometteur, nous avons hâte de voir la suite.
Read MoreSortie de Shinken 1.2, cap sur un tableau de bord et une interface de configuration
Après une attente un peu plus longue que prévue, le logiciel de supervision Shinken, parti comme une réécriture de Nagios en Python, sort une version 1.2. Les développements de cette version se sont concentrés principalement sur l’interface de visualisation des alertes, ainsi que sur l’arrivée d’une nouvelle interface de découverte et configuration.
L’interface de visualisation
Outre un léger relooking de l’interface et de meilleures capacités pour filtrer les informations, la principale nouveauté de cette version est l’arrivée d’un tableau de bord. L’utilisateur pouvant sélectionner des « widgets » et les placer à sa guise sur sa page personnalisée.
L’installation pour les feignants
curl -L http://install.shinken-monitoring.org | /bin/bash
Scalabilité de la supervision passive
La partie configuration
On note ainsi l’arrivée de découverte des équipements en plusieurs phases au lieu d’une seule. Par exemple, une première phase basée sur Nmap pouvant découvrir les principales caractéristiques des équipements (OS, ports ouverts, fabricant du matériel, …), et de nouvelles sondes de découvertes pouvant être lancés sur les équipements respectant certains critères (comme ne scanner les partages réseaux que sur les Windows par exemple).
Autre point intéressant de cette version, l’apparition de moyens d’échanger des bonnes pratiques de supervision. Si dans le microcosme Nagios le partage de sondes de supervision est courant, celui du partage des bonnes pratiques de la configuration de ces sondes l’est beaucoup moins. Or une bonne partie de la bonne gestion de gros environnements passe par ces bonnes pratiques. Shinken propose un outil (shinken-pack) permettant d’extraire de la configuration ce qui a trait à un sujet particulier (Linux, Windows, etc) comme la configuration des sondes ou les règles de découvertes, et d’en faire une archive. Un site communautaire http://community.shinken-monitoring.org a été mis en place pour faciliter leur partage.
Dernier point de la partie configuration est l’arrivée en beta de l’outil de configuration de Shinken, nommé sKonf. Il permet d’utiliser la bibliothèque de découverte de l’outil, mais également la configuration plus classique des éléments. Il est également capable d’aller rechercher de nouveaux packs de supervision directement sur le site communautaire du projet.
Corrélation avancée et calcul de KPI : les triggers
Un autre outil important en matière de supervision est Zabbix. ce dernier repose sur l’obtention de données de performances qui sont analysée par des expressions dites « triggers », là où Nagios, et donc Shinken, laisse cette tâche aux sondes.
Shinken inaugure dans cette version ses propres triggers. Ces derniers n’ont pas pour but d’être utilisés pour toute la supervision, mais dans les cas où l’utilisation des sondes n’est plus adaptée. Ces triggers sont tout simplement du code Python qui sera lancé après les sondes au sein même de l’outil, et ayant accès à toutes ses données.
Ils pourront être utilisés pour définir des règles métiers complexes, où de simples opérateurs & | Xof: ne sont plus assez complets, ou encore dans le calcul de nouveaux indicateurs, comme calculer la moyenne du temps de réponse de serveurs web déjà supervisés, et alerter si elle devient trop importante. Le principal atout de ce système étant que les données étant réinjectées directement au sein de l’outil, elles seront disponibles avec les interfaces actuelles de supervision.
Un autre module fait appel à ce système : le module Collectd. L’outil du même nom est un agent exportant sur le réseau les données de performances des serveurs. Shinken est désormais capable d’écouter ces informations et les transformer en données de performances pour ses propres services. Des triggers peuvent alors être utilisés pour comparer les valeurs à des seuils, et lever des alertes si besoin est.
On notera enfin des améliorations importantes du côté du temps de démarrage sur les gros environnements, ce qui est toujours bon à prendre 🙂
Et un hors série Linux Mag en prime!
Prochaine version
Les développements actuels sont orientés vers la complétion de l’interface de configuration sKonf, ainsi que le rajout de nouvelles fonctions aux triggers et la possibilité à des modules externes d’en fournir des nouvelles.
Une autre idée des utilisateurs de Shinken devrait également voir le jour, à savoir pouvoir changer les commandes, et donc potentiellement les seuils, suivant la période de temps (par exemple augmenter les seuils de charge acceptables pendant une sauvegarde). Sera également présent une partie complète pour l’interface de visualisation dédiée à la supervision « de bout en bout », permettant de simuler un utilisateur sur un site de vente en ligne par exemple (avec affichage des temps de réponses, captures d’écrans sur les erreurs, etc).
Read MorePlugin Monitoring pour GLPI version 0.80+1.2
La nouvelle version est disponible. Il est possible de voir le détail de la version précédente ici.
Buts du projet
Je rappelle que GLPI (gestion de parc informatique & helpdesk) joue les rôles :
- UI de configuration avec son moteur de règles (les check sont définis dynamiquement grâce à l’inventaire automatique via FusionInventory par exemple)
- UI de gestion des ressources / alertes / événements avec des vues techniciens et managers
Shinken sort sa version 1.0
Après une sortie 0.8 de Shinken qui avait apportée une nouvelle interface graphique, voici de nouveau une sortie, et pas n’importe laquelle : la 1.0.
Licence
Sauf mention spéciale, le contenu de ce site est distribué sous licence Creative Commons version BY 3.0.