Forum général.cherche-logiciel Quel logiciel (libre) pour construire des tableaux de bord à partir de données SQL ?

5
12
nov.
2019

Bonjour,

Je souhaite mettre au point des tableaux de bord pour analyser les données d'une base de données SQL : nombre d'utilisateurs, dernière utilisation, etc. J'aimerais également pouvoir remonter des données provenant d'autres sources, par exemple : espace de stockage utilisé par client.

Je ne sais pas vers quel logiciel me tourner, ni même vers quel typologie de logicie… s'agit-il de BI (business intelligence) genre Talend Open Studio ? Autre chose ?

Mes besoins :

  • historiser des données basées sur une (ou plusieurs) requêtes SQL
  • récupérer les données sous forme tabulaire (fichier csv par exemple)
  • construire des graphiques
  • construire des modèles de rapport/tableau de bord dynamique (par exemple : une requête me donne la liste des clients, puis je construire un tableau de bord ou un export par client)

Merci pour vos éclairages.

  • # Grafana

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

    salut,

    Grafana peut, peut-être répondre à ton besoin ? il est capable d’interroger des serveurs SQL (exemple https://grafana.com/docs/features/datasources/mysql/ https://grafana.com/docs/features/datasources/postgres/ ou encore https://grafana.com/docs/features/datasources/mssql/ (avec des exemples de graphiques dans ce dernier))

  • # ReDash

    Posté par  . Évalué à 5. Dernière modification le 12 novembre 2019 à 15:54.

    A mon avis, il faut chercher du côté des "DashBoard".
    Je suis un utilisateur convaincu de Redash.

    • [^] # Re: ReDash

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

      J'avais vu ReDash mais pas perçu qu'il était libre. J'ai creusé vite fait et j'ai l'impression que c'est ce genre d'outil que je cherche.

      Merci pour la piste ; je reviens faire un retour après mon essai.

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

      • [^] # Re: ReDash

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Bon, je suis en train de tester reDash. Ca a l'air pas mal, par contre je ne trouve pas une fonctionnalité clé pour moi…

        J'ai une requête qui me permet de connaitre le nombre d'utilisateurs actifs à un moment donné. Cette requête me retourne simplement le nombre d'utilisateur ayant ajouté du contenu durant les 7 derniers jours ; le résultat est donc une unique valeur.

        J'aimerais que cette requête s'exécute chaque jour et obtenir le tableau résultat "date / nb".
        Je ne trouve pas comment récupérer l'ensemble des valeurs obtenues (et stockées ?) par redash et grapher à partir de ça.

        J'ai bien trouvé comment grapher des données datées en SQL, mais là, c'est différent ; j'ai peur que l'outil ne le permette pas… je me trompe ?

        #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

        • [^] # Re: ReDash

          Posté par  . Évalué à 1.

          Tu ne te trompes, ReDash n'est là que pour exploiter des données. Il ne gére pas le stockage.
          Un petit script SQL et une table ad-hoc devrait te permettre de résoudre proprement ce problème.

          • [^] # Re: ReDash

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Donc je ne me trompe pas : ReDash ne permet pas de faire ce que je veux. :-/

            Un petit script SQL et une table ad-hoc devrait te permettre de résoudre proprement ce problème.

            • une tâche cron. Sur un service de production c'est pas "juste une petite modification" ; je ne suis pas convaincu que modifier la base de données d'une application soit la bonne stratégie pour obtenir des métriques qui ne sont pas directement utiles pour ladite application. Pour moi le stockage de ces données doit être fait ailleurs ; peut-être alors une nouvelle base de données ? Ca devient compliqué s'il faut créer une nouvelle table + nouvelle tâche cron + nouveau script à chaque besoin "temporel" (genre voir l'évolution d'un contenu qui n'est pas historisé nativement par l'application)…

            D'après ce que j'ai réussi à glaner sur internet, il semblerait que les résultats soient stockés des requêtes soient stockés dans la base de données de ReDash, ça me semblerait naturel, donc, de pouvoir avoir ce genre de sortie.

            C'est aussi peut-être la différence entre un outil de tableau de bord et un outil de business intelligence… :-s

            Merci pour le retour.

            #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

            • [^] # Re: ReDash

              Posté par  . Évalué à 2.

              une tâche cron. Sur un service de production c'est pas "juste une petite modification" ; je ne suis pas convaincu que modifier la base de données d'une application soit la bonne stratégie pour obtenir des métriques qui ne sont pas directement utiles pour ladite application. Pour moi le stockage de ces données doit être fait ailleurs ; peut-être alors une nouvelle base de données ? Ca devient compliqué s'il faut créer une nouvelle table + nouvelle tâche cron + nouveau script à chaque besoin "temporel" (genre voir l'évolution d'un contenu qui n'est pas historisé nativement par l'application)…

              pourtant c'est exactement ce que va faire ton logiciel de BI/report
              si tu as des données existantes dans la base et qu'il faut juste agglomérer, additionner/calculer, il le fait en temps reel à la consultation.

              si tu veux des valeurs qui n'existent pas, il faut les produire et les stocker pour exploitation ultérieure :

              • soit tu les produits à coté (script + base de données séparées) et tu interroges cette base
              • soit tu les produits dans ta base de prod, dans une table permanente à part ou temporaire,
              • soit ton logiciel de BI le fait pour toi.
              • [^] # Re: ReDash

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                On est 100% d'accord ; ce que je veux c'est un logiciel qui le fasse pour moi :)

                #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

            • [^] # Re: ReDash

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

              Un outil de monitoring ?

              C'est exactement ce que je fais avec zabbix : j'ai créé une sonde qui remonte le résultat d'une requête SQL et zabbix s'occupe de stocker les valeurs et de les représenter. Avec possibilité de mettre des alarmes en cas de dépassement.

              • [^] # Re: ReDash

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                C'est ça, mais dans un cadre "tableau de bord business", pas infrastructure. C'est la même chose que je recherche, mais simple à utiliser et déployer, sachant que je n'ai pas un besoin de scalabilité, de milliers de sources de données, etc.

                #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

                • [^] # Re: ReDash

                  Posté par  . Évalué à 2.

                  C'est ça, mais dans un cadre "tableau de bord business", pas infrastructure

                  c'est la meme chose, que tu comptes les passages d'octets sur une carte réseau, le nombre de ticket de caisse produit ou le nombre d'entrée/sortie de la boutique, ca reste un compteur, un debit (+ ou - N elements depuis la dernière mesure)

                  ce sera infra si tu l'appelles ainsi ou BI si tu l'appelles comme ca.

                  du coup tu peux regarder tous les systèmes de monitoring ou de collection de data et de representation de ses datas (grafana je crois)

  • # Urungi

    Posté par  . Évalué à 4.

    • [^] # Re: Urungi

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Bien vu ! Je vais peut-être essayé, mais c'est vrai que la technologie de ReDash est plus proche de ce que nous utilisons au quotidien, du coup c'est plus tentant…

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

      • [^] # Re: Urungi

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Dis, Nonolapéro, sais-tu si Urungi permet de faire ce que j'évoque dans le commentaire précédent ?

        Si oui je vais y jeter un coup d'oeil.

        #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

        • [^] # Re: Urungi

          Posté par  . Évalué à 2. Dernière modification le 19 novembre 2019 à 10:07.

          Strictement aucune idée, je n’ai jamais utilisé Urungi. C’était juste un pointeur car je me souvenais vaguement de la dépêche.
          Dans ton cas, j’ai l’impression que tu as besoin d’un véritable outil de BI, ETL ou autre acronyme du genre dont le but est de faire de la consolidation de données dans une base dédiée et de remonter certains indicateurs.
          À toi de voir si l’artillerie lourde est pertinente ou dans un premier temps si stocker dans une base séparée quelques métriques et de les exploiter avec ReDash suffit à ton besoin.

          • [^] # Re: Urungi

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            L'avantage de ce fil de discussion, c'est que je sais ce que je recherche entre un tableau de bord et un outil de BI / ETL.

            Je pensais que ReDash aurait ce genre de fonctionnalité (j'avoue que je suis dubitatif sur les cas d'utilisation où tu fais des tableaux de bord sans aucune donnée consolidée)

            #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # Tableau ?

    Posté par  . Évalué à 1.

    • [^] # Re: Tableau ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Tableau n'a pas l'air libre, si ? Je n'ai pas trouvé le code source facilement…

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

Suivre le flux des commentaires

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