Facette, outil de visualisation de séries numériques

Posté par  . Édité par Benoît Sibaud. Modéré par rootix. Licence CC By‑SA.
Étiquettes :
31
29
juil.
2014
Supervision

Facette est un nouvel outil libre sous licence BSD permettant de réaliser des graphiques à partir de métriques collectées et stockées par divers outils tels que collectd, Graphite, InfluxDB. Cette alternative aux autres logiciels de visualisation permet de présenter sur les mêmes graphiques des séries de données numériques provenant de sources hétérogènes.

logo Facette

Facette est une application web développée en Go, par conséquent très facile à déployer et peu coûteuse en ressources système. L'interface web a été pensée pour permettre une utilisation simple et intuitive, et esthétiquement agréable — ce qui n'est pas toujours le cas des alternatives dans ce domaine ;-) Pour aller plus loin, le logiciel met également à disposition une API RESTful permettant par exemple de se servir de Facette "juste" pour fédérer plusieurs sources de données hétérogènes, ou encore d'automatiser certaines actions au niveau du catalogue interne.

Cette application ne fait pas de collecte ni de stockage de métriques : elle se contente d'interroger les sources des outils déjà mis en place afin de récupérer et afficher les données dans une interface unifiée.

Le projet est encore très jeune, toutefois l'équipe est très motivée à pousser l'outil très loin et a d'ores et déjà beaucoup d'idées pour la suite.

Aller plus loin

  • # Troll ?

    Posté par  . Évalué à 10.

    Facette est une application web développée en Go, par conséquent très facile à déployer et peu coûteuse en ressources système

    C'est pas gentil de se moquer de Java…

  • # Intéressant mais quid de Highcharts et sa licence?

    Posté par  (site web personnel) . Évalué à 8.

    Ce projet a l'air très intéressant et déjà bien documenté, bravo :)

    Mais (y a toujours un mais…) j'ai juste une question sur l'utilisation de la lib Highcharts pour les graphs. Si je ne m'abuse, cette lib n'est pas libre (cf www.highcharts.com/license) et gratuite que pour une utilisation non commerciale.

    Les personnes non averties qu'elles ont besoin d'une licence Highcharts se retrouveraient donc dans l'illégalité s'ils présentent une UI facette à leur clients par exemple, même si Facette est en BSD.

    Même si j'avoue que je suis aussi un grand fan de cette lib, est-ce que pour un outil libre, que l'on souhaite utilisable par tout le monde sans risque d'avocat and co, ne serait-il pas préférable de switcher vers un équivalent genre http://nvd3.org/ (avec un petit re-stylage car de base c'est moche…).

    Bravo en tout cas pour le projet, ça donne envie d'aller creuser dans ses métriques :D

  • # Bravo !

    Posté par  . Évalué à 2.

    Bientavu !(private joke inside)

    Quelle surprise de voir passer cette news, l'outil à bien grandi on dirait \o/
    Bonne continuation à vous.

    Bisous bisous
    F.

  • # Alternatives

    Posté par  (site web personnel) . Évalué à 3.

    Par curiosité comment compareriez vous Facette avec Grafana ?
    J'ai effectivement pas mal galéré pour trouver une IHM simple à mettre en oeuvre et sympa visuellement au dessus de notre OpenTSBD, et je dois avouer que je trouve celle ci assez puissante et simple à utiliser.

    • [^] # Re: Alternatives

      Posté par  . Évalué à 1.

      On ne se "compare" pas vraiment aux autres, à l'origine le projet Facette a commencé il y a plusieurs années — d'autres outils sont sortis entre-temps.

      Grafana est un pur front-end web en JavaScript, sans composant "serveur" ce qui fait qu'il est très largement dépendant des fonctionnalités exposées par les API des back-ends supportés (Graphite, OpenTSDB, InfluxDB), ou alors doit implémenter ce qui manque en JS ce qui peut être assez lourd niveau consommation de ressources du navigateur.

      Facette dispose d'une partie back-end qui lui permet d'effectuer des opérations complémentaires sur les séries de métriques (sommes, moyennes, statistiques etc.) provenant de sources différentes, par exemple des fichiers RRDtool de collectd et des métriques Carbon/Whisper de Graphite sur un même graphique.

      • [^] # Re: Alternatives

        Posté par  (site web personnel) . Évalué à 1.

        Gestion des droits ? Support https ?

        Je sais je suis un peu empêcheur de tourner en rond mais les aspects sécurité ne sont pas à oublier pour une adoption par les grandes entreprises… J'ai dernièrement monté une maquette mettant en œuvre du Shinken, du graphite, du grafana.

        Et à chaque fois sur ces outils le maillon faible c'était la gestion de la partie sécurité…

        Dans MongoDB, cela s'améliore… mais par défaut on est tjs dans un monde tout ouvert
        Elasticsearch, l'aspect sécu serait en prévision pour une version future.
        Pour Shinken, l'aspect sécu s'est un peu améliorée dans la V2, mais il y a eu qq échanges qui semblaient indiquer que c'était pas encore vraiment ça…
        Pour graphite, c'est bof, bof…

        etc

        Dans les banques et mêmes dans quelques grandes entreprises, on commence à regarder de vraiment beaucoup plus prêts ces aspects sécus…et les outils qui ne savent pas faire de la sécu par défaut seront de plus en plus exclus de ces entreprises.

        Et donc cet outil Facette a-t-il les mêmes défauts ?

        • [^] # Re: Alternatives

          Posté par  . Évalué à 4.

          En même temps, dans une grosse structure, les droits et le HTTPS seraient très probablement délégués à une couche à part, commune aux différentes applis web. Genre un LemonLDAP.

        • [^] # Re: Alternatives

          Posté par  . Évalué à 0.

          Dans les banques et mêmes dans quelques grandes entreprises, on commence à regarder de vraiment beaucoup plus prêts ces aspects sécus…et les outils qui ne savent pas faire de la sécu par défaut seront de plus en plus exclus de ces entreprises.

          Mwahahaha. Vu les courbes des budgets j'ai un léger doute.

        • [^] # Re: Alternatives

          Posté par  . Évalué à 4.

          Nous sommes partis du principe que Facette étant une webapp, elle peut — et devrait — bénéficier d'une sécurisation via une couche reverse-proxy HTTP tel qu'évoqué dans la documentation : Use Facette with a HTTP reverse-proxy.

          Du coup, HTTPS/authentification/gestion de rôles avec LDAP ou pas… c'est à la charge de l'administrateur système de sécuriser l'accès à l'application comme bon lui semble. Accessoirement, le logiciel dispose d'un mode "read only" afin de n'exposer à certaines population une version consultation seule, dans laquel il n'est pas possible de modifier les objets existants.

          • [^] # Re: Alternatives

            Posté par  (site web personnel) . Évalué à 6.

            J'avoue être du même avis. Toute les couches d'auth et de sécurisation devraient être factorisées plutôt que réimplémentées par chaque outil (avec ses failles potentielles). Quand on parle d'application web mettre un frontal pour gérer le https correctement est pas si mal par exemple, surtout que tu factorise tes connaissance et tes configurations entre les X outils, plutôt que voir comment on gère sur chacun.

          • [^] # Re: Alternatives

            Posté par  . Évalué à 0.

            Je suis d'accord. Il me semble également que c'est la bonne direction.

          • [^] # Re: Alternatives

            Posté par  . Évalué à 7.

            La problématique n'est pas sur l'identification ou l'authentification ni même la confidentialité.
            Ces fonctions peuvent être implémentées dans des outils tiers dont la robustesse est éprouvée comme les reverse proxies. Alors que l'outil de gestion de la donnée pourrait mal implémenter ces fonctions.

            La problématique est sur la gestion des accès à la donnée :
            Comment s'assurer que Paul, exploitant de l'application bidule, ne voit pas les métriques de l'application tartempion.
            Cela, il n'y a que l'outil de gestion de la donnée qui peut le gérer.

            • [^] # Re: Alternatives

              Posté par  (site web personnel) . Évalué à 4.

              Tout à fait juste.

              En gros la partie chiffrement et auth doit être gérée par un élément tiers, mais si l'appli reçoit comme information l’identité (vérifiée) alors elle doit l'appliquer comme un filtre supplémentaire.

              Le vrai soucis c'est pas trop de ce côté de la connexion en fait, car ça se fait assez bien peu importe le backend http utilisé. Mais ce qui est vraiment problématique pour les concepteurs c'est que ceci signifie qu'il faut avoir un mapping user<->objets, et ça à définir/maintenir c'est déjà rude d'un point de vue conceptuel, mais en plus ça va demander sûrement la création d'une UI de configuration et gestion. Or c'est pas vendeur lors d'un test pour attirer l'utilisateur, donc ils préfèrent laisser ça à plus tard :)

              • [^] # Re: Alternatives

                Posté par  . Évalué à 2.

                Tu peux aussi passer par un mapping user->profile->"droit sur l'objet".

                Il faudra administrer dans l'outil le mapping profile->droit. Mais cela ne devait pas changer autant que les users. Plutôt autant que les applications.

                Le mapping user->profile est pris en charge par les solutions d'IAM qui passent l'information de profile dans la requête, une fois l'utilisateur authentifié ; ou alors il faut faire une requête au système d'IAM pour avoir le profile de l'utilisateur ; mais le résultat est le même. Il y a des protocoles standardisés pour faire cela.

                • [^] # Re: Alternatives

                  Posté par  (site web personnel) . Évalué à 4.

                  Ca allège le soucis oui, mais c'est loin de régler correctement la maintenance. C'est ce qu'on fait dans les outils genre Nagios ou Shinken par exemple, la notion de groupes de contacts (aka ~profile). Mais ça reste très complexe quand tu as plusieurs milliers d'équipements sur X datacenters chacun avec ses équipes, et donc les éléments ont des métriques qui ne doivent être vue que par une partie des équipes (genre le infos systèmes par les sysadmin, les métriques oracle par les dba, etc etc).

                  Donc le mapping est vraiment d'un ordre de grandeur monstrueux si tu veux le maintenir à la main (infaisable dans les faits sur de grosses infras). Tu as donc aussi besoin de profile/groupe sur tous tes éléments (que ce soit les serveurs, c'est presque "facile", mais aussi sur tous les métriques qu'ils ont, et là c'est chaud).

                  Pour l'avoir géré dans Shinken (groupes, héritages de templates and co), je les comprends parfaitement de ne PAS s’embêter avec ça. Quand on voit que malgré ce manque énorme les outil sont quand même déployés chez de gros utilisateurs, tu relativise beaucoup l'importance de l'énormité du manque en fait :p

            • [^] # Re: Alternatives

              Posté par  . Évalué à -1.

              Comment s'assurer que Paul, exploitant de l'application bidule, ne voit pas les métriques de l'application tartempion.
              Cela, il n'y a que l'outil de gestion de la donnée qui peut le gérer.

              En autorisant Paul à accéder à /bidule/* seulement, /tartempion/* lui étant interdit ?

        • [^] # Re: Alternatives

          Posté par  . Évalué à 1. Dernière modification le 30 juillet 2014 à 09:06.

          Stunnel est ma réponse. Je n'aime pas les logiciels qui implémentent LEUR solution de sécurité qui sera forcément incomplète.

  • # QBE

    Posté par  . Évalué à 1.

    C'est très beau. Bravo.

    A chaque fois que je vois un outil de ce type, je me dis qu'il faudrait un système de requêtage pour les utilisateurs.

    Soit en QBE. On choisit des colonnes, on filtre, on trie. On peut faire plusieurs niveaux.

    Soit façon OLAP, Business Object ou Lotus Improv. Les colonnes sont des "dimensions". On les mets soit en abscisse, soit en ordonnée. Souvent avec du drag'n drop.

  • # Munin ?

    Posté par  . Évalué à 2. Dernière modification le 30 juillet 2014 à 12:01.

    Le projet a vraiment l'air sympa, j'essaie de le faire parler avec les rrd générés par Munin mais cela ne semble pas fonctionner.

    J'ai crée un fichier de ressource pour mes RRD 

    {
    "connector": {
        "type": "rrd",
        "path": "/var/lib/munin/desktop",
        "pattern": "(?P<source>[^/]+)/(?P<metric>.+).rrd"
    }

}

    Mais ils ne semblent pas être pris en compte…

  • # Utile ailleurs?

    Posté par  . Évalué à 1.

    Voilà un outil intéressant: je me demande si on ne pourrait pas l'utiliser par exemple pour de la visualisation scientifique, histoire de faire de l'exploration graphique de données.

    • [^] # Re: Utile ailleurs?

      Posté par  . Évalué à 3.

      Absolument, il n'y a aucune contre-indication à cela :) Facette s'interface avec des outils de collecte/stockage de données numériques indexées sur le temps, que l'on affiche des Mbits/s, des requêtes/s ou n'importe quelle autre mesure physique/scientifique.

Suivre le flux des commentaires

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