Shinken version 2.0

42
16
avr.
2014
Supervision

Le projet de logiciel libre de supervision Shinken vient d’annoncer sa nouvelle version majeure, la 2.0. Elle apporte principalement une orientation du projet vers le cœur de supervision, la mise en place de HTTPS entre les démons et une forte améliorations des règles métiers. Le projet gagne au passage un nouveau logo.

Logo Shinken

Un recentrage comme infrastructure de supervision

Le changement important de cette version est un découpage bien plus clair qu’avant entre ce qui concerne le cœur du projet, l’infrastructure de supervision avec ses démons, et les divers modules et packs de supervision. L’objectif est de donner aux utilisateurs les connaissances et les choix pour bâtir leur propre solution.

Ils sont aidés dans cette tâche par un nouveau site d’échange de packs et de modules, shinken.io et la nouvelle commande shinken permettant d’aller récupérer et installer automatiquement les paquetages :

$ shinken install linux-ssh

Installation via pip

La partie installation a également fortement évolué. Précédemment basée sur un script d’installation, elle suit désormais les standards du monde Python avec un paquet disponible sur Pypi. L’installation de l’infrastructure devient donc tout simplement :

$ pip install shinken

Cette nouvelle méthode est bien plus adaptée pour les empaqueteurs, et des paquets pour les distributions principales sont en cours de finalisation.

Il est à noter que les futures mises à jour de Shinken se feront simplement en relançant cette même commande. :)

Amélioration des règles métiers

Grâce au (gros) travail du contributeur Christophe Simon, les règles métiers (alias bp_rules) ont fortement évolué dans cette version. Il est désormais possible de créer un indicateur agrégé pour un ensemble d’éléments en se basant sur des expressions régulières ou des groupes dans lesquels ils se situent.

Par exemple, pour créer un indicateur unique qui agrège les états de tous les disques de ses serveurs GNU/Linux, il suffit de déclarer :

check_command bp_rule!g:linux,Disks

Un passage au HTTPS entre les daemons

Dernier changement, et non des moindres, les démons communiquent désormais en HTTP(S). Ceci permet de mettre en place facilement un chiffrement efficace (modulo les failles dans OpenSSL, évidemment) de manière simple par rapport aux versions précédentes qui utilisaient la bibliothèque Python Pyro peu compatible avec le SSL.

Il est désormais possible d’interroger directement et facilement les démons Shinken (et leurs indicateurs internes). Par exemple, pour vérifier qu’un démon est en vie, il suffit de lancer :

$ curl http://localhost:7770/ping
"pong"

Ou, par exemple, pour vider tous les hôtes chargés par Shinken :

$ curl "http://localhost:7770/get_objects_properties?table=hosts" | json_pp

Une liste complète des appels API est disponible via :

$ curl http://localhost:7770/api_full | json_pp

Les prochaines versions amélioreront fortement cette API, et les modules pourront également proposer leurs propres appels spécifiques.

Feuille de route et cycle de versions

Cette version a eu une gestation bien longue, notamment expliquée par le fait que le développeur principal de Shinken a lancé sa société d’édition pendant cette période et que les objectifs de réusinage de l’infrastructure étaient assez élevés (tout en assurant une compatibilité ascendante).

Avec désormais un cycle de version propre à l’infrastructure, décorrélé de celui des modules qui peuvent être plus longs (par exemple, celui de l’interface graphique WebUI), et un objectif d’avoir moins de nouvelles fonctionnalités par version, le cycle de sortie devrait fortement réduire. :)

Concernant les améliorations des futures versions, on notera tout particulièrement :

  • un rétroportage de certaines vues de la version Enterprise de Shinken dans la version communautaire ;
  • l’ajout d’une fonctionnalité tout particulièrement chère au cœur de l’auteur de Shinken : les arbiters relays, permettant de laisser la gestion complète d’un royaume (aka datacenter) à un démon sur place ;
  • l’ajout très prochainement des commandes d’instantanées (snapshots) permettant d’avoir une « vue » de l’état d’une machine (ex : par le lancement d’un ps) lors d’un souci de charge la nuit, par exemple ;
  • accès à toutes les informations internes des démons depuis l’API HTTP.

Mise à jour et cours

Concernant la documentation, elle est désormais disponible en ligne, mais elle est également embarquée avec l’installation de Shinken et disponible sur le port 8080 en lançant :

$ shinken doc-serve

Des cours en vidéos sont disponibles concernant la mise en place de cette nouvelle version et la mise à jour depuis la version 1.4 sur le blog du projet.

  • # packs et modules

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

    Il me semble que le site http://shinken.io/ référence des liens vers les modules mais n'a pas lui même une copie des modules… En gros, c'est un annuaire. A mon avis, c'est dommage. Une des grandes forces du CPAN (Perl) est d'avoir tous les modules Perl ainsi que toutes les versions. Ainsi, l'upstream peut disparaître.

    Cependant, j'ai peut être mal compris.

  • # Supervision oui, mais de quoi ?

    Posté par . Évalué à 1.

    Après lecture de la dépêche, impossible de savoir ce que Shinken surveille.

    Donc pour ceux qui se pose la question, d'après leur site:

    Shinken packages will allow you to (…) monitor your servers and applications.

    • [^] # Re: Supervision oui, mais de quoi ?

      Posté par . Évalué à 10.

      En fait en informatique le mot supervision est en général utilisé au sens de supervision de l'infrastructure (serveurs notamment) et des logiciels qui tournent dessus ("en général" est un euphémisme).

      D'ailleurs regarde la catégorie de la dépêche (l'icône en haut à gauche représentant un oscilloscope bleu que quand on passe la souris dessus ça affiche "Supervision"), elle ne dit pas non plus ce qu'on doit superviser.

      Du coup personnellement je pardonne les rédacteurs de la dépêche de ne pas avoir précisé. Mais c'est juste mon choix individuel.
      ++

  • # explosion mémoire dû aux commentaires

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

    Un bogue connu est que Shinen consomme beaucoup de mémoire à partir de quelques centaines de commentaires enregistrés… c'est toujours d'actualité ?

    Love – bépo

    • [^] # Re: explosion mémoire dû aux commentaires

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

      Je n'ai pas encore réussi à le reproduire, donc j'imagine que oui. En même temps de mémoire on ne me l'a remonté que sur une seule installation. Je suis beaucoup de grosses installations et aucune ne m'a remontée le problème encore :)

      • [^] # Re: explosion mémoire dû aux commentaires

        Posté par . Évalué à 9.

        Il n'y a que 6 commentaires sur la dépêche pour le moment (enfin ça va faire 7 avec le mien), du coup c'est pour ça que tu ne reproduit pas le bug, il en faut plusieurs centaines! Dès que les moules auront suffisamment commenté la dépêche, tous les Shinken de la planète planteront.

      • [^] # Re: explosion mémoire dû aux commentaires

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

        J'ai eu un écho qu'ils avaient un problème de fuite mémoire sur Shinken chez Immochan, résolu par un script qui purge des entrées (j'ai pas plus de précision)… Donc peut-être deux cas, non ?

        • [^] # Re: explosion mémoire dû aux commentaires

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

          Ben ce script est de moi, chez immochan effectivement. Et les entrées sont juste les commentaires. En bourrant des entrées dans le fichier de rétention, on peut admirer shinken en train de croquer la mémoire à pleines dents.

          Et ce qui est bizarre, c'est qu'au début ça n'arrivait que sur le poller, et après une réinstallation, ça arrivait au scheduler (ou l'inverse, mais peut importe).

          Voilà voilà…

          Love – bépo

  • # Tu m'excuseras de rire...

    Posté par . Évalué à 10.

    Je lis :

    Dernier changement et non des moindres : les daemons communiquent désormais en HTTP(S). Ceci permet de mettre en place facilement un chiffrement efficace (modulo les failles dans OpenSSL évidemment) de manière simple par rapport aux versions précédentes qui utilisaient la librairie python Pyro peu compatible avec le SSL.

    Et 30 secondes passees a regarder ce que fait le client HTTP donnent :

    # Also set the SSL options to do not look at the certificates too much
    self.con.setopt(pycurl.SSL_VERIFYPEER, 0)
    self.con.setopt(pycurl.SSL_VERIFYHOST, 0)

    Genre, ca sert a quoi SSL si le module en charge des connections ne verifie meme pas a qui il cause et se chope une attaque MITM avec un certificat valide mais avec un hostname different ?

    • [^] # Re: Tu m'excuseras de rire...

      Posté par . Évalué à 2.

      Je me demandais justement comment était gérer les connexions HTTPS. Genre, est-ce que le client vérifie le serveur et est vérifié par le serveur ? Comment sont gérés les certificats ?
      En effet, je cherchais du code python pour faire cela il y a qq jours ;)

    • [^] # Re: Tu m'excuseras de rire...

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

      C'est tout à fait juste, je sais donc quoi rajouter pour la première release bug fix merci :)

      Perso ce qui m’embête plus n'est pas le paramétrage à 0 par défaut qui restera ainsi, mais plus qu'il ne soit pas modifiable. Heureusement ça va se gérer plutôt bien surtout qu'on a déjà le paramètre géré côté conf, il suffit de le relier au bon endroit :)

      Vu que tu as l'air efficace dans le domaine je t'invite à aller voir du côté de l'UI web de shinken vérifier qu'il n'y a pas de soucis (https://github.com/shinken-monitoring/mod-webui/blob/master/module/module.py). Bon on a pas de https qui est laissé à un frontal si besoin est, mais si tu peux prendre un peu de temps pour regarder ça nous aiderai bien :)

      • [^] # Re: Tu m'excuseras de rire...

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

        La valeur par défaut à 0 restera ainsi ?
        C'est vraiment une mauvaise pratique. Il n'est plus si difficile de gérer une CA aujourdhui (qca, easy-rsa…).
        À la limite, je ne sais pas si c'est facile, mais je préfèrerais une valeur par défaut à "pre shared key".

        • [^] # Re: Tu m'excuseras de rire...

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

          Ah intéressant, elle permet quoi exactement? Si elle est pas trop impactante (car si beaucoup ont encore du mal à avoir une vrai PKI :) ) ça pourrait être pas mal :)

          • [^] # Re: Tu m'excuseras de rire...

            Posté par (page perso) . Évalué à 10. Dernière modification le 17/04/14 à 11:27.

            paramétrage à 0 par défaut qui restera ainsi

            Je crois qu'il faudrait surtout commencer à se renseigner sur la sécurité avant d'implémenter à l'arrache.
            Car la, je ne sais pas pour le site web de Shinken lui-même, mais la dépèche laisser penser que Shinken permet des liens sécurisés ("S" de HTTPS) entre les différents composants, alors qu'en fait non (le commentaire du code source dit bien "bon, on regarde le certifcat, mais si ça ne correspond pas, pas grave, c'est juste pour l'affichage, on peut dire qu'on a HTTPS et les gens ne vont pas chercher plus loin")

            Le faux sentiment de sécurité est pire pour la sécurité que l'absence de sécurité.

            mais je préfèrerais une valeur par défaut à "pre shared key".

            Ah intéressant, elle permet quoi exactement?

            "pre shared key".

            • [^] # Re: Tu m'excuseras de rire...

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

              C'est justement pour ça que je prépare la 2.0.1 :)

              Cette version est surtout concentrée sur le http, le s était en plus, car les mise en prod que j'avais faite reposaient surtout sur des reverse proxy qui s'occupaient de ça en frontal (car il le faut de toute manière pour la partie web), d'où le manque sur ce paramètre là. faut dire qu'entre les nrpe t autre graphite en général en matière de supervision on a d'autres soucis que le chiffrement (ou plutôt authentification) mais bon ça n'excuse pas tout en effet :p

              Sinon pour pre shared key je connais le principe, c'est juste que j'aimerai surtout savoir ce que ça donne en vrai dans openssl côté implémentation et si possible si c'est déjà géré par pyopenssl (mais ça ça ne doit pas poser un gros soucis).

              • [^] # Re: Tu m'excuseras de rire...

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

                Je trouve tout à fait pertinent de se reposer sur un frontal pour la partie chiffrement. Au passage, ça limite (un tout petit peu) l'impact de heartbleed sur la fuite d'infos :-)
                Je ne sais pas implémenter PSK là comme ça sans lire la doc, mais ça me semble un chiffrement du pauvre suffisant pour commencer (le mieux étant peut-être de faire de l'auth réciproque par clef publique ad-hoc en demandant au tech qui est devant l'écran de valider qu'il est bien en train de connecter deux machines :-)

              • [^] # Re: Tu m'excuseras de rire...

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

                Et hop voici une 2.0.1 toute chaude avec le paramètre de géré sur tous les daemons. Pour info il faut donc rajouter le paramètre hard_ssl_name_check les configuration des daemons (en plus de use_ssl donc).

                Pour mettre à jour un passage par la commande pip suffira :)

                Finalement heureusement que l'update simplifiée est gérée dès à présent :p

                • [^] # Re: Tu m'excuseras de rire...

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

                  Je tiens à féliciter tous les auteurs qui ont rendu possible la possibilité d'installer/mettre à jour avec pip.
                  Par contre je ne peux être plus d'accord avec Zenitram quand il dit que l'illusion de la sécurité est pire que du trafic en clair. En fait, je trouve assez grave que la valeur par défaut soit "ne pas vérifier". Limite ça vaut un CVE.

                  • [^] # Re: Tu m'excuseras de rire...

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

                    pip, et plus simplement le packaging python, a été une vraie galère à mettre en place. C'est fait pour des lib, pas pour des outils (genre les fichiers de conf par exemple) :(

                    Sinon en fait le paramètre à 0 est situé juste en dessous de use_ssl avec un texte très explicite, donc là sincèrement le mec qui active le ssl ne pourra pas dire qu'il ne l'a pas vu :)

                    Ce qu'il faut voir c'est que si je le passe à 1 par défaut, on va avoir une armée de stagiaires arriver en pleurant sur les forums qui ne vont pas comprendre pourquoi ça ne marche pas, et sincèrement j'ai autre chose à faire que gérer une armée de stagiaires en supervision :)
                    (oui je commence à les connaître ceux là au bout de quelques années dans le domaine :) )

                    Là le paramètre est très clair, commenté et juste ne dessous de l'activation du ssl, donc un admin "normal" n'aura aucun soucis à savoir qu'il doit le passer à 1 s'il a ses propres certificats.

                    Bon après sincèrement autant mettre un simple reverse apache/nginx en façade, car les admins ont déjà tout outillé pour ça (les règles puppet and co) et ça facilite un peu la mise en place sur de grosses infras un peu sensibles au point de vue réseau (genre là où on a mis la 2.0 en prod dernièrement en fait).

                    On verra bien comment ça sera utiliser au final, après tout vu que c'est du http, c'est très malléable :)

                    • [^] # Re: Tu m'excuseras de rire...

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

                      Ce qu'il faut voir c'est que si je le passe à 1 par défaut, on va avoir une armée de stagiaires arriver en pleurant sur les forums qui ne vont pas comprendre pourquoi ça ne marche pas

                      quitte à me répéter, Le faux sentiment de sécurité est pire pour la sécurité que l'absence de sécurité.

                      Ici, tes stagiaires vont penser et dire que c'est sécurisé (il ont activié la sécurité et tout laissé par défaut), alors que ça ne l'est pas.
                      Un jour, ça te retombera dessus, et comme tout truc qui retombe après des années de "mais ça marche alors ça va", ça peut faire très très mal.

                      C'est un choix, certes. Mais un choix problématique pour la sécurité.

                      • [^] # Re: Tu m'excuseras de rire...

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

                        Là le moindre admin qui regarde les precos ou qui va se demander comment le stagiarie à fait sans lui demander un certificat va savoir directement qu'il y a un soucis.

                        Donc on a plus un soucis d'organisation, et si on mets en place le 1 par défaut, on va juste avoir le ssl de désactivé systématiquement ce qui n'est gère mieux. On n'aura pas le faux sentiment de sécurité c'est vrai, on en aura carrément pas :)

                        Bon après ça permets justement de lever un signal d'alarme.

                        Est-ce que ça va poser un soucis dans certains endroits? oui peu être, mais ça leur montrera aussi que la mise en place d'un tel outil doit être fait par une personne qualifiée, et pas par un stagiaire.

                        Dans les SI où les admins prennent ça au sérieux et savent lire le commentaire qui est une ligne en dessous du paramètre d'activation du HTTPS ça ne posera aucun soucis, et sincèrement c'est bien eux mes utilisateurs principaux.

                        Je comprends ton point de vue, et oui c'est tout à fait justifiable de forcer un paramètre sécurisé dès le début, mais vu qu'il va n'impacter que ceux qui n'en ont pas grand chose à faire et va pourri la vie des mainteneurs sans impacter ceux que ça intéresse, le jeu n'en vaut pas la chandelle.

                        Ensuite ça n’empêche pas que je vais rajouter une page dans la doc sur l'activation du SSL avec justement un petit focus là dessus et un petit warning dans les logs par exemple. Si le stagiaire pense que c'est vraiment sécurisé alors que la ligne juste en dessous a un gros warning sur la sécurité, qu'il se prends un log de warning et que la doc a un point spécial là dessus, c'est qu'il est cliniquement con :)

                        Pas trivial comme problématique je dois bien l'avouer, et je suis un peu biaiser vu que je suis l'un de ceux qui devraient gérer l'afflux de demandes sur les forums. On verra bien dans le futur si on change le paramètre ou pas. Mais bon on part sur cette version sur une responsabilisation des utilisateurs justement, avec l'arrêt du script d'install automatiques et le non paramétrage par défaut de pleins de trucs de manière un peu magique. Je préfère suivre cette logique et voir ce que ça donne :)

                        Ps: je n'ai rien contre les stagiaires, on a tous commencé comme ça dans la supervision, mais il faut bien reconnaître que la proportions de questions triviales ("j'ai pas les droits sur tel répertoire, je dois faire quoi?") explose dès le début des périodes de stages..

                        • [^] # Re: Tu m'excuseras de rire...

                          Posté par (page perso) . Évalué à 2. Dernière modification le 17/04/14 à 16:38.

                          Un warning ? pourquoi pas critical ?

                          import threading
                          import time
                          
                          from my_modules imports globally_stopped()
                          
                          most_important_logger = logging.getLogger('root')
                          
                          # [...] quelque part après avoir lu la conf :
                          
                          class ComplainThread(object):
                              def run():
                                  while not globally_stopped():
                                      most_important_logger.critical(
                                          "Someone is (probably) hijacking your SSL sessions!"
                                          " read documentation at https://..."
                                       )
                                      if config["Yes I know what I'm doing"]:
                                          return
                          
                                      time.sleep(10)
                          
                          complaint = ComplainThread()
                          complaint.start()

                          :-)

                    • [^] # Re: Tu m'excuseras de rire...

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

                      Je ne lis pas l'avenir dans le marc de café, mais je pense que tu auras moins de stagiaires en panne d'assistance si tu attrapes l'exception "certificat non valide" et leur mets un gros message pour leur expliquer l'alternative qui s'offre à eux :
                      * permettre le mitm,
                      * créer une PKI au moyen de $outil,
                      * utiliser nginx devant (et toujours avoir une PKI).

                      • [^] # Re: Tu m'excuseras de rire...

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

                        c'est vrai que le message d'erreur de libcurl est vraiment cryptique en plus. Je me le note pour la prochaine version de le catcher et proposer une solution de contournent ou un simple lien vers la doc qui l'explique en fait :)

                        • [^] # Re: Tu m'excuseras de rire...

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

                          Les stagiaires te remercient d’avance ! :)
                          (et pour la patience avec laquelle vous leur répondez sur les forums, aussi…)
                          Et on se demande aussi pourquoi une tâche aussi importante que la mise en place d’une supervisation est presque toujours confiée à un stagiaire tout seul… C’est quand même quelque chose de complexe et sensible… On dirait que ça fait partie d’une sorte de travail d’initiation, ou de chef d’œuvre de compagnonnage…

                          • [^] # Re: Tu m'excuseras de rire...

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

                            En fait, en France en tout cas, la supervision est ue uniquement d'un point de vue "technique", comme "juste" un outil pour les admins mais qui n'a pas d'influence sur les métiers de l'entreprise.

                            Or je ne vais pas vous apprendre que plus c'est "technique" et plus c'est mal vu en France. Or la supervision peut, et même doit, être orienté vers les applications métiers, afin de les aider à toujours être en état de marche. C'est un long travail et le fait d'avoir un nagios qui se focalise sur l'IT d'un point de vue bas niveau n'aide pas à faire comprendre que si, on peut être supervision et haut niveau (genre ce qu'on a avec les bp_rule et shinken).

                            Corollaire: si c'est technique et peu important on ne mets pas les moyens, donc on mets un stagiaire. cqfd.

                            C'est bizarre, mais j'ai rarement des questions de stagiaires des US par exemple, mais surtout en France. Or on a beaucoup de shinken aux us aussi, mais le plus souvent ce sont les admins expérimentés qui le mettent en place.

                            Bon au final ça fait de bon sujet de stage, et ça marche pas si mal avec un très bon stagiaire. Le soucis c'est que quand on en mets un pas très débrouillard, bah ça donne pas grand chose, normal après tout :p

          • [^] # Re: Tu m'excuseras de rire...

            Posté par . Évalué à 4.

            car si beaucoup ont encore du mal à avoir une vrai PKI :)

            C'est peut être plus simple de gérer un ensemble de clef PGP ? (je sais pas)

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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