Grafana: Grafana 2.0: fuente de datos SQL

Creado en 28 feb. 2015  ·  168Comentarios  ·  Fuente: grafana/grafana

Con el backend viene la posibilidad de tener una fuente de datos SQL.

Mi pensamiento es que cuando agrega la fuente de datos,

  • tipo db (inicialmente solo mysql y postgres y sqlite3)
  • detalles de la conexión db
  • especificar una plantilla de consulta métrica (básicamente una consulta SQL con parámetros)
  • especificar una plantilla de consulta de anotación

Quizás también sea una opción para permitir consultas SQL RAW desde la interfaz de consulta métrica del panel.

¿Alguna otra idea?

typfeature-request

Comentario más útil

+1 para SQLite

Todos 168 comentarios

Personalmente sugeriría algo más en la línea de Cassandra (CQL) o SparkSQL

Vaya, esto es muy útil.

  • agregue una matriz de servidores de base de datos para equilibrar la carga
  • un campo que concatena un LIMIT X a la consulta
  • un interruptor para ORDER BY ASC DESC
  • eligió columnas db para TIME y VALUE de la tabla mysql?

@phagedorn algunos así, no estoy seguro del cambio para el orden asc / desc, grafana siempre los quiere en orden ascendente (por tiempo). tampoco estoy seguro del límite x.

más como una plantilla de consulta métrica (escrita por el usuario cuando agregan la fuente de datos), esto es solo un ejemplo, todavía no he pensado mucho en esto.

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

@syepes pienso como primer paso para implementar algo simple. ¿Podría describir más qué se necesitaría para implementar CQL o SparkSQL sobre una base de datos SQL genérica y qué beneficios? SparkSQL parece interesante desde el punto de vista analítico, ¿alguna implementación de golang?

+1 para permitir SQL sin formato

@torkelo : Las plantillas de consulta suenan bien: +1:
Me funcionaría para tablas existentes

¿Esta fuente de datos tendrá un editor de sugerencias? ¿Qué backends de base de datos para esta fuente de datos se pueden utilizar?

también interesado en permitir SQL sin formato

Inicialmente mysql y postgres, no se incluirá ningún autocompletado inicialmente

interesado +1

: +1: para postgres

: +1: para postgres

: +1: para postgres con tipo JSON

: +1: para postgres con tipo JSON

¿Alguna idea sobre la hoja de ruta cuando la fuente de datos SQL estará disponible? ¿En 2.0 o 2.1?

@juliusloman no estoy seguro, tal vez en 2.2 o 2.3, muchas otras cosas que se agregaron a 2.1 que deben suceder primero

Pero un PR siempre es bienvenido

Tener una fuente de datos SQL definitivamente hará de grafana una herramienta analítica superior. Me encantaría verlo. Torkel, lo siento, no estoy familiarizado con github, ¿qué implican las relaciones públicas?
+

@ hceylan97 implica que alguien intenta implementarlo y lo envía como solicitud de extracción (es decir, parche de función), me encantaría implementar esto, pero no estoy seguro de cuándo tendré que hacerlo, ya que probablemente tendré más problemas de prio para el próximo par de meses

además de usted, ¿tiene curiosidad por saber si alguien más está trabajando en esto?

: +1:

+1 mysql

@torkelo Podría comenzar un PR para esto pendiente de la cantidad de trabajo esperada. Me encantaría descubrir cómo crear nuevas fuentes de datos para que podamos integrar más en Grafana. ¿Podría dar un resumen de lo que se debe hacer para agregar una nueva fuente de datos y el trabajo restante para la compatibilidad con SQL genérico?

+1 Oráculo

+1 MS SQL

: +1: para postgres con tipo JSON

+1 postgres / postgres con tipo JSON

@torkelo haciendo ping de nuevo, ya que se ha retrasado dos meses. Me gustaría agregar algo de soporte para nuevas fuentes de datos en Grafana y me encantaría un resumen de cómo hacerlo y lo que queda para el soporte de SQL genérico (estoy bastante seguro de que apreciaría si pudiera obtener un PR también :) )

@ agilgur5 aún no se ha trabajado en esto

@torkelo ¿y d0d995d? En cualquier caso, se agradecería mucho un resumen.

@ agilgur5 que fue principalmente un trabajo en el sistema de complementos de la fuente de datos, nada específico para una fuente de datos SQL

+1 MS SQL !!!

con MySQL al frente puedes insertarlo en cualquier SGBD con motor XA & Connect!

especificar una plantilla de consulta métrica (básicamente una consulta SQL con parámetros)
especificar una plantilla de consulta de anotación

me pregunto si esto es necesario tal vez sea una molestia adicional que podamos evitar.
¿No es suficiente especificar la tabla y las columnas cuando se utiliza DS? o quizás especificar la tabla en el DS para que solo tenga que especificar columnas cuando la utilice. Sospecho que habrá muchas tablas con solo unas pocas columnas.

¿Cuál es la ETA para esto?

@EliSnow https://github.com/grafana/grafana/milestones dice alrededor del 29 de septiembre. Esta función por sí sola podría realizarse antes de eso, y también existe la posibilidad de que se rechace (como ya ha sucedido algunas veces). Independientemente, no creo que se haga ningún trabajo en esto hasta después de la versión 2.1.

+1 MS SQL; +1 consulta con parámetros
En realidad, ¿por qué estoy preguntando? La forma más sencilla de poner en escena contadores de rendimiento desde numerosas ventanas es configurar recopiladores de datos en ellos para poner los datos directamente en ms sql sin ningún "recopilador de software intermedio". Por lo tanto, sería realmente bueno tener una opción para leer esos datos desde MS SQL. ¡Así que esta sería una gran opción!

+1 - Postgres.

Postgres es simplemente una base de datos fenomenal. Si tengo tiempo, podría investigar esto @torkelo

@torkelo , me gustaría contribuir a que esto se haga. Estoy mirando la confirmación mencionada anteriormente para el sistema de complemento de fuente de datos (d0d995d). ¿Existe alguna documentación para el sistema de complementos? ¿Qué piezas se necesitan? Mirando otras fuentes de datos en el directorio / public / app / plugins / datasource , parece ser solo Javascript (Angular + AMD) y algunas plantillas HTML. ¿Se requiere algún código Go para que esto funcione o es estrictamente Javascript?

Dado que las bases de datos SQL generalmente no tienen una API http, es probable que haya algún código backend go

+1 MySQL y Cassandra

Esto es algo fuera de tema, pero creo que es un buen paso (o paso alternativo) para obtener una fuente de datos SQL. Sería genial permitir que un usuario administrador, desde la interfaz de usuario, agregue una fuente de datos HTTP personalizada.

El usuario administrador puede especificar la URL base y una función de JavaScript que transforma una consulta en una solicitud http real. También podrían proporcionar funciones de mapeo de JavaScript que transformarían los datos devueltos desde la solicitud http en un formato común comprendido por grafana. Eventualmente, podría haber una interfaz para que las personas construyan su propio generador de consultas de IU que podría permitir sugerencias y demás. Una de las piezas más importantes de esto es que tiene que estar bien documentado.

¿Por qué es esto relevante para este tema? Algunas personas pueden optar por tener acceso a su base de datos SQL a través de un punto final HTTP en lugar de permitir el acceso directo. Quizás grafana no esté en la misma red que la base de datos y no tenga acceso directo por razones de seguridad. Incluso si se puede acceder directamente a la base de datos y el usuario puede proporcionar SQL sin procesar, todavía existe el problema de que, dada una consulta SQL arbitraria, grafana no sabrá en qué formato se devuelven los datos, y las funciones de mapeo de JavaScript seguirán siendo necesarias. (quizás a nivel de gráfico / tablero).

Para evitar XSS, quizás no queremos que ningún usuario que no sea administrador edite un panel y proporcione funciones de JavaScript que se ejecutarán en la página. Esto podría evitarse exigiendo que las consultas SQL devuelvan datos en un formato específico. Alternativamente, XSS quizás podría mitigarse a través de CSP.

Reconozco que una persona determinada puede agregar una fuente de datos HTTP personalizada editando el código fuente, pero esto es más desafiante porque: 1) no está documentado (que yo sepa) y 2) requiere que diferentes personas estén involucrados, asumiendo una persona en una posición donde los roles "devops" y "grafana admin" son cumplidos por diferentes personas.

Personalmente, pude agregar una fuente de datos SQL personalizada a través de un punto final HTTP que imitaba la interfaz influxdb. El generador de consultas permite al usuario especificar consultas arbitrarias, solo necesitaba asegurarme de que mi punto final devolviera datos en un formato como influxdb. Es genial, pero es hacky y deja mucho que desear.

Pensamientos, @torkelo?

@EliSnow - ¿Te importaría compartir el código?

@roybass , supongo que estás preguntando por mi código que imita la interfaz InfluxDB.

No puedo compartir mi código específico, y probablemente no sería muy útil si lo hiciera porque es específico del lenguaje que utilicé (Node.js), mi base de datos (Postgres) y la estructura de mis datos (jsonb). La esencia de lo que debe hacer es crear un extremo HTTP /query que devuelva datos en el mismo formato que lo hace InfluxDB.

Grafana llamará a su punto final usando el método GET con el parámetro q de la cadena de consulta siendo la consulta de búsqueda / consultas especificadas en su panel de control. Cada consulta está delimitada por un carácter de nueva línea. (Nota: el botón "Probar conexión" para probar su fuente de datos en la interfaz de administración enviará la consulta SHOW MEASUREMENTS LIMIT 1 . Si devuelve un 204 para esa consulta, será suficiente). Puede diseñar la consulta de búsqueda para que sea su propio DSL. Hice mi consulta de búsqueda en un objeto JSON simple. Si bien ciertamente puede usar SQL real para su consulta de búsqueda, debe asegurarse de que el usuario de la base de datos que ejecuta la consulta solo tenga permiso para SELECT en tablas específicas. Para mí, mis consultas SQL son bastante largas y retorcidas, y prefiero tener un nivel de abstracción de la base de datos.

InfluxDB devuelve datos en el siguiente formato json [anotado]:

{
//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 no tiene su propia instancia de InfluxDB y necesita jugar con la forma en que Grafana envía sus consultas, puede usar el panel de prueba y sus herramientas de desarrollador para echar un vistazo.

Como descargo de responsabilidad, probablemente me he perdido algo en la forma en que Grafana se comunica con InfluxDB, pero lo anterior fue suficiente para comenzar.

Espero que ayude.

¡Gracias! Eso es exactamente lo que quise decir

El martes 22 de septiembre de 2015 a las 11:57 p.m., EliSnow [email protected] escribió:

@roybass https://github.com/roybass , supongo que estás preguntando sobre
mi código que imita la interfaz InfluxDB.

No puedo compartir mi código específico y probablemente no sería muy útil
si lo hice porque es específico del idioma que utilicé (Node.js), mi
base de datos (Postgres) y la estructura de mis datos (jsonb). La esencia de lo que
lo que debe hacer es crear un punto final HTTP / query que devuelva datos en el
mismo formato que hace InfluxDB.

Grafana llamará a su punto final usando el método GET con el parámetro q
de la cadena de consulta es la consulta de búsqueda / consultas especificadas en su
panel del tablero de instrumentos. Cada consulta está delimitada por un carácter de nueva línea. (Nota:
que el botón "Probar conexión" para probar su fuente de datos en el administrador
La interfaz enviará la consulta MOSTRAR LÍMITE DE MEDIDAS 1. Si devuelve un
204 para esa consulta será suficiente). Puede diseñar la consulta de búsqueda para
sea ​​su propio DSL. Hice mi consulta de búsqueda en un objeto JSON simple. Mientras tu
ciertamente podría usar SQL real para su consulta de búsqueda, debe asegurarse
el usuario de la base de datos que ejecuta la consulta solo tiene permiso para SELECCIONAR en
tabla (s) específica (s). Para mí, mis consultas SQL son bastante largas y retorcidas, y
prefiero tener un nivel de abstracción de la base de datos.

InfluxDB devuelve datos en el siguiente formato json [anotado]:

{// cada entrada en "resultados" representa el resultado de una sola consulta
"resultados": [{
// cada entrada en "serie" representa un grupo diferente si el
// la consulta tenía una cláusula GROUP BY.
"serie": [
{
"nombre": "nombre de la medición",
// no estoy seguro de qué etiquetas elige devolver la afluencia
// quizás solo los que están en la cláusula WHERE
// grafana te permite usar etiquetas en el patrón de alias
"etiquetas": {
"foo": "bar"
},
// No he comprobado la fuente de grafana pero es posible
// no lee la matriz de "columnas"
"columnas": ["tiempo", "medio"],
"valores" : [
// tiempo (en época ms), valor
[1442953067791, 41,2]
]
}
]
}]
}

Si no tiene su propia instancia de InfluxDB y necesita jugar
sobre cómo Grafana envía sus consultas, puede usar el panel de prueba
http://play.grafana.org y sus herramientas de desarrollo para echar un vistazo.

Como descargo de responsabilidad, probablemente me he perdido algo en cómo Grafana
se comunica con InfluxDB, pero lo anterior fue suficiente para comenzar.

Espero que ayude.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment -142419032.

Los términos anteriores reflejan un posible acuerdo comercial, se proporcionan únicamente
como base para una discusión adicional, y no pretenden ser ni
constituyen una obligación legalmente vinculante. Ninguna obligación legalmente vinculante
ser creado, implícito o inferido hasta que se ejecute un acuerdo en forma final
por escrito por todas las partes involucradas.

Este correo electrónico y cualquier archivo adjunto al mismo pueden ser confidenciales o privilegiados.
Si recibió esta comunicación por error, no la reenvíe a
cualquier otra persona, borre todas las copias y archivos adjuntos, y permítame
sepa que ha ido a la persona equivocada. Gracias.

: +1: ¡para Postgres!

+1 para SQLite

@roybass : su publicación me ha dado una idea y he tenido un comienzo muy básico en un proxy de postgres; en realidad, todavía no lo he señalado a grafana, pero espero que a través de consultas personalizadas de influjo pueda pretender ser influjo pero está respaldado por postgres

lo siento, un enlace sería útil: https://github.com/sysadminmike/postgres-influx-mimic

hola a todos los que quieran conectarse a postgres: he logrado que lo anterior funcione y tenga un gráfico de ejemplo

+1 postgres / postgres con tipo JSONB
@EliSnow usamos node, postgres, influxdb y grafana ... si puedes, me gustaría ver tu código :)
¡@sysadminmike lo comprobará!

: +1: MySQL

@RobMcZag déjeme saber lo que piensa; lo he usado para configurar una idea de colección de métricas distribuidas: https://github.com/sysadminmike/yadms/

@torkelo , no estoy seguro de cómo, una fuente de datos SQL escalará con millones de puntos de datos almacenados todos los días. Puedo estar de acuerdo en tener una fuente de datos como Cassandra, que es altamente escalable y tiene un rendimiento increíble.

@utkarshcmu , creo que es justo decir que las bases de datos relacionales no son lentas por naturaleza. De todos modos, incluso si lo fueran, aún puede ser atractivo extraer datos de una pequeña tabla para anotaciones o lo que sea, por lo que las bases de datos SQL son una fuente de datos muy útil, si me preguntas.

¿Qué es lo último en SQL como fuente de datos?

+1 Informix TimeSeries / Informix TimeSeries con JSON
@utkarshcmu Informix es un ejemplo de cómo una base de datos relacional de objetos puede admitir una implementación de datos de series de tiempo altamente escalable a través de un tipo de datos de series de tiempo optimizado (los elementos de series de tiempo pueden ser tipos de datos SQL y / o documentos JSON). ;)

Hola,

Existe la posibilidad de exportar datos numéricos SQL a través de la interfaz HTTP utilizando una capa adicional entre el servidor SQL y Grafana con la ayuda de ArrestDB: https://github.com/alixaxel/ArrestDB
Si alguien pudiera bifurcar un complemento del existente basado en HTTP, sería muy bueno. Personalmente, no soy un experto en codificación Java aquí y necesito ayuda con esto.
Esto también se combinaría muy bien con Restful API de otras fuentes de datos: https://restdb.io/docs/rest-api

+1

Hola, aquí está mi primer proyecto en marcha:
Recopile métricas de Microsoft SQL Server, envíelas a InfluxDB y visualice con Grafana
https://github.com/zensqlmonitor/influxdb-sqlserver

+1 a MySQL :)

+1 para VoltDB [In-Memory SQL DB]

: +1:

¿Qué tal jdbc?

+1 MySQL

+1 MySQL

+1 PostgreSQL

+1 PostgreSQL

+1 postgresql
El 8 de febrero de 2016 a las 22:00, "Tom Dyas" [email protected] escribió:

Fuente de datos WIP SQL: # 3964 https://github.com/grafana/grafana/pull/3964

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment -181722398.

+1 Cassandra

Hola, ¿cuál es el estado de la integración de una fuente de datos SQL? Para nosotros es de gran interés conectar grafana a Amazon Redshift o Presto. Podría existir la opción de poner a uno de nuestros desarrolladores sobre este tema. ¿La integración de SQL es solo un trabajo de codificación o se requieren cambios importantes?

Tenía un prototipo de trabajo en progreso en PR https://github.com/grafana/grafana/pull/3964 hablando con Redshift de mi empresa. Así que creo que solo la codificación funciona (de mi parte o de otra persona) en este momento. Aunque hay varios elementos enumerados en el RP que deberían cumplirse antes de que esté listo para producción.

+1 VoltDB

+1 Sería útil para anotaciones y paneles de texto.

+1

+1

He estado ejecutando influxdb proxy a través de grafana por un tiempo. Como un pasatiempo secundario, estoy hurgando con un firewall de aplicaciones web, y una cosa a la que me gustaría encontrar una solución es algo similar a las declaraciones preparadas para adelantarme a las inyecciones de SQL. En este momento, tengo una colección de varias expresiones regulares que detectan inyecciones de sql, pero ajustarlas mientras conservo la capacidad de implementar nuevos paneles de control prácticamente lo previene, y no me deja otra opción que incluir en la lista blanca la sección de argumentos.
Conceptualmente, sería simple: publicar enlaces proxy fijos para la recopilación de datos creados cuando se crea / actualiza el tablero, en lugar de tener la declaración de consulta incrustada en el argumento de la URL. Todo lo que tendría que hacer en el lado del proxy es asignarlo a la consulta real y luego enviarlo al backend de la base de datos.
Lidiar con esto a través de las partes proxy de grafana brinda la elegancia adicional de la independencia de la base de datos para poder manejar declaraciones preparadas.

: +1: para el concepto / idea, así como la capacidad de usar SQL más o menos sin procesar si desea complementar los métodos / características / métricas existentes

+1 para postgresql / mysql

todo mis dedos levantado para postgres

+1

+1

+1. ¡Realmente necesito esto!

+1

¿Alguna actualización sobre esto?

Escribí una prueba de concepto inicial que presenté como PR para obtener comentarios: https://github.com/grafana/grafana/pull/3964. El código funcionó bien para consultas en una instancia de PostgreSQL que se ejecuta localmente. No sé si todavía funcionaría dados los cambios en el código fuente en Grafana en el camino a v3.

Desafortunadamente, ya no tengo tiempo para trabajar en él porque el proyecto interno que habría necesitado tal fuente de datos, ya no lo hace.

Dado que el código fuente para la prueba de concepto está disponible públicamente en el PR, no sería trivial (pero no una gran cantidad de trabajo) que alguien más se hiciera cargo. Si es un desarrollador, esta es una excelente manera de aprender la base del código fuente de Grafana. Si no es un desarrollador, pero tiene influencia en su empresa, le recomiendo que convenza a un desarrollador de su organización para que trabaje en ello.

Este problema realmente demuestra el problema del "usuario gratuito" en el código abierto. La "moneda" del código abierto es el código (en su sentido más amplio) y el tiempo invertido por los contribuyentes en ese código. Me parece que todos están felices de dar un +1, pero muy pocas personas contribuyen o usan su influencia para convencer a alguien en su organización de que contribuya.

¿Quiere influir en la dirección del proyecto en este tema? Asuma la prueba de concepto, complétela y contribuya con ella, ya sea haciéndola usted mismo o asignando el tiempo de su organización (en forma de desarrollador) para hacerlo. Esa asignación de tiempo es definitivamente un gasto. ¿Quién está dispuesto a "gastar" el tiempo?

Por mi parte, estoy dispuesto a responder cualquier pregunta sobre la prueba de concepto de quien se haga cargo.

Envié una solicitud de extracción de esto.

+1

+1 para Postgres, mi lugar de trabajo ya ama a Grafana

Nos encantaría ver esto: como referencia https://github.com/sirensolutions/kibi es una "bifurcación amigable" de kibana y la compatibilidad con sql es una de las características que han agregado.
https://github.com/sirensolutions/kibi/tree/master/src/plugins/kibi_core/lib/datasources

si esto ayuda.

+1 para soporte de backend mysql / mariadb (necesario principalmente para excavar bases de datos de tickets GLPI / OTRS / etc ...)

Chicos, por favor, dejen de publicar +1. Solo da las gracias a @anzai y aplica https://github.com/grafana/grafana/pull/5364 a tu grafana local.

mysql y postgre son increíbles, Oracle o jdbc genérico serían increíbles (como en Kibi mencionado anteriormente)

@Jimilian : el +1 es para

+1 para esta función, especialmente si es compatible con ODBC / JDBC

: +1: para postgres !! :-)

Tomé otro enfoque para mostrar datos en RDBMS usando RestSQL. RestSQL permite operaciones CRUD en bases de datos relacionales y es una solución bastante elegante para permitir operaciones de bases de datos utilizando métodos HTTP y REST.

Escribí un complemento de Grafana para RestSQL - Complemento de Grafana (3.x) para RestSQL . Sin embargo, considérelo como un PoC en este momento :-)

En mi configuración no se necesitan cambios en la base de código de Grafana. Sin embargo, esta configuración necesita Java (Tomcat) para que RestSQL funcione.

+1. Awesome POCO @juliusloman.

+1. ¡Sería genial para Postgres!

+1 Postgres!
+1 consultas SQL sin procesar

+1 para cassandra!

@juliusloman ¡ Sería genial si publicaras ese complemento en grafana.net!

+1 MYSQL y POSTGRES con consultas sin procesar

+1 Postres!
+1 Cassandra!
+1 MySQL!

+1 Cassandra

+1 MySQL

+1 MS SQL !! :D

En lugar de crear comentarios N +1, sugiero agregar una etiqueta: +1: a la primera línea que mencione la base de datos que le gustaría haber admitido.

: +1:

+1 BigQuery.

Entonces, ¿este complemento va a la versión oficial? Me gustaría tener Postgres como fuente de datos.

+1 PostgreSQL

@todos He abierto mi convertidor de protocolo InfluxDB a MySQL y lo he publicado en https://github.com/philip-wernersbach/influx-mysql , y está listo para trabajar con Grafana.

Creo que una puerta de enlace de entrada JSON debería ser suficiente para permitir prácticamente cualquier entrada de SQL. Escribo el SQL para que se ejecute a través del controlador adecuado, y grafana consume el JSON resultante.

Los conjuntos de datos de BigQuery como backends configurables serían absolutamente _ poderosos _.

+1 MySQL

@envintus Si tiene tiempo para contribuir, me encantaría contar con el soporte de BigQuery en https://github.com/philip-wernersbach/influx-mysql

sparkSQL +1

alguna actualización sobre el complemento sql?

tener soporte SQL sin formato en grafana definitivamente lo convertirá en el mejor 👍
alguna actualización sobre este tema?

¡Mi ingenuo intento grafana-simple-sql-datasource!
DESCARGO DE RESPONSABILIDAD: versión beta sin pulir y torpe ... pero funciona para mí 🤣

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

image

¡@gbrian se ve bien!

Soy nuevo en proxies sql-js y tengo una pregunta.
Existen distintos paquetes para distintas bases de datos, como MySql, MSSql, Postgress ...
¿Es ingenuo pensar que su implementación funcionará con diferentes bases de datos?
Si es así, ¿cómo se podría abordar esto? parece que necesitamos algo de abstracción en el medio ...

@osigida , gracias!

Sí, la idea principal es tener un archivo "xxxproxy.js" para cada fuente de datos similar a SQL.

El siguiente en mi lista es Apache Drill (https://drill.apache.org/)
Si lo hice bien, debería ser fácil crear el proxy y configurar el conector como
http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port
por supuesto, la tarea es convertir el esquema de la fuente de datos a simple-sql.

Me alegrará si lo prueba y me envía algunos comentarios. Abra todos los problemas que encuentre e intentaré solucionarlos lo antes posible.

Gracias por adelantado.

@gbrian Si planea implementar Postgres. Estaré encantado de ayudarte y probar.

buen trabajo. ¿Será esto también para Oracle?

Enviado a través del Samsung Galaxy S® 6, un teléfono inteligente AT&T 4G LTE
-------- Mensaje original -------- De: Gustavo Brian [email protected] Fecha: 16/02/17 4:00 AM (GMT-05: 00) Para: grafana / grafana [email protected] Cc: gsaray101 [email protected] , comentario [email protected] Asunto: Re: [grafana / grafana] Grafana 2.0: Fuente de datos SQL (# 1542)
@osigida , gracias!
Sí, la idea principal es tener un archivo "xxxproxy.js" para cada fuente de datos similar a SQL.
El siguiente en mi lista es Apache Drill (https://drill.apache.org/)

Si lo hice bien, debería ser fácil crear el proxy y configurar el conector como

http: // simple-sql-server : port /? con = drill: // drilluser: contraseña @ drill-server : puerto

por supuesto, la tarea es convertir el esquema de la fuente de datos a simple-sql.
Me alegrará si lo prueba y me envía algunos comentarios. Abra todos los problemas que encuentre e intentaré solucionarlos lo antes posible.
Gracias por adelantado.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / grafana / grafana", "title ":" grafana / grafana "," subtitle ":" Repositorio de 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": "Abrir en GitHub", "url": " https://github.com/grafana/grafana "}}, "updates": {"snippets": [{"icon": "PERSON", "message": " @gbrian in # 1542: @osigida , ¡gracias! \ r \ n \ r \ nSí, la idea principal es tener un archivo \ "xxxproxy.js \" para cada fuente de datos similar a SQL. \ r \ n \ r \ nEl siguiente en mi lista es Apache Drill (https://drill.apache.org/)\r\nSi lo hice bien, debería ser fácil crear el proxy y configurar el conector como \ r \ n http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port \ r \ npor supuesto, la tarea está convirtiendo el esquema de la fuente de datos a simple-sql. \ r \ n \ r \ nMe alegrará si lo prueba y me envía de vuelta me retroalimentación. Abra todos los problemas que encuentre e intentaré solucionarlos lo antes posible. \ R \ n \ r \ nGracias de antemano. "}]," Action ": {" name ":" Ver problema "," url ": " https://github.com/grafana/grafana/issues/1542#issuecomment -280272622"}}}

@anayrat , @ gsaray101

Parece factible y debería ser bastante fácil:
https://www.npmjs.com/package/pg
https://www.npmjs.com/package/strong-oracle

+1 MySQL

+1 MySQL

+1 Cassandra

+1 MSSQL +1 MYSQL

FYI

Ahora hay un complemento oficial premium de Oracle (no gratuito)
https://grafana.com/plugins/grafana-oracle-datasource

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

Hola @epizut : este complemento premium está en desarrollo como parte del esfuerzo general. El complemento premium aprovechará las próximas funciones principales.

¡Más por venir aquí!

¿Existe alguna limitación conocida del uso de cassandra como fuente de datos de grafana? ¿O cualquier otra inquietud que deba tener en cuenta antes de implementar un complemento de fuente de datos?

Cassandra no es una base de datos de series de tiempo, así que no creo que puedas usarla como
fuente de datos en grafana. Estoy usando opentsdb para mi fuente de datos grafana

El 19 de mayo de 2017 a las 10:28 a. M., "Mtnxplorer7" [email protected] escribió:

¿Existe alguna limitación conocida del uso de cassandra como datos de grafana?
¿fuente? O cualquier otra preocupación que uno deba tener en cuenta antes de implementar un
complemento de fuente de datos?

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-302763176 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ARG51ZdZ6qbzst8m7mx-tsSZ9cRoBe5Lks5r7dEggaJpZM4DndgD
.

Cassandra admite el modelado de datos de series de tiempo. Cualquier pensamiento basado en esto

+1 para Apache Drill.

Veo que la parte de backend de este PR se ha fusionado, pero ¿cuál es el estado general? ¿Existe una ETA para una revisión y fusión de cualquier trabajo frontend necesario?

Para MySQL hay una parte de backend y una parte de frontend, con soporte de alerta. Aún no hay soporte para Postgres

El soporte de Postgres será realmente genial de usar con http://www.timescale.com/.

Me encantaría ver el soporte de SQL para athena: http://docs.aws.amazon.com/athena/latest/ug/what-is.html

@torkelo Necesito ayuda con MySQL Datasource. Tengo instalada la última versión de Grafana (v4.4.3)

Supongamos que mi host de grafana es grafana.host.org y tengo una base de datos SQL para una aplicación que está alojada en un host diferente, digamos application.host.org. Tengo mysql db en la misma aplicación.host.org

Cuando agrego una nueva fuente de datos de tipo MySQL en grafana (es decir, grafana.host.org), me pregunta los detalles de la conexión. Le agrego los siguientes detalles:

Anfitrión: application.host. org: 3306
Base de datos: dbname
Usuario: dbuser
Contraseña: dbpassword

Ahora, cuando guardo y pruebo esta conexión, me da un error que dice:

"Error 1045: Acceso denegado para el usuario 'dbuser'@'grafana.host.org' (usando contraseña: SÍ)"

¿Alguna pista sobre una solución a esto? ¿Por qué está intentando acceder a grafana.host.org cuando he especificado el host de la base de datos como application.host.org? Puedo conectarme desde grafana.host.org a application.host.org bien. Sin embargo, me da este error.

Tengo entendido que debería intentar conectarse a la base de datos en application.host.org. Cuando me conecto a la base de datos en ese host en el backend, lo hago sin problemas.

Su ayuda será muy apreciada.

Gracias,
Jyoti

Error 1045: Acceso denegado para el usuario 'dbuser'@'grafana.host.org' (usando contraseña: SÍ)

Este error es de MySQL. Ha reconocido que dbuser está conectando _desde_ la dirección de red que se resuelve en grafana.host.org . Verifique los permisos, la contraseña, etc. en MySQL.

¿Alguna idea sobre la compatibilidad con el dialecto SQL de Redshift?

Redshift SQL es solo la familia Postgres 8.x, que debería ser compatible con el soporte Postgres recién lanzado. No lo he probado todavía, pero también me interesa si hay algún error.

Si no le importa transferir datos a través de postgres, puede conectar grafana a (casi) cualquier base de datos con contenedor de datos externos de postgres (https://wiki.postgresql.org/wiki/Foreign_data_wrappers).

+1 base de datos de Oracle

+1 para MS SQL

+1 para SQLite

hola, cualquiera interesado en mssql, por favor revise pr # 10093

¿Alguien ha trabajado en Oracle como fuente de datos? Me encantaría verlo.

@ gsaray101 y cualquier persona interesada: póngase en contacto con [email protected] si desea probar la fuente de datos beta de Oracle.

Hemos fusionado la fuente de datos de Microsoft SQL Server con Grafana y se lanzará en Grafana 5.1 (# 10093, # 11298).

Esto significa que Grafana ahora tiene soporte en el núcleo para MySQL, Postgres y MS SQL Server como fuentes de datos. No agregaremos más bases de datos SQL como fuentes de datos al núcleo de Grafana, por lo que finalmente es hora de cerrar este problema.

En un futuro cercano, tendremos soporte para complementos de backend, por lo que será posible tener otras fuentes de datos SQL como complementos externos.

¿Alguien está pensando en agregar soporte para DB2 LUW?

@daniellee ¿Qué pasa con Oracle y SQLite? : pensando: ¿Alguna noticia sobre esto?

@mnlbox Ya existe un complemento de Oracle: https://grafana.com/plugins/grafana-oracle-datasource (sin embargo, no es de código abierto)

Sqlite como fuente de datos no está en nuestra cartera de pedidos y no he oído hablar de nadie que trabaje en él.

+1 para Pronto

¿Alguna actualización sobre SQLite @daniellee ?

¡La fuente de datos SQLite sería muy útil!

Sqlite !!!!!

Sqlite !!!!!

Sqlite !!!!!

Sqlite !!!!!

Utilice la función 👍 para mostrar su aprobación y comentario solo si puede proporcionar información adicional, notas útiles, parches y comentarios similares que ayuden a resolver el problema. Enviar spam a los desarrolladores, colaboradores o participantes probablemente no convencerá a nadie para que implemente sus solicitudes.

Daniellee indicó anteriormente que no se han realizado más esfuerzos para admitir fuentes de datos adicionales en el núcleo y los complementos son el camino a seguir. Además, nadie parece haber comenzado a trabajar en SQLite hasta ahora. Si necesita una solución rápida y sucia y no desea escribir / encargar / adaptar un complemento completo para / a SQLite , debería ser algo fácil construir un script proxy smapp para servir sus datos SQLite como JSON similar a Doublemarkets RRD -Proxy . No es una gran solución en términos de velocidad, pero probablemente no usaría SQLite si eso le preocupa.

Como dice @adlerweb , actualmente no hay planes para el equipo central de Grafana para una fuente de datos Sqlite central. No creo que aceptemos un RP por ello tampoco. Sin embargo, por supuesto, publicaríamos un complemento de fuente de datos externa en grafana.com si alguien lo escribiera.

¿Alguna actualización sobre SQLite @daniellee ?

Para aquellos interesados ​​en el soporte de SQLite (o de hecho aquellos que esperan cualquier fuente de datos), no necesitan esperar mucho. Es bastante fácil escribir su propia fuente de datos usando Python. La documentación es un poco escasa (consulte https://github.com/grafana/simple-json-datasource), pero es posible. He creado un ejemplo bastante extenso en este repositorio y una publicación de blog sobre cómo visualizar SQLite con Grafana . El repositorio también incluye un ejemplo funcional de SQLite y una pequeña base de datos para este ejemplo.

  • ¡Voto SQLite!

votar por sqlite

Con el backend viene la posibilidad de tener una fuente de datos SQL.

Mi pensamiento es que cuando agrega la fuente de datos,

  • tipo db (inicialmente solo mysql y postgres y sqlite3)
  • detalles de la conexión db
  • especificar una plantilla de consulta métrica (básicamente una consulta SQL con parámetros)
  • especificar una plantilla de consulta de anotación

Quizás también sea una opción para permitir consultas SQL RAW desde la interfaz de consulta métrica del panel.

¿Alguna otra idea?

Para Sqlite

Vote por sqlite.

Sqlite plsss

¿Fue útil esta página
0 / 5 - 0 calificaciones