Grafana: Grafana 2.0 : Source de données SQL

Je suggérerais personnellement quelque chose de plus dans la lignée de Cassandra (CQL) ou SparkSQL

Wow, cela nous est très utile.

• ajouter un tableau de serveurs db pour l'équilibrage de charge
• un champ qui concatène un LIMIT X à la requête
• un switch pour ORDER BY ASC DESC
• choisi les colonnes db pour TIME et pour VALUE de la table mysql ?

@phagedorn certains comme ça, pas sûr du commutateur pour l'ordre asc/desc, grafana les veut toujours dans l'ordre croissant (par temps). pas sûr de la limite x non plus.

plus comme un modèle de requête métrique (écrit par l'utilisateur lorsqu'il ajoute la source de données), ce n'est qu'un exemple, je n'y ai pas encore beaucoup réfléchi.

SELECT MyValue as Value, Timestamp as Time 
  FROM MyMetrics
  WHERE SeriesName IN (?SeriesList) AND Time > (?TimeFrom) AND Time < (?TimeTo)
  ORDER BY Timestamp ASC 

@syepes Je pense comme première étape pour mettre en œuvre quelque chose de simple. Pourriez-vous décrire davantage ce qu'il faudrait pour implémenter CQL ou SparkSQL au-dessus d'une base de données SQL générique et quels avantages ? SparkSQL semble intéressant du point de vue analytique, une implémentation de golang ?

+1 pour autoriser le SQL brut

@torkelo : Les modèles de requête sonnent bien :+1:
Fonctionnerait pour moi pour les tables existantes

Cette source de données aura-t-elle un éditeur de suggestions ? Quels backends de base de données pour cette source de données peuvent être utilisés ?

également intéressé à autoriser le SQL brut

Initialement mysql et postgres, aucune saisie semi-automatique ne sera incluse initialement

intéressé +1

:+1: pour postgres

:+1: pour postgres

:+1: pour postgres avec type JSON

:+1: pour postgres avec type JSON

Une idée de la feuille de route lorsque la source de données SQL sera disponible ? En 2.0 ou 2.1 ?

@juliusloman pas sûr, peut-être dans 2.2 ou 2.3, tellement d'autres choses qui ont été mises à 2.1 qui doivent d'abord se produire

Mais un PR est toujours le bienvenu

Avoir une source de données SQL fera certainement de grafana un outil d'analyse de premier plan. J'aimerais beaucoup le voir. Torkel, désolé de ne pas être familier avec github, qu'est-ce que les relations publiques impliquent ?
+

@ hceylan97 cela implique que quelqu'un essaie de l'implémenter et le soumet en tant que demande d'extraction (c'est-à-dire un correctif de fonctionnalité), devrai le faire car j'aurai probablement plus de problèmes de priorité élevée pour le prochain quelques mois

à part vous, curieux de savoir si quelqu'un d'autre travaille là-dessus ?

:+1:

+1 mysql

@torkelo Je pourrais commencer un PR pour cela en attendant la quantité de travail attendue. J'adorerais découvrir comment créer de nouvelles sources de données afin que nous puissions en intégrer davantage dans Grafana. Pourriez-vous donner un aperçu de ce qui doit être fait pour ajouter une nouvelle source de données et du travail restant pour la prise en charge SQL générique ?

+1 Oracle

+1 MS SQL

:+1: pour postgres avec type JSON

+1 postgres / postgres avec type JSON

@torkelo ping à nouveau car cela a été repoussé de deux mois. J'aimerais ajouter un peu de support pour les nouvelles sources de données dans Grafana et j'aimerais un aperçu de la façon de le faire et de ce qui reste pour le support SQL générique (vous apprécierez certainement si je pouvais aussi sortir un PR :) )

@agilgur5 aucun travail n'a encore été fait à ce sujet

@torkelo et d0d995d ? En tout cas un récapitulatif serait très apprécié

@agilgur5 qui fonctionnait principalement sur le système de plug-in de source de données, rien de spécifique à une source de données SQL

+1 MS SQL !!!

avec MySQL en face vous pouvez insérer dans n'importe quel SGBD avec le moteur XA & Connect !

spécifier un modèle de requête métrique (essentiellement une requête SQL avec des paramètres)
spécifier un modèle de requête d'annotation

je me demande si cela est nécessaire? c'est peut-être des tracas supplémentaires que nous pouvons éviter.
ne suffit-il pas de spécifier la table et les colonnes lors de l'utilisation de la DS ? ou peut-être spécifiez la table dans le DS afin que vous n'ayez qu'à spécifier des colonnes lorsque vous l'utilisez. Je soupçonne qu'il y aura de nombreuses tables avec chacune seulement quelques colonnes.

C'est quoi l'ETA pour ça ?

@EliSnow https://github.com/grafana/grafana/milestones dit vers le 29 septembre. Cette fonctionnalité seule peut être effectuée avant cela, et il est également possible qu'elle soit repoussée (comme cela a déjà été le cas plusieurs fois). Quoi qu'il en soit, je ne pense pas qu'un travail soit fait à ce sujet avant la version 2.1.

+1 MS SQL ; +1 requête avec paramètres
En fait pourquoi je demande. Le moyen le plus simple de mettre des compteurs de performances sur la scène à partir de nombreuses fenêtres Windows est de configurer des collecteurs de données sur eux pour mettre les données directement dans MS SQL sans aucun "collecteur intermédiaire". Ce serait donc vraiment génial d'avoir une option juste pour lire ces données à partir de MS SQL. Ce serait donc une très bonne option !

+1 - Postgres.

Postgres est juste une base de données phénoménale. Si j'ai le temps, je pourrais me pencher sur ce @torkelo

@torkelo , j'aimerais contribuer à ce que cela soit fait. Je regarde le commit référencé précédemment pour le système de plugin de source de données (d0d995d). Existe-t-il de la documentation pour le système de plugins ? Quelles pièces sont nécessaires ? En regardant d'autres sources de données dans le répertoire /public/app/plugins/datasource , il semble qu'il s'agisse simplement de Javascript (Angular + AMD) et de quelques modèles HTML. Un code Go est-il requis pour que cela fonctionne ou s'agit-il strictement de Javascript ?

Étant donné que les bases de données SQL n'ont généralement pas d'API http, il devra y avoir du code backend go

+1 MySQL et Cassandre

C'est un peu hors sujet, mais je pense que c'est une bonne étape (ou une étape alternative) vers l'obtention d'une source de données SQL. Ce serait formidable de permettre à un utilisateur administrateur, à partir de l'interface utilisateur, d'ajouter une source de données HTTP personnalisée.

L'utilisateur admin peut spécifier l'url de base et une fonction javascript qui transforme une requête en une véritable requête http. Ils pourraient également fournir des fonctions de mappage javascript qui transformeraient les données renvoyées par la requête http en un format commun compris par grafana. Finalement, il pourrait y avoir une interface permettant aux utilisateurs de créer leur propre générateur de requêtes d'interface utilisateur, ce qui pourrait permettre des conseils, etc. L'un des éléments les plus importants de ceci est qu'il doit être bien documenté.

Pourquoi est-ce pertinent pour ce problème? Certaines personnes peuvent choisir d'avoir leur base de données SQL accessible via un point de terminaison HTTP plutôt que d'autoriser un accès direct. Peut-être que grafana n'est pas sur le même réseau que la base de données et qu'il n'a pas d'accès direct pour des raisons de sécurité. Même si la base de données est directement accessible et que l'utilisateur peut fournir du SQL brut, il reste le problème selon lequel, compte tenu d'une requête SQL arbitraire, grafana ne saura pas dans quel format les données sont renvoyées et les fonctions de mappage javascript seront toujours nécessaires. (peut-être au niveau graphique/tableau de bord).

Pour éviter XSS, nous ne voulons peut-être pas qu'un utilisateur non administrateur modifie un tableau de bord et fournisse des fonctions javascript qui seront exécutées sur la page. Cela pourrait être évité en exigeant que les requêtes SQL renvoient des données dans un format spécifié. Alternativement, XSS pourrait peut-être être atténué par CSP.

Je reconnais qu'une personne déterminée peut actuellement ajouter une source de données HTTP personnalisée en modifiant le code source, mais c'est plus difficile car : 1) ce n'est pas documenté (à ma connaissance) et 2) cela nécessite que différentes personnes soient impliqué, en assumant une position où les rôles "devops" et "grafana admin" sont remplis par des personnes différentes.

Personnellement, j'ai pu ajouter une source de données SQL personnalisée via un point de terminaison HTTP qui imitait l'interface influxdb. Le générateur de requêtes permet à l'utilisateur de spécifier des requêtes arbitraires, j'avais juste besoin de m'assurer que mon point de terminaison renvoyait des données dans un format comme influxdb. C'est génial, mais c'est bidon et laisse beaucoup à désirer.

Des pensées, @torkelo?

@EliSnow - Voulez-vous partager le code ?

@roybass , je suppose que vous posez des questions sur mon code qui imite l'interface InfluxDB.

Je ne peux pas partager mon code spécifique, et cela ne serait probablement pas très utile si je le faisais car il est spécifique au langage que j'ai utilisé (Node.js), à ma base de données (Postgres) et à la structure de mes données (jsonb). L'essentiel de ce que vous devez faire est de créer un point de terminaison HTTP /query qui renvoie les données dans le même format qu'InfluxDB.

Grafana appellera votre point de terminaison à l'aide de la méthode GET avec le paramètre q de la chaîne de requête étant la ou les requêtes de recherche spécifiées dans votre panneau de tableau de bord. Chaque requête est délimitée par un caractère de nouvelle ligne. (Remarque : le bouton « Tester la connexion » pour tester votre source de données dans l'interface d'administration enverra la requête SHOW MEASUREMENTS LIMIT 1 . Si vous renvoyez un 204 pour cette requête, cela suffira). Vous pouvez concevoir la requête de recherche pour qu'elle soit votre propre DSL. J'ai fait de ma requête de recherche un simple objet JSON. Bien que vous puissiez certainement utiliser du vrai SQL pour votre requête de recherche, vous devez vous assurer que l'utilisateur de la base de données qui exécute la requête n'a l'autorisation que de SELECT sur des tables spécifiques. Pour moi, mes requêtes SQL sont assez longues et noueuses, et je préfère avoir un niveau d'abstraction de la base de données.

InfluxDB renvoie les données au format json [annoté] suivant :

{
//each entry in "results" represents the result of a single query
  "results": [{
    // each entry in "series" represents a different group if the
    // query had a GROUP BY clause.
    "series" : [
      {
        "name" : "measurement name",
        // not sure which tags influx chooses to return
        // perhaps only the ones in the WHERE clause
        // grafana allows you to use tags in the alias pattern
        "tags" : {
          "foo" : "bar"
        },
        // I have not checked grafana's source but it's possible
        // it does not read the "columns" array
        "columns" : ["time", "mean"],
        "values" : [
          // time (in epoch ms), value
          [1442953067791, 41.2]
        ]
      }
    ]
  }]
}

Si vous n'avez pas votre propre instance InfluxDB et que vous devez jouer avec la façon dont Grafana lui envoie des requêtes, vous pouvez utiliser le tableau de bord de test et vos outils de développement pour jeter un coup d'œil.

En guise d'avertissement, j'ai probablement manqué quelque chose dans la façon dont Grafana communique avec InfluxDB, mais ce qui précède était suffisant pour me lancer.

J'espère que cela pourra aider.

Merci! C'est exactement ce que je voulais dire

Le mardi 22 septembre 2015 à 23h57, EliSnow [email protected] a écrit :

@roybass https://github.com/roybass , je suppose que vous posez des questions sur
mon code qui imite l'interface InfluxDB.

Je ne peux pas partager mon code spécifique, et cela ne serait probablement pas très utile
si je l'ai fait parce que c'est spécifique au langage que j'ai utilisé (Node.js), mon
base de données (Postgres) et la structure de mes données (jsonb). L'essentiel de quoi
vous devez créer un point de terminaison HTTP /query qui renvoie des données dans le
même format qu'InfluxDB.

Grafana appellera votre point de terminaison en utilisant la méthode GET avec le paramètre q
de la chaîne de requête étant la ou les requêtes de recherche spécifiées dans votre
panneau de tableau de bord. Chaque requête est délimitée par un caractère de nouvelle ligne. (Noter:
que le bouton "Tester la connexion" pour tester votre source de données dans l'administrateur
l'interface enverra la requête SHOW MEASUREMENTS LIMIT 1. Si vous retournez un
204 pour cette requête, cela suffira). Vous pouvez concevoir la requête de recherche pour
être votre propre DSL. J'ai fait de ma requête de recherche un simple objet JSON. Pendant que tu
pourrait certainement utiliser du vrai SQL pour votre requête de recherche, vous devez vous assurer
l'utilisateur de la base de données exécutant la requête n'a l'autorisation de SELECTIONNER que sur
table(s) spécifique(s). Pour moi, mes requêtes SQL sont assez longues et noueuses, et je
préfèrent avoir un niveau d'abstraction de la base de données.

InfluxDB renvoie les données au format json [annoté] suivant :

{//chaque entrée dans "résultats" représente le résultat d'une seule requête
"résultats": [{
// chaque entrée dans "série" représente un groupe différent si le
// la requête avait une clause GROUP BY.
"séries" : [
{
"nom" : "nom de la mesure",
// pas sûr des balises que l'afflux choisit de renvoyer
// peut-être seulement ceux de la clause WHERE
// grafana permet d'utiliser des balises dans le modèle d'alias
"Mots clés" : {
"foo" : "bar"
},
// je n'ai pas vérifié les sources de grafana mais c'est possible
// il ne lit pas le tableau "colonnes"
"colonnes" : ["temps", "moyenne"],
"valeurs" : [
// heure (en époque ms), valeur
[1442953067791, 41.2]
]
}
]
}]
}

Si vous n'avez pas votre propre instance InfluxDB et que vous devez jouer
avec la façon dont Grafana lui envoie des requêtes, vous pouvez utiliser le tableau de bord de test
http://play.grafana.org et vos outils de développement pour jeter un coup d'œil.

En guise d'avertissement, j'ai probablement raté quelque chose dans la façon dont Grafana
communique avec InfluxDB, mais ce qui précède était suffisant pour me lancer.

J'espère que cela pourra aider.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-142419032 .

Les termes ci-dessus reflètent un accord commercial potentiel, sont fournis uniquement
comme base pour une discussion plus approfondie, et ne sont pas destinés à être et ne
constituent une obligation juridiquement contraignante. Aucune obligation juridiquement contraignante ne sera
être créé, implicite ou inféré jusqu'à ce qu'un accord sous sa forme finale soit signé
par écrit par toutes les parties concernées.

Cet e-mail et toutes ses pièces jointes peuvent être confidentiels ou privilégiés.
Si vous avez reçu cette communication par erreur, veuillez ne pas la transmettre à
quelqu'un d'autre, veuillez effacer toutes les copies et pièces jointes, et s'il vous plaît laissez-moi
sachez qu'il est allé à la mauvaise personne. Merci.

:+1: pour Postgres !

+1 pour SQLite

@roybass - votre message m'a donné une idée et j'ai fait un début très basique sur un proxy postgres - je n'ai pas encore pointé grafana dessus, mais j'espère que via des requêtes personnalisées d'afflux, il peut prétendre être un afflux mais est soutenu par postgres

désolé un lien serait utile : https://github.com/sysadminmike/postgres-influx-mimic

salut à tous ceux qui veulent se connecter à postgres - j'ai réussi à faire fonctionner ce qui précède et à avoir un exemple de graphique

+1 postgres / postgres de type JSONB
@EliSnow nous utilisons node, postgres, influxdb et grafana... si vous le pouvez, j'aimerais regarder votre code :)
@sysadminmike va vérifier !

:+1: MySQL

@RobMcZag, faites-moi savoir ce que vous en pensez - je l'ai utilisé pour configurer une idée de collecte de métriques distribuée : https://github.com/sysadminmike/yadms/

@torkelo , je ne sais pas comment, une source de données SQL évoluera avec des millions de points de données stockés chaque jour. Je peux convenir d'avoir une source de données comme Cassandra qui est hautement évolutive et impressionnante en termes de performances.

@utkarshcmu , je suppose qu'il est juste de dire que les bases de données relationnelles ne sont pas lentes par nature. Quoi qu'il en soit, même s'ils l'étaient, il peut toujours être intéressant d'extraire des données d'une petite table pour des annotations ou autre, donc les bases de données SQL sont une source de données très utile, si vous me le demandez.

quelle est la dernière sur sql comme source de données?

+1 Informix TimeSeries / Informix TimeSeries avec JSON
@utkarshcmu Informix est un exemple de la façon dont une base de données relationnelle objet peut prendre en charge une implémentation de données de séries chronologiques hautement évolutive via un type de données de séries chronologiques optimisé (les éléments de séries chronologiques peuvent être des types de données SQL et/ou des documents JSON). ;)

Bonjour,

Il est possible d'exporter les données numériques SQL via l'interface HTTP en utilisant une couche supplémentaire entre le serveur SQL et Grafana à l'aide d'ArrestDB : https://github.com/alixaxel/ArrestDB
Si quelqu'un pouvait forker le plugin à partir de celui basé sur HTTP existant, ce serait très bien. Personnellement, je ne suis pas un expert du codage Java ici et j'ai besoin d'aide pour cela.
Cela s'empilerait également parfaitement avec l'API Restful d'autres sources de données - https://restdb.io/docs/rest-api

+1

Salut, voici mon premier projet en go :
Collectez les métriques Microsoft SQL Server, envoyez-les à InfluxDB et visualisez avec Grafana
https://github.com/zensqlmonitor/influxdb-sqlserver

+1 à MySQL :)

+1 pour VoltDB [BD SQL en mémoire]

:+1:

Et jdbc ?

+1 MySQL

+1 MySQL

+1 PostgreSQL

+1 PostgreSQL

Source de données WIP SQL : https://github.com/grafana/grafana/pull/3964

+1 postgresql
Le 8 février 2016 à 22h00, "Tom Dyas" [email protected] a écrit :

Source de données WIP SQL : #3964 https://github.com/grafana/grafana/pull/3964

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-181722398 .

+1 Cassandre

Bonjour, quel est le statut d'une intégration de source de données SQL ? Pour nous, il est très intéressant de connecter grafana à Amazon Redshift ou Presto. Il pourrait y avoir la possibilité de mettre l'un de nos développeurs sur ce sujet. L'intégration SQL n'est-elle qu'un travail de codage ou des changements majeurs sont-ils nécessaires ?

J'avais un prototype de travail en cours dans PR https://github.com/grafana/grafana/pull/3964 en train de parler à Redshift de mon entreprise. Je pense donc que le codage fonctionne (de ma part ou de quelqu'un d'autre) à ce stade. Bien qu'il y ait plusieurs éléments répertoriés dans le PR qui devraient être accomplis avant de le rendre prêt pour la production.

+1 VoltDB

+1 Serait utile pour les annotations et les panneaux de texte.

+1

+1

J'exécute influxdb par proxy via grafana depuis un certain temps maintenant. En tant que passe-temps secondaire, je fouille avec un pare-feu d'application Web, et une chose à laquelle je serais vraiment désireux de trouver une solution est quelque chose qui s'apparente à des instructions préparées afin de préempter les injections SQL. À l'heure actuelle, j'ai une collection de diverses expressions régulières qui détectent les injections SQL, mais les affiner tout en conservant la capacité de déployer de nouveaux tableaux de bord empêche cela, ne me laissant pas d'autre option que de mettre à peu près la section des arguments sur liste blanche.
Conceptuellement, ce serait simple : publier des liens proxy fixes pour la collecte de données créés lors de la création/mise à jour du tableau de bord, plutôt que d'intégrer l'instruction de requête dans l'argument de l'URL. Côté proxy, tout ce que vous avez à faire est de le mapper sur la vraie requête, puis de l'envoyer au backend de la base de données.
Traiter cela via les parties proxy de grafana donne l'élégance supplémentaire de l'indépendance de la base de données pour pouvoir traiter les déclarations préparées.

:+1 : pour le concept/l'idée ainsi que la possibilité d'utiliser plus ou moins du SQL brut si vous souhaitez compléter les méthodes/fonctionnalités/métriques existantes

+1 pour postgresql/mysql

tous mes doigts levés pour postgres

+1

+1

+1. Vraiment besoin de ça !

+1

Des mises à jour à ce sujet ??

J'ai écrit une première preuve de concept que j'ai mise en place en tant que RP pour obtenir des commentaires : https://github.com/grafana/grafana/pull/3964. Le code a bien fonctionné pour les requêtes sur une instance PostgreSQL exécutée localement. Je ne sais pas si cela fonctionnerait toujours compte tenu des changements de code source dans Grafana sur le chemin de la v3.

Malheureusement, je n'ai plus le temps de travailler dessus car le projet interne qui aurait eu besoin d'une telle source de données, n'en a plus.

Étant donné que le code source de la preuve de concept est accessible au public dans le PR, il ne serait pas trivial (mais pas une grande quantité de travail) que quelqu'un d'autre prenne le relais. Si vous êtes un développeur, c'est un excellent moyen d'apprendre la base de code source Grafana. Si vous n'êtes pas un développeur, mais que vous avez de l'influence dans votre entreprise, je vous recommande de convaincre un développeur de votre organisation de travailler dessus.

Ce problème démontre vraiment le problème du "free rider" en open source. La "monnaie" de l'open source est le code (au sens le plus large) et le temps investi par les contributeurs dans ce code. Il me semble que tout le monde est heureux de donner un +1, mais très peu de gens contribuent ou utilisent leur influence pour convaincre quelqu'un dans leur organisation de contribuer.

Vous voulez influencer l'orientation du projet sur cette question ? Reprenez la preuve de concept, complétez-la et contribuez-la en retour, que ce soit en la faisant vous-même ou en allouant du temps à votre organisation (sous la forme d'un développeur) pour le faire. Cette attribution de temps est très certainement une dépense. Qui est prêt à « passer » le temps ?

Pour ma part, je suis prêt à répondre à toutes les questions sur la preuve de concept de la personne qui la reprend.

J'ai envoyé une pull request à ce sujet.

• https://github.com/grafana/grafana/pull/5168 "Ajouter la source de données du SGBDR (PostgreSQL et MySQL)"
• Vous pouvez voir le détail de ceci:
  https://github.com/anzai/grafana/wiki/SQL-DB-plugin-%28datasource%29

+1

+1 pour Postgres, mon lieu de travail aime déjà Grafana

Nous aimerions voir cela - comme référence https://github.com/sirensolutions/kibi est un "friendly-fork" de kibana et le support sql est l'une des fonctionnalités qu'ils ont ajoutées
https://github.com/sirensolutions/kibi/tree/master/src/plugins/kibi_core/lib/datasources

si cela aide.

+1 pour le support backend mysql/mariadb (nécessaire principalement pour creuser les bases de données de tickets GLPI/OTRS/etc...)

Les gars, s'il vous plaît, arrêtez de poster +1. Dites simplement merci à @anzai et appliquez https://github.com/grafana/grafana/pull/5364 à votre grafana local.

mysql et postgre est génial, Oracle ou jdbc générique serait génial (comme dans Kibi mentionné ci-dessus)

@Jimilian - le +1 est de l'

+1 pour cette fonctionnalité, surtout si elle prend en charge ODBC/JDBC

:+1: pour postgres!! :-)

J'ai adopté une autre approche pour afficher les données dans le SGBDR à l'aide de RestSQL. RestSQL permet les opérations CRUD sur les bases de données relationnelles et c'est une solution assez élégante pour activer les opérations de base de données à l'aide des méthodes HTTP et REST.

J'ai écrit un plugin Grafana pour RestSQL - plugin Grafana (3.x) pour RestSQL . Cependant, considérez-le comme un PoC pour le moment :-)

Dans ma configuration, aucune modification de la base de code Grafana n'est nécessaire. Cependant, cette configuration nécessite Java (Tomcat) pour que RestSQL fonctionne.

+1. Super POC @juliusloman .

+1. Ce serait vraiment génial pour Postgres !

+1 Postgres !
+1 requêtes SQL brutes

+1 pour Cassandre !

@juliusloman Ce serait génial si vous publiiez ce plugin sur grafana.net !

+1 MYSQL et POSTGRES avec des requêtes brutes

+1 Desserts !
+1 Cassandre !
+1 MySQL !

+1 Cassandre

+1 MySQL

+1 MS SQL !! :RÉ

Au lieu de créer N +1 commentaires, je suggère d'ajouter une balise :+1: à la première ligne mentionnant la base de données que vous voudriez avoir prise en charge ?

:+1:

+1 BigQuery.

Alors ce plugin va-t-il en version officielle ? J'aimerais avoir Postgres comme source de données.

+1 PostgreSQL

@all J'ai ouvert mon convertisseur de protocole InfluxDB-to-MySQL et je l'ai publié sur https://github.com/philip-wernersbach/influx-mysql , et il est prêt à fonctionner avec Grafana.

Je pense qu'une passerelle d'entrée JSON devrait suffire pour autoriser pratiquement n'importe quelle entrée SQL. J'écris le SQL à exécuter via le pilote approprié et le résultat JSON est consommé par grafana.

Les ensembles de données BigQuery en tant que backends configurables seraient absolument _ puissants _.

+1 MySQL

@envintus Si vous avez le temps de contribuer, j'aimerais avoir le support BigQuery dans https://github.com/philip-wernersbach/influx-mysql

SparkSQL +1

une mise à jour sur le plugin sql?

avoir un support SQL brut dans grafana en fera certainement le meilleur 👍
des mises à jour sur ce sujet?

Mon naïf essaie grafana-simple-sql-datasource !
AVIS DE NON-RESPONSABILITÉ : version bêta non polie et maladroite ... mais fonctionne pour moi 🤣

https://github.com/gbrian/grafana-simple-sql-datasource

@gbrian a l' air bien !

Je suis nouveau sur les proxys sql-js et j'ai une question.
Il existe différents packages pour différentes bases de données, comme MySql, MSSql, Postgress...
Est-il naïf de penser que votre implémentation fonctionnera avec différentes bases de données ?
Si oui, comment cela pourrait-il être résolu ? On dirait que nous avons besoin d'une sorte d'abstraction entre les deux...

@osigida , merci !

Oui, l'idée principale est d'avoir un fichier "xxxproxy.js" pour chaque source de données de type SQL.

Le suivant sur ma liste est Apache Drill (https://drill.apache.org/)
Si j'ai bien fait, cela devrait être compliqué comme créer le proxy et configurer le connecteur comme
http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port
bien sûr, la tâche consiste à convertir le schéma de la source de données en simple-sql.

Je serai heureux si vous le testez et me renvoyez des commentaires. Veuillez ouvrir autant de problèmes que vous trouvez et j'essaierai de les résoudre dès que possible.

Merci d'avance.

@gbrian Si vous envisagez d'implémenter Postgres. Je serai ravi de vous aider et de tester.

bon travail. ce sera aussi pour oracle ?

Envoyé via le Samsung Galaxy S® 6, un smartphone AT&T 4G LTE
-------- Message d'origine --------De : Gustavo Brian [email protected] Date : 16/02/17 4:00 AM (GMT-05:00) À : grafana/grafana [email protected] Cc : gsaray101 [email protected] , Commentaire [email protected] Objet : Re : [grafana/grafana] Grafana 2.0 : Source de données SQL (#1542)
@osigida , merci !
Oui, l'idée principale est d'avoir un fichier "xxxproxy.js" pour chaque source de données de type SQL.
Le suivant sur ma liste est Apache Drill (https://drill.apache.org/)

Si j'ai bien fait, cela devrait être compliqué comme créer le proxy et configurer le connecteur comme

http://simple-sql-server :port/?con= drill://drilluser:password@drill-server :port

bien sûr, la tâche consiste à convertir le schéma de la source de données en simple-sql.
Je serai heureux si vous le testez et me renvoyez des commentaires. Veuillez ouvrir autant de problèmes que vous trouvez et j'essaierai de les résoudre dès que possible.
Merci d'avance.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/grafana/grafana","title ":"grafana/grafana","subtitle":"Dépôt GitHub","main_image_url":" https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png " ,"avatar_image_url":" https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ","action":{"name":"Ouvrir dans GitHub", "url":" https://github.com/grafana/grafana "}},"updates":{"snippets":[{"icon":"PERSON","message":" @gbrian dans #1542 : @osigida , merci!\r\n\r\nOui, l'idée principale est d'avoir un fichier \"xxxproxy.js\" pour chaque source de données de type SQL.\r\n\r\nLe suivant sur ma liste est Apache Drill (https://drill.apache.org/)\r\nSi j'ai bien fait, cela devrait être simple comme créer le proxy et configurer le connecteur comme \r\n http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port \r\nbien sûr la tâche convertit le schéma de la source de données en simple-sql.\r\n\r\nJe serai heureux si vous le testez et me le renvoyez moi des commentaires. Veuillez ouvrir autant de problèmes que vous trouvez et j'essaierai de les résoudre dès que possible.\r\n\r\nMerci d'avance."}],"action":{"name":"Afficher le problème","url": " https://github.com/grafana/grafana/issues/1542#issuecomment -280272622"}}}

@anayrat , @gsaray101

Cela semble faisable et devrait être assez facile :
https://www.npmjs.com/package/pg
https://www.npmjs.com/package/strong-oracle

+1 MySQL

+1 MySQL

+1 Cassandre

+1 MSSQL +1 MYSQL

pour votre information

Il existe maintenant un plugin Oracle premium officiel (non gratuit)
https://grafana.com/plugins/grafana-oracle-datasource

https://github.com/grafana/grafana/pull/5364#issuecomment -290066384

HI @epizut : Ce plugin premium est en cours de développement dans le cadre de l'effort global. Le plugin premium tirera parti des fonctionnalités de base à venir.

Plus à venir ici!

Existe-t-il des limites connues à l'utilisation de cassandra comme source de données grafana ? Ou d'autres préoccupations dont il faut être conscient avant d'implémenter un plugin de source de données ?

Cassandra n'est pas une base de données de séries temporelles, donc je ne pense pas que vous puissiez l'utiliser comme
source de données dans grafana. J'utilise opentsdb pour ma source de données grafana

Le 19 mai 2017 à 10h28, "mtnxplorer7" [email protected] a écrit :

Existe-t-il des limitations connues à l'utilisation de cassandra en tant que données grafana
la source? Ou toute autre préoccupation dont il faut être conscient avant de mettre en œuvre un
plug-in de source de données ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-302763176 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ARG51ZdZ6qbzst8m7mx-tsSZ9cRoBe5Lks5r7dEggaJpZM4DndgD
.

Cassandra prend en charge la modélisation de données de séries chronologiques. Toute réflexion basée sur cela

+1 pour Apache Drill.

Je vois que la partie backend de ce PR a été fusionnée, mais quel est le statut global ? Existe-t-il un ETA pour un examen et une fusion de tout travail frontal nécessaire ?

Pour MySQL, il existe une partie backend et une partie frontend, avec prise en charge des alertes. Pas encore de support pour Postgres

La prise en charge de Postgres sera vraiment cool à utiliser avec http://www.timescale.com/.

J'aimerais voir la prise en charge de SQL pour athena : http://docs.aws.amazon.com/athena/latest/ug/what-is.html

@torkelo J'ai besoin d'aide avec la source de données MySQL. J'ai la dernière version de Grafana installée (v4.4.3)

Mon hôte grafana est supposé grafana.host.org et j'ai une base de données SQL pour une application qui est hébergée sur un hôte différent, disons application.host.org. J'ai mysql db sur le même application.host.org

Lorsque j'ajoute une nouvelle source de données de type MySQL sur grafana (c'est-à-dire grafana.host.org), il me demande des détails de connexion. J'y ajoute les détails suivants :

Hôte : application.host. org:3306
Base de données : nom_base
Utilisateur : dbuser
Mot de passe : dbpassword

Maintenant, lorsque j'enregistre et teste cette connexion, cela me donne une erreur disant :

"Erreur 1045 : Accès refusé pour l'utilisateur 'dbuser'@'grafana.host.org' (en utilisant le mot de passe : OUI)"

Des pistes sur une solution à cela? Pourquoi essaie-t-il d'accéder à grafana.host.org alors que j'ai spécifié l'hôte de base de données comme application.host.org ? Je peux me connecter de grafana.host.org à application.host.org très bien. Cependant cela me donne cette erreur.

Je crois comprendre qu'il devrait essayer de se connecter à la base de données sur application.host.org. Lorsque je me connecte à la base de données sur cet hôte sur le backend, je passe sans problème.

Votre aide avec thil sera très appréciée.

Merci,
Jyoti

Erreur 1045 : Accès refusé pour l'utilisateur 'dbuser'@'grafana.host.org' (en utilisant le mot de passe : OUI)

Cette erreur vient de MySQL. Il a reconnu que dbuser connecte _de_ l'adresse réseau qui se résout en grafana.host.org . Vérifiez les autorisations, le mot de passe, etc. sur MySQL.

Avez-vous des idées pour prendre en charge le dialecte Redshift SQL ?

Redshift SQL n'est que la famille Postgres 8.x, qui devrait être compatible avec le support Postgres récemment arrivé. Je ne l'ai pas encore essayé mais je suis également intéressé s'il y a des erreurs.

Si cela ne vous dérange pas de transmettre des données via postgres, vous pouvez connecter grafana à (presque) n'importe quelle base de données avec un wrapper de données étrangères postgres (https://wiki.postgresql.org/wiki/Foreign_data_wrappers).

+1 base de données Oracle

+1 pour MS SQL

+1 pour SQLite

salut, toute personne intéressée par mssql, veuillez vérifier pr #10093

Quelqu'un a-t-il travaillé sur Oracle comme source de données ? J'aimerais beaucoup le voir.

@gsaray101 et toute personne intéressée - contactez [email protected] si vous souhaitez tester la source de données Oracle bêta.

Nous avons fusionné la source de données Microsoft SQL Server avec Grafana et elle sera publiée dans Grafana 5.1 (#10093, #11298).

Cela signifie que Grafana prend désormais en charge dans le noyau MySQL, Postgres et MS SQL Server en tant que sources de données. Nous n'ajouterons plus de bases de données SQL en tant que sources de données au cœur de Grafana, il est donc enfin temps de clore ce problème.

Dans un avenir proche, nous aurons un support pour les plugins backend, il sera donc possible d'avoir d'autres sources de données SQL en tant que plugins externes.

Quelqu'un souhaite-t-il ajouter la prise en charge de DB2 LUW ?

@daniellee Qu'en est-il d'Oracle et de SQLite ? :thinking: Des nouvelles à ce sujet ?

@mnlbox Il existe déjà un plugin Oracle : https://grafana.com/plugins/grafana-oracle-datasource (Il n'est cependant pas open source)

Sqlite en tant que source de données n'est pas du tout dans notre carnet de commandes et je n'ai entendu personne travailler dessus.

+1 pour Bientôt

Une mise à jour sur SQLite @daniellee ?

La source de données SQLite serait très utile !

Sqlite !!!!!

Sqlite !!!!!

Sqlite !!!!!

Sqlite !!!!!

Veuillez utiliser la fonction 👍 pour montrer votre approbation et vos commentaires uniquement si vous pouvez fournir des informations supplémentaires, des notes utiles, des correctifs et des commentaires similaires - enfin - des commentaires aidant à résoudre le problème. Le spam des développeurs, des contributeurs ou des participants ne convaincra probablement personne de mettre en œuvre vos demandes.

Daniellee a déclaré ci-dessus qu'aucun effort supplémentaire n'est fait pour prendre en charge des sources de données supplémentaires dans le noyau et que les plugins sont la voie à suivre. De plus, personne ne semble avoir commencé à travailler sur SQLite jusqu'à présent. Si vous avez besoin d'une solution rapide et sale et que vous ne voulez pas écrire/commander/ adapter un plugin entier pour/à SQLite, il devrait être assez facile de créer un script proxy smapp pour servir vos données SQLite en tant que JSON similaire à doublemarkets RRD -Procuration . Ce n'est pas une excellente solution en termes de rapidité, mais vous n'utiliseriez probablement pas SQLite si c'était un problème.

Comme le dit @adlerweb , il n'y a actuellement aucun plan pour l'équipe principale de Grafana pour une source de données principale Sqlite. Je ne pense pas que nous accepterions un PR pour cela non plus. Cependant, nous publierions bien sûr un plugin de source de données externe sur grafana.com si quelqu'un l'écrivait.

Une mise à jour sur SQLite @daniellee ?

Pour ceux qui s'intéressent au support SQLite (ou en fait ceux qui attendent une source de données), vous n'avez pas besoin d'attendre longtemps. Il est assez facile d'écrire votre propre source de données en utilisant Python. La documentation est un peu clairsemée (voir https://github.com/grafana/simple-json-datasource), mais c'est possible. J'ai créé un exemple assez complet dans ce référentiel et un article de blog sur la façon de visualiser SQLite avec Grafana . Le référentiel comprend également un exemple fonctionnel de SQLite et une petite base de données pour cet exemple.

• Votez SQLite !

voter pour sqlite

Avec le backend vient la possibilité d'avoir une source de données SQL.

Je pense que lorsque vous ajoutez la source de données, vous

• type de base de données (initialement uniquement mysql et postgres et sqlite3)
• détails de connexion à la base de données
• spécifier un modèle de requête métrique (essentiellement une requête SQL avec des paramètres)
• spécifier un modèle de requête d'annotation

Peut-être aussi une option pour autoriser les requêtes SQL RAW à partir de l'interface de requête de métrique du panneau.

D'autres idées ?

Pour Sqlite

Votez pour sqlite.

Sqlite plsss