Shinken 2.4

Posté par (page perso) . Édité par Florent Zara, palm123 et Xavier Teyssier. Modéré par tankey. Licence CC by-sa
38
19
mai
2015
Supervision

Le projet de supervision Open Source Shinken a sorti sa version 2.4 récemment.

Logo Shinken

Cette version, qui inaugure un nouveau cycle de développement plus rapide, est concentrée sur le refactoring de certaines parties du cœur de l'outil afin de le rendre plus flexible et maintenable.

Après plus de 320 commits, cette version 2.4 clôture le premier cycle de développement à cycle réduit adopté par le projet après la version 2.2.

La version 2.2 avait vu beaucoup de rajouts dans le cœur de supervision avec notamment :

  • un export automatique des métriques internes de Shinken vers l'extérieur
  • le rajout de nouveaux objets de configuration (les snapshots) permettant de "sauvegarder" des données des hôtes supervisés lors de problème sur ces derniers afin de pouvoir creuser a posteriori.

Export des données internes de l'outil

Le framework Shinken gère en interne beaucoup de données sur les éléments supervisés ainsi que beaucoup de files d'attentes des checks et des informations échangées entre les daemons. Ces informations sont très pratiques pour superviser le bon fonctionnement de Shinken dans le cas de gros environnement. La version 2.2 a donc rajouté la possibilité d'exporter ces métriques internes vers le monde extérieur. Pour cela deux méthodes sont disponibles :

  • vers statsd : si l'administrateur a un daemon statsd sous la main, il peut l'utiliser et recevoir dans ce dernier cas tous les métriques internes de Shinken. Statsd sauvegardera ces métriques dans un outil de métrologie genre Graphite.
  • vers kernel.shinken.io : pour ceux qui ne souhaitent pas mettre en place un statsd, un webservice gratuit est disponible sur kernel.shinken.io afin de recevoir les métriques des frameworks Shinken et afficher l'état et les données des différents daemons.

Les snapshots de données de supervision

Un des cas courants vécus par les administrateurs est d'avoir à annoncer à son responsable qu'il y a eu un souci de charge durant la nuit, mais qu'il n'a pas assez d'information dans sa supervision pour savoir quel processus a provoqué cela.

C'est le problème que règlent les objets "snapshots" dans Shinken depuis la version 2.2. Ce sont des commandes pouvant être lancées sur les serveurs supervisés qui peuvent fournir des informations sur l'état de la machine (comme une sortie de commande ps) lorsqu'elle est dans un état anormal.

Ces sorties de commandes seront récupérées et relayées vers le daemon "broker" de Shinken qui pourra les fournir à des modules afin de, par exemple, les sauvegarder en base pour un temps donné. Un module sauvegardant en base mongodb est disponible.

Version de maintenance

Cette version 2.4, quant à elle, a été l’occasion de payer de la dette technique dans le cœur et faire un peu de tuning sur certaines parties du code. Ceci permettra d'avoir plus de facilité lors des prochaines phases d'ajouts de fonctionnalités.

Le projet devient grand, il est forké :)

Deux membres de la communauté ont eu un désaccord majeur sur la gouvernance du projet. Ils demandaient la mise en place d'un comité de direction du projet à la place du leader du projet, afin de pouvoir valider ses commits notamment. Mais ceci a été décliné par ce dernier. D'après lui, si cette organisation est efficace pour des gros projets du genre OpenStack, ça n'a pas de sens pour un projet de la taille de Shinken.

Ces deux membres ont donc décidé de forker le projet afin d'appliquer leur nouvelle gouvernance. Leur nouveau fork se nomme Alignak. Nous leur souhaitons toute la réussite dans leur nouveau projet dans le monde décidément impitoyable de la supervision :)

La prochaine version

La prochaine version du framework Shinken sera concentrée une nouvelle fois sur les performances sur les très gros environnements (plus de 50K points de collecte) afin que ces derniers puissent encore plus descendre les intervalles de collecte d'information et donc avoir une supervision plus précise.

  • # Démo

    Posté par (page perso) . Évalué à 8.

    Y a-t-il moyen d'accéder à une démo de l'interface de Shinken ? Je suis curieux de voir les changements par rapport au vieillissant Nagios. J'ai pu tester Icinga et Icinga-web, mais concernat Shinken, je n'ai rien trouvé. Bien sûr, cela peut sembler poudre aux yeux pour décideur pressé quand l'essentiel du travail (et des différences) se trouve sous le capot, mais quand même, everybody loves screenshot :).

    • [^] # Re: Démo

      Posté par . Évalué à -4.

      salut' bob
      pr info j'ai trouvé zabbix beaucoup plus intuitif que nagios, si tu as l'occasion d'essayer (captures d'écrans ici)
      bub

      • [^] # Re: Démo

        Posté par (page perso) . Évalué à 0.

        Pour avoir utilisé Zabbix et Nagios dans des milieux un peu complexes, Zabbix est beaucoup moins intuitif que Nagios.

        Mais bon, intuitif, c'est subjectif.

    • [^] # Re: Démo

      Posté par (page perso) . Évalué à 2.

      Pour une installation chez un client, nous avons préféré utiliser l'interface Thruk que l'interface propre… En effet avec Thruk on peut gérer plusieurs serveurs, pas vu comment faire avec l'intefarce builtin.

      Attention à moins de prendre la version entreprise, la partie configuration graphique n'est pas dispo… Perso, je préfère la ligne de commande à des clickodromes donc cela ne me gêne pas, mais cela peut en gêner d'autres.

  • # copyright et fork

    Posté par . Évalué à 1.

    J'ai fait une recherche rapide sur le net sur le fork pour voir ce qu'il annonçait comme avantage et j'ai vu qu'il s'apprêtait (PR) à supprimer le copyright.
    Ça se fait cela ?
    On doit pas mettre les dates qui vont bien.
    Sinon, j'ai pas vu trop d'info.

  • # [HS] Ouverture d'esprit

    Posté par (page perso) . Évalué à 10.

    Une annonce d'une version d'un soft qui en profite pour informer sur l'existence d'un fork, donner le lien et souhaiter sa réussite. Bravo à l'auteur pour l'ouverture d'esprit.

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # HowTo MaJ ?

    Posté par . Évalué à 3.

    Hello, bonne nouvelle pour cette nouvelle version !
    Petite question, comment se gère la mise a jour sur un serveur Shinken déjà en prod ?
    La doc officiel nous dit "Whatever the way you used to install the previous version of Shinken, you should use the same to update."
    Donc un simple pip install shinken est suffisant ?
    Les modules Shinken (logstore-sqlite, livestatus, webui,…) sont ils a remettre a jour également ? :)

    • [^] # Re: HowTo MaJ ?

      Posté par . Évalué à 1.

      Je me réponds à moi même, si ca peut éventuellement servir (enfin je n'ai pas réussi la maj :( )
      Avant tout bien sauvegarder /etc/shinken/* pour remettre votre conf en place car tous les fichiers sample.cfg et conf de base reviennent (pas génant si vous avez basé votre install avec les noms par défaut, génant si vous avez personnalisé votre conf)

      Sur un serveur en prod donc, j'ai cette version de Shinken :

      $ shinken --version
      shinken 2.0.3

      Je me lance avec la même commande d'install :

      $ pip install shinken
      Requirement already satisfied (use --upgrade to upgrade): shinken in /usr/lib/python2.6/site-packages
      Cleaning up…

      Oups, ok…(j'ai viré les Notice / Warning pour ne pas polluer) :

      $ pip install shinken --upgrade
      Downloading / unpacking shinken from https://pypi.python.org/packages/source/S/Shinken/Shinken-2.4.tar.gz$md5=31210d597b1444ae915196face621e79
      Running setup.py egg_info for package shinken
      Parser error no such option: --egg-base
      Previous Shinken lib detected (/usr/lib/python2.6/site-packages/shinken/init.pyc)
      […]
      Notice: for better performances for the daemons communication, you should install the python-cherrypy3 lib
      Shinken setup done
      Installing collected packages: shinken
      Found existing installation: Shinken 2.0.3
      Uninstalling Shinken:
      Successfully uninstalled Shinken
      Running setup.py install for shinken
      ('updating path in %s', 'build/shinken.cfg')
      […]
      Shinken setup done
      Successfully installed shinken
      Cleaning up…

      Suite à ca, je remets ma conf en ordre, puis restart les services Shinken (puis le serveur lui même…), mais je reste toujours en 2.0.3 ! J'ai du rater un truc =/

      • [^] # Re: HowTo MaJ ?

        Posté par . Évalué à 1.

        Re-réponse à moi même…
        Finalement j'ai pu faire la maj en 2.4 aprés avoir remis a jour les différents packages pip installés (pip freeze pour les lister).

        Par contre l'héritage des service_description d'une définition de service (qui fonctionnaient tres bien en 2.0.3) ne passent plus du tout en 2.4 !
        Shinken se lance avec 0 services (les hosts check fonctionnent par contre..)

        C'est "normal" ou pas ? La doc ne semble rien indiquer sur ce nouveau comportement.

  • # Installation

    Posté par (page perso) . Évalué à 5.

    J'ai suivi Shinken depuis la première annonce passée sur Linuxfr. La supervision étant très importante dans mon métier, je dois connaître ce qui existe.

    La première chose qui m'a sauté aux yeux (qui était encore d'actualité il y a quelques mois, je suppose que c'est toujours le cas), c'est que la procédure officielle pour installer Shinken est d'exécuter un bon gros script sous le compte root.
    Alors bien sûr une machine de test ne risque pas grand'chose, mais en production on évite de jouer avec ça. Un bug, un truc qui se passe mal, ou même une modification malveillante du script et c'est la cata.

    Il y a désormais un paquet Debian, mais on utilise en général les dernières versions disponibles. De plus je ne suis pas certain que ce paquet contiennent l'ensemble de Shinken.

    Comme je n'ai jamais utilisé Shinken « en vrai » sur mes installations (sur celles des autres oui, via le script en root), je n'ai jamais fait l'installation manuellement. Donc je n'ai jamais écris la procédure d'installation.
    note : celle proposée sur le site il y a quelques mois n'était pas viable sur une Debian fraîche.

    À l'occasion je contacterai l'équipe (ou maintenant les équipes) pour savoir si ce genre de procédure d'installation les intéresse.
    Car pouvoir installer et configurer rapidement est important pour évaluer un outil sans avoir à y passer 4 heures et se rendre compte que ce n'est pas celui qui convient pour notre usage.

    • [^] # Re: Installation

      Posté par (page perso) . Évalué à 6. Dernière modification le 21/05/15 à 07:08.

      Heu depuis la 2.0 (donc je dirai plus d'un an facilement) pour l'upstream c'est par pip ou setup.py en local. Tu ne serais pas tombé sur le vieux wiki (supprimé depuis) marqué en deprecated tout gros sur la page principale? :) (ta remarque sur debian fraîche me fait penser que si).

      Sinon des paquets sont disponibles sur Fedora/RH depuis… heu disons sacrément longtemps (la 1.0 je crois mais je peux me tromper), grâce au travail de hvad. Debian ça a pris plus de temps car… disons que c'est debian donc c'était autrement plus long :)

      Plus sérieusement, un outil de supervision ça prendra de toute manière plus de 4h pour en mesurer l'efficacité. L'installation des outils c'est toujours relativement facile (quand on prends la bonne doc ;) ) mais la partie configuration là ça se corse, car tout le monde a des besoins très différents en la matière et l'adaptation à ses besoins bah… c'est pas forcément trivial ^

      Si en 2h tu as fait le tour de tes besoins, c'est qu'ils étaient relativement simples, et dans ce cas je conseille le relativement méconnu (à tort) Sensu. Son scope est de l'ordre de 10% d'un Nagios ou d'un Shinken a fortiori, mais c'est bien plus accessible ┗(^0^)┓

      • [^] # Re: Installation

        Posté par (page perso) . Évalué à 2.

        depuis la 2.0 (donc je dirai plus d'un an facilement) pour l'upstream c'est par pip ou setup.py en local. Tu ne serais pas tombé sur le vieux wiki (supprimé depuis) marqué en deprecated tout gros sur la page principale?

        Merci pour l'info.
        Je viens de re-jeter un œil et je constate que ce n'est plus du tout la procédure que j'ai vu. La nouvelle semble nettement mieux.
        Par contre aucun souvenir d'avoir vu un avertissement, mais ce ne serait pas la première fois que je passe à côté de quelque chose.

        un outil de supervision ça prendra de toute manière plus de 4h pour en mesurer l'efficacité.

        Je parlais du temps pour l'installer.
        Un outil qui prends plus de 20 minutes à installer en configuration de base sur un serveur de test en suivant la procédure officielle, il y a un soucis. Ou alors c'est un truc énorme, expérimental.

        Lorsque Shinken a été annoncé ici, je me suis dit que je participerai volontier. Je vais peut-être m'y pencher durant les prochains jours.

    • [^] # Re: Installation

      Posté par . Évalué à 3.

      Perso j'utilise le paquet Debian depuis la sortie de jessie, et l'installation se passe plutôt bien.

    • [^] # Re: Installation

      Posté par . Évalué à 1.

      Salut,

      En complément tu peux voir ici (https://hvad.fedorapeople.org/fedora/shinken/) les différentes version de shinken et une petit procédure d'installation simple sur Fedora/RedHat/Centos pour la version 2.2 :

      yum install shinken shinken-arbiter shinken-broker shinken-reactionner shinken-poller shinken-scheduler shinken-receiver

      Pour la version 2.4 en RPM tu peux suivre les instructions ici https://copr.fedoraproject.org/coprs/hvad/shinken/ avant que cela soit mis dans les dépots offciels EPEL/Fedora.

      A+

  • # Points de collecte

    Posté par . Évalué à 2.

    Par curiosité, que désignent les 50 000 "points de collecte" évoqués dans l'annonce ? Des serveurs/équipements réseau ? Des services au sens Nagios ? Des métriques ?

  • # Centreon + Centreon-engine

    Posté par . Évalué à -2.

    Je ne vois personne mentionner Centreon ici, et pourtant c'est un excellent projet qui présente l'avantage d'avoir une compatibilité au niveau des fichiers avec Nagios. Migration facile donc !

    Grâce à Centreon-Engine on supprime complètement la brique Nagios, on gagne en performance et en pérennité puisque l'avenir de Nagios côté licence est plié :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.