Grafana: Grafana 2.0: источник данных SQL

Созданный на 28 февр. 2015  ·  168Комментарии  ·  Источник: grafana/grafana

С бэкэндом появляется возможность иметь источник данных SQL.

Я думаю, что когда вы добавляете источник данных, вы

  • тип db (изначально только mysql, postgres и sqlite3)
  • детали подключения к базе данных
  • укажите шаблон запроса метрики (в основном SQL-запрос с параметрами)
  • указать шаблон запроса аннотации

Возможно, также есть возможность разрешить запросы RAW SQL из интерфейса запроса метрики панели.

Есть другие идеи?

typfeature-request

Самый полезный комментарий

+1 для SQLite

Все 168 Комментарий

Я бы лично посоветовал кое-что еще в линейке Cassandra (CQL) или SparkSQL.

Вау, это нам очень пригодилось.

  • добавить массив серверов db для балансировки нагрузки
  • поле, которое объединяет LIMIT X с запросом
  • переключатель для ORDER BY ASC DESC
  • выбрали столбцы db для TIME и VALUE из таблицы mysql?

@phagedorn некоторые из них не уверены в переключателе для порядка asc / desc, графана всегда хочет их в порядке возрастания (по времени). тоже не уверен в пределе x.

больше похоже на шаблон метрического запроса (написанный пользователем при добавлении источника данных), это просто пример, мы еще не задумывались об этом.

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

@syepes Я считаю первым шагом к реализации чего-то простого. Не могли бы вы подробнее описать, что потребуется для реализации CQL или SparkSQL поверх общей базы данных SQL и какие преимущества? SparkSQL выглядит интересно с точки зрения аналитики, есть ли реализация на golang?

+1 за разрешение необработанного SQL

@torkelo : шаблоны запросов звучат неплохо: +1:
Будет работать для меня для существующих таблиц

Будет ли в этом источнике данных редактор предложений? Какие бэкенды БД для этого источника данных можно использовать?

также заинтересован в разрешении необработанного SQL

Первоначально mysql и postgres, автозаполнение не будет изначально включено

заинтересован +1

: +1: для postgres

: +1: для postgres

: +1: для postgres с типом JSON

: +1: для postgres с типом JSON

Есть идеи о планах, когда будет доступен источник данных SQL? В 2.0 или 2.1?

@juliusloman не уверен, может быть, в 2.2 или 2.3, так много других вещей, которые были перенесены в 2.1, которые должны произойти в первую очередь

Но пиар всегда приветствуется

Наличие источника данных SQL определенно сделает grafana лучшим аналитическим инструментом. Я хотел бы видеть его. Торкель, извините не знаком с гитхабом, что за пиар влечет?
+

@ hceylan97 это влечет за собой то, что кто-то пытается его реализовать и запрос на перенос (то есть патч функции), я бы хотел реализовать это, но не уверен, когда мне придется это сделать, поскольку у меня, вероятно, будет больше проблем с высоким приоритетом для следующего Пару месяцев

Кроме вас, интересно, работает ли над этим кто-нибудь еще?

: +1:

+1 MySQL

@torkelo Я мог бы начать PR по этому поводу в ожидании ожидаемого объема работы. Хотелось бы выяснить, как создавать новые источники данных, чтобы мы могли больше интегрировать в Grafana. Не могли бы вы кратко рассказать о том, что нужно сделать, чтобы добавить новый источник данных, и о том, что осталось сделать для общей поддержки SQL?

+1 Oracle

+1 MS SQL

: +1: для postgres с типом JSON

+1 postgres / postgres с типом JSON

@torkelo снова

@ agilgur5 над этим еще не

@torkelo а что с d0d995d? В любом случае было бы очень полезно краткое изложение

@ agilgur5, который в основном работал над системой плагинов источника данных, ничего специфичного для источника данных SQL

+1 MS SQL !!!

с MySQL впереди вы можете вставить в любой SGBD с движком XA & Connect!

укажите шаблон запроса метрики (в основном SQL-запрос с параметрами)
указать шаблон запроса аннотации

интересно, нужно ли это? может быть, нам удастся избежать лишних хлопот.
разве недостаточно указать таблицу и столбцы при использовании DS? или, возможно, укажите таблицу в DS, чтобы вам нужно было указать только столбцы при ее использовании. Я подозреваю, что будет много таблиц, в каждой из которых всего несколько столбцов.

Какое расчетное время прибытия для этого?

@EliSnow https://github.com/grafana/grafana/milestones говорит примерно 29 сентября. Одна только эта функция может быть реализована до этого, и есть также вероятность, что она будет отодвинута (как это уже было несколько раз). Тем не менее, я не верю, что работа над этим будет проводиться до выхода версии 2.1.

+1 MS SQL; +1 запрос с параметрами
Собственно, почему я спрашиваю. Самый простой способ разместить счетчики производительности на сцене из многочисленных оконных окон - это настроить на них сборщики данных, чтобы они помещали данные непосредственно в ms sql без каких-либо «сборщиков промежуточного программного обеспечения». Так что было бы действительно здорово иметь возможность читать эти данные из MS SQL. Так что это был бы действительно отличный вариант!

+1 - Постгрес.

Postgres - просто феноменальная БД. Если у меня будет время, я могу заглянуть в этот @torkelo

@torkelo , я хотел бы внести свой вклад в это. Я смотрю на коммит, упомянутый ранее для системы плагинов источника данных (d0d995d). Есть ли документация по системе плагинов? Какие штуки нужны? Глядя на другие источники данных в каталоге / public / app / plugins / datasource, кажется, что это просто Javascript (Angular + AMD) и некоторые шаблоны HTML. Требуется ли какой-либо код Go для работы или это строго Javascript?

Поскольку базы данных SQL обычно не имеют http api, может быть какой-то код backend go.

+1 MySQL и Кассандра

Это несколько не по теме, но я думаю, что это хороший шаг (или альтернативный шаг) на пути к получению источника данных SQL. Было бы здорово разрешить пользователю с правами администратора из пользовательского интерфейса добавить собственный источник данных HTTP.

Пользователь-администратор может указать базовый URL-адрес и функцию javascript, которая преобразует запрос в фактический HTTP-запрос. Они также могут предоставить функцию (-ы) сопоставления javascript, которая преобразует данные, возвращаемые из HTTP-запроса, в общий формат, понятный grafana. В конце концов, может появиться интерфейс для создания собственного конструктора запросов пользовательского интерфейса, позволяющего делать подсказки и тому подобное. Одна из самых важных частей этого - это то, что это должно быть хорошо задокументировано.

Почему это имеет отношение к данному вопросу? Некоторые люди могут предпочесть доступ к базе данных SQL через конечную точку HTTP, а не прямой доступ. Возможно, графана не находится в той же сети, что и база данных, и не имеет прямого доступа по соображениям безопасности. Даже если база данных доступна напрямую и пользователь может предоставить необработанный SQL, по-прежнему существует проблема, заключающаяся в том, что с учетом произвольного SQL-запроса grafana не будет знать, в каком формате возвращаются данные, и функции сопоставления javascript все равно потребуются (возможно, на уровне графика / панели инструментов).

Чтобы избежать XSS, возможно, мы не хотим, чтобы какой-либо пользователь, не являющийся администратором, редактировал панель управления и предоставлял функции javascript, которые будут выполняться на странице. Этого можно было бы избежать, потребовав, чтобы запросы SQL возвращали данные в указанном формате. В качестве альтернативы, XSS, возможно, можно было бы смягчить с помощью CSP.

Я понимаю, что решительный человек в настоящее время может добавить собственный источник данных HTTP, отредактировав исходный код, но это сложнее, потому что: 1) он не задокументирован (о чем я знаю), и 2) для этого требуются разные люди. вовлечены, предполагая, что человек находится в положении, в котором роли «DevOps» и «Grafana admin» исполняют разные люди.

Я лично смог добавить пользовательский источник данных SQL через конечную точку HTTP, которая имитировала интерфейс infxdb. Конструктор запросов позволяет пользователю указывать произвольные запросы, мне просто нужно было убедиться, что моя конечная точка возвращает данные в формате, подобном Infxdb. Это здорово, но это взломано и оставляет желать лучшего.

Мысли, @torkelo?

@EliSnow - не могли бы вы поделиться кодом?

@roybass , я

Я не могу поделиться своим конкретным кодом, и, вероятно, было бы не очень полезно, если бы я это сделал, потому что он зависит от языка, который я использовал (Node.js), моей базы данных (Postgres) и структуры моих данных (jsonb). Суть того, что вам нужно сделать, это создать конечную точку HTTP /query которая возвращает данные в том же формате, что и InfluxDB.

Grafana вызовет вашу конечную точку с помощью метода GET с параметром q строки запроса, являющейся поисковым запросом / запросами, указанными на панели вашей панели инструментов. Каждый запрос отделяется символом новой строки. (Примечание: кнопка «Проверить соединение» для тестирования источника данных в интерфейсе администратора отправит запрос SHOW MEASUREMENTS LIMIT 1 . Если вы вернете 204 для этого запроса, этого будет достаточно). Вы можете создать поисковый запрос как собственный DSL. Я сделал свой поисковый запрос простым объектом JSON. Хотя вы, безусловно, можете использовать настоящий SQL для своего поискового запроса, вы должны убедиться, что пользователь базы данных, выполняющий запрос, имеет разрешение только на SELECT для определенных таблиц. Для меня мои SQL-запросы довольно длинные и грубые, и я предпочитаю иметь некоторый уровень абстракции от базы данных.

InfluxDB возвращает данные в следующем [аннотированном] формате json:

{
//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]
        ]
      }
    ]
  }]
}

Если у вас нет собственного экземпляра InfluxDB и вам нужно поиграть с тем, как Grafana отправляет ему запросы, вы можете использовать панель тестирования и инструменты разработчика, чтобы взглянуть на него.

В качестве отказа от ответственности я, вероятно, что-то упустил в том, как Grafana взаимодействует с InfluxDB, но вышесказанного было достаточно, чтобы начать.

Надеюсь, это поможет.

Спасибо! Это именно то, что я имел в виду

Во вторник, 22 сентября 2015 г., в 23:57, EliSnow [email protected] написал:

@roybass https://github.com/roybass , я полагаю, вы спрашиваете о
мой код, который имитирует интерфейс InfluxDB.

Я не могу поделиться своим конкретным кодом, и, вероятно, это не очень поможет
если я это сделал, потому что он специфичен для языка, который я использовал (Node.js), мои
база данных (Postgres) и структура моих данных (jsonb). Суть того, что
вам нужно создать конечную точку HTTP / query, которая возвращает данные в
тот же формат, что и InfluxDB.

Grafana вызовет вашу конечную точку с помощью метода GET с параметром q
строки запроса, являющейся поисковым запросом / запросами, указанными в вашем
панель приборов. Каждый запрос отделяется символом новой строки. (Примечание:
что кнопка «Проверить соединение» для тестирования вашего источника данных в админке
интерфейс отправит запрос ПОКАЗАТЬ ПРЕДЕЛ ИЗМЕРЕНИЙ 1. Если вы вернете
204 для этого запроса). Вы можете создать поисковый запрос так, чтобы
будь вашим собственным DSL. Я сделал свой поисковый запрос простым объектом JSON. Пока ты
конечно, вы можете использовать настоящий SQL для вашего поискового запроса, вы должны убедиться, что
пользователь базы данных, выполняющий запрос, имеет разрешение только на ВЫБРАТЬ на
конкретная таблица (и). Для меня мои SQL-запросы довольно длинные и грубые, и я
предпочитаю иметь уровень абстракции от базы данных.

InfluxDB возвращает данные в следующем [аннотированном] формате json:

{// каждая запись в "результатах" представляет результат одного запроса
"полученные результаты": [{
// каждая запись в "серии" представляет другую группу, если
// запрос имел предложение GROUP BY.
"серии" : [
{
"name": "название измерения",
// не уверен, какой приток тегов хочет вернуть
// возможно только те, что указаны в предложении WHERE
// grafana позволяет использовать теги в шаблоне псевдонима
"теги": {
"фу": "бар"
},
// Я не проверял источник графаны, но это возможно
// он не читает массив столбцов
"столбцы": ["время", "среднее значение"],
"ценности" : [
// время (в миллисекундах), значение
[1442953067791, 41,2]
]
}
]
}]
}

Если у вас нет собственного экземпляра InfluxDB и вам нужно поиграть
вокруг того, как Grafana отправляет ему запросы, вы можете использовать тестовую панель
http://play.grafana.org и ваши инструменты разработчика, чтобы взглянуть.

В качестве оговорки, я, наверное, что-то упустил в том, как Grafana
общается с InfluxDB, но этого было достаточно, чтобы начать работу.

Надеюсь, это поможет.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment -142419032.

Вышеуказанные условия отражают потенциальное деловое соглашение, предоставляются исключительно
в качестве основы для дальнейшего обсуждения и не предназначены для
представляют собой юридически обязывающее обязательство. Никакие юридически обязательные обязательства не будут
быть созданным, подразумеваемым или предполагаемым до тех пор, пока соглашение в окончательной форме не будет выполнено
в письменной форме всеми участвующими сторонами.

Это электронное письмо и любые вложения к нему могут быть конфиденциальными или привилегированными.
Если вы получили это сообщение по ошибке, не пересылайте его
кто-нибудь еще, удалите все копии и вложения, и позвольте мне
знайте, что он попал не к тому человеку. Спасибо.

: +1: для Postgres!

+1 для SQLite

@roybass - ваш пост дал мне идею, и я сделал очень простой старт на прокси-сервере postgres - я на самом деле еще не указывал на него grafana, но надеюсь, что через пользовательские запросы притока он может притвориться притоком, но поддерживается postgres

извините, ссылка будет полезна: https://github.com/sysadminmike/postgres-influx-mimic

привет всем, кто хочет подключиться к postgres - мне удалось заставить все вышеописанное работать и у меня есть пример графика

+1 postgres / postgres с типом JSONB
@EliSnow мы используем node, postgres, Influxdb и grafana ... если можете, я бы хотел посмотреть на ваш код :)
@sysadminmike проверит это!

: +1: MySQL

@RobMcZag, дайте мне знать, что вы думаете - я использовал его для создания идеи распределенного сбора метрик: https://github.com/sysadminmike/yadms/

@torkelo , я не уверен, как, источник данных SQL будет масштабироваться с миллионами точек данных, хранящихся каждый день. Я могу согласиться с тем, чтобы иметь источник данных в виде Cassandra, который отличается высокой масштабируемостью и отличной производительностью.

@utkarshcmu , я думаю, будет справедливо сказать, что реляционные базы данных не медленные по своей природе. В любом случае, даже если бы они были, все равно может быть привлекательно извлекать данные из небольшой таблицы для аннотаций или чего-то еще, поэтому базы данных SQL - очень полезный источник данных, если вы спросите меня.

какая последняя версия sql в качестве источника данных?

+1 Informix TimeSeries / Informix TimeSeries с JSON
@utkarshcmu Informix - это пример того, как объектно-реляционная БД может поддерживать высокомасштабируемую реализацию данных временных рядов с помощью оптимизированного типа данных временных рядов (элементы временных рядов могут быть типами данных SQL и / или документами JSON). ;)

Привет,

Существует возможность экспортировать числовые данные SQL через интерфейс HTTP с использованием дополнительного уровня между SQL-сервером и Grafana с помощью ArrestDB: https://github.com/alixaxel/ArrestDB
Было бы очень хорошо, если бы кто-то мог разветвить плагин из существующего, основанного на HTTP. Лично я здесь не эксперт в программировании на Java и мне нужна помощь с этим.
Это также хорошо сочетается с Restful API из других источников данных - https://restdb.io/docs/rest-api

+1

Привет, вот мой первый проект:
Собирайте метрики Microsoft SQL Server, отправляйте в InfluxDB и визуализируйте с помощью Grafana
https://github.com/zensqlmonitor/influxdb-sqlserver

+1 к MySQL :)

+1 для VoltDB [БД SQL в памяти]

: +1:

Как насчет jdbc?

+1 MySQL

+1 MySQL

+1 PostgreSQL

+1 PostgreSQL

Источник данных WIP SQL: https://github.com/grafana/grafana/pull/3964

+1 postgresql
8 февраля 2016 г. в 22:00 «Том Дайас» [email protected] написал:

Источник данных WIP SQL: # 3964 https://github.com/grafana/grafana/pull/3964

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment -181722398.

+1 Кассандра

Привет, каков статус интеграции источника данных SQL? Для нас очень интересно подключить графану к Amazon Redshift или Presto. Возможно, есть вариант, чтобы обсудить эту тему с одним из наших разработчиков. Интеграция SQL - это всего лишь некоторая работа по кодированию или требуются серьезные изменения?

У меня был незавершенный прототип в PR https://github.com/grafana/grafana/pull/3964, когда я разговаривал с Redshift моей компании. Так что я считаю, что на данный момент это просто работа по кодированию (с моей или чьей-либо стороны). Хотя есть несколько пунктов, перечисленных в PR, которые необходимо выполнить, прежде чем подготовить его к производству.

+1 ВольтДБ

+1 Было бы полезно для аннотаций и текстовых панелей.

+1

+1

Я уже какое-то время использую прокси-сервер infxdb через графану. В качестве побочного хобби я ковыряюсь в брандмауэре веб-приложений, и я бы очень хотел найти решение, что-то вроде подготовленных операторов для предотвращения SQL-инъекций. Прямо сейчас у меня есть набор различных регулярных выражений, которые обнаруживают SQL-инъекции, но их тонкая настройка при сохранении возможности развертывания новых информационных панелей в значительной степени предотвращает это, не оставляя мне другого выбора, кроме как внести в белый список раздел аргументов.
Концептуально это было бы просто: публиковать фиксированные прокси-ссылки для сбора данных, созданные при создании / обновлении панели мониторинга, а не включать инструкцию запроса в аргумент URL-адреса. Все, что вам нужно сделать на стороне прокси, - это сопоставить его с реальным запросом, а затем отправить его в серверную часть базы данных.
Работа с этим через прокси-части grafana дает дополнительную элегантность независимости базы данных от возможности работать с подготовленными операторами.

: +1: за концепцию / идею, а также за возможность использовать более или менее необработанный SQL, если вы хотите дополнить существующие методы / функции / метрики

+1 для postgresql / mysql

все мои пальцы были подняты для постгрес

+1

+1

+1. Действительно нужно это!

+1

Любые обновления по этому поводу ??

Я написал первоначальное доказательство концепции, которое выставил как пиар для получения обратной связи: https://github.com/grafana/grafana/pull/3964. Код отлично работал для запросов к локально запущенному экземпляру PostgreSQL. Я не знаю, будет ли это работать, учитывая изменения исходного кода в Grafana на пути к v3.

К сожалению, у меня больше нет времени работать над этим, потому что внутреннему проекту, который нуждался бы в таком источнике данных, больше нет.

Учитывая, что исходный код для подтверждения концепции общедоступен в PR, было бы нетривиально (но не большой объем работы), чтобы кто-то другой взял его на себя. Если вы разработчик, это отличный способ изучить базу исходного кода Grafana. Если вы не разработчик, но имеете влияние в своей компании, я рекомендую убедить разработчика в вашей организации поработать над этим.

Этот выпуск действительно демонстрирует проблему «безбилетника» в открытом исходном коде. «Валюта» открытого исходного кода - это код (в самом широком смысле) и время, вложенное участниками в этот код. Мне кажется, что все рады поставить +1, но очень немногие люди вносят свой вклад или используют свое влияние, чтобы убедить кого-то в своей организации внести свой вклад.

Хотите повлиять на направление проекта в этом вопросе? Возьмите на себя доказательство концепции, завершите его и внесите обратно, сделав это самостоятельно или выделив время вашей организации (в форме разработчика) на это. Такое распределение времени определенно является расходом. Кто готов «тратить» время?

От себя я готов ответить на любые вопросы о подтверждении концепции от того, кто ее возьмет на себя.

Я отправил запрос на перенос этого.

+1

+1 за Postgres, мое рабочее место уже любит Grafana

Нам бы очень хотелось это увидеть - в качестве справки https://github.com/sirensolutions/kibi - это «дружественный форк» kibana, а поддержка sql - одна из добавленных функций.
https://github.com/sirensolutions/kibi/tree/master/src/plugins/kibi_core/lib/datasources

если это поможет.

+1 для поддержки бэкэнда mysql / mariadb (требуется в основном для поиска баз данных билетов GLPI / OTRS / и т. Д.)

Ребята, перестаньте ставить +1. Просто скажите спасибо @anzai и примените https://github.com/grafana/grafana/pull/5364 к своей местной графане.

mysql и postgre - это здорово, Oracle или общий jdbc были бы потрясающими (как в Kibi, упомянутом выше)

@Jimilian - +1 означает, что он попадет в основную раздачу. Применение патча означает, что когда будет выпущена новая графана, мне придется повторно применить, что большинство пользователей не хотят иметь дело.

+1 за эту функцию, особенно если она поддерживает ODBC / JDBC

: +1: для postgres !! :-)

Я применил другой подход к отображению данных в СУБД с помощью RestSQL. RestSQL позволяет выполнять операции CRUD с реляционными базами данных, и это довольно элегантное решение, позволяющее выполнять операции с базой данных с использованием методов HTTP и REST.

Я написал плагин Grafana для RestSQL - плагин Grafana (3.x) для RestSQL . Однако сейчас рассматривайте это как PoC :-)

В моей настройке никаких изменений в кодовой базе Grafana не требуется. Однако для работы RestSQL требуется Java (Tomcat).

+1. Замечательный POC

+1. Было бы здорово для Postgres!

+1 Постгрес!
+1 Необработанные SQL-запросы

+1 за кассандру!

@juliusloman Было бы здорово, если бы вы опубликовали этот плагин на grafana.net!

+1 MYSQL и POSTGRES с необработанными запросами

+1 Десерты!
+1 Кассандра!
+1 MySQL!

+1 Кассандра

+1 MySQL

+1 MS SQL !! : D

Вместо того, чтобы создавать комментарии N +1, я предлагаю добавить тег: +1: в первую строку с упоминанием БД, которую вы хотели бы поддерживать?

: +1:

+1 BigQuery.

Будет ли этот плагин официальной версией? Я хотел бы иметь Postgres в качестве источника данных.

+1 PostgreSQL

@all Я открыл исходный код своего конвертера протокола InfluxDB-to-MySQL и опубликовал его на https://github.com/philip-wernersbach/influx-mysql , и он готов к работе с Grafana.

Я бы подумал, что входного шлюза JSON должно хватить, чтобы разрешить практически любой ввод SQL. Я пишу SQL, который будет выполняться через соответствующий драйвер, а полученный JSON будет использоваться grafana.

Наборы данных BigQuery в качестве настраиваемых серверных модулей были бы абсолютно _ мощными _.

+1 MySQL

@envintus Если у вас есть время внести свой вклад, я бы хотел, чтобы поддержка BigQuery была на https://github.com/philip-wernersbach/influx-mysql.

sparkSQL +1

какое-либо обновление плагина sql?

наличие поддержки сырого SQL в графане определенно сделает его лучшим 👍
какие-нибудь обновления по этой теме?

Моя наивная попытка grafana-simple-sql-datasource!
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: неполированная и неуклюжая бета-версия ... но у меня работает 🤣

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

image

@gbrian выглядит хорошо!

Я новичок в прокси sql-js, и у меня есть вопрос.
Существуют разные пакеты для разных баз данных, например MySql, MSSql, Postgress ...
Наивно думать, что ваша реализация будет работать с разными БД?
Если да, то как с этим можно справиться? похоже, нам нужна какая-то абстракция между ними ...

@osigida , спасибо!

Да, основная идея состоит в том, чтобы иметь файл «xxxproxy.js» для каждого источника данных, подобного SQL.

Следующим в моем списке идет Apache Drill (https://drill.apache.org/).
Если я все сделал правильно, это должно было быть похоже на создание прокси и настройку коннектора, например
http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port
Конечно, задача состоит в том, чтобы преобразовать схему источника данных в простой sql.

Буду рад, если вы протестируете его и отправите мне отзыв. Пожалуйста, откройте как можно больше проблем, и я постараюсь исправить их как можно скорее.

Заранее спасибо.

@gbrian Если вы планируете внедрить Postgres. Буду рад помочь и протестировать.

отличная работа. это будет также для оракула?

Отправлено через Samsung Galaxy S® 6, смартфон AT&T 4G LTE
-------- Исходное сообщение -------- От: Gustavo Brian [email protected] Дата: 16.02.17, 4:00 AM (GMT-05: 00) Кому: grafana / grafana [email protected] Копия: gsaray101 [email protected] , Комментарий [email protected] Тема: Re: [grafana / grafana] Grafana 2.0: Источник данных SQL (# 1542)
@osigida , спасибо!
Да, основная идея состоит в том, чтобы иметь файл «xxxproxy.js» для каждого источника данных, подобного SQL.
Следующим в моем списке идет Apache Drill (https://drill.apache.org/).

Если я все сделал правильно, это должно было быть похоже на создание прокси и настройку коннектора, например

http: // простой-sql-сервер : порт /? con = Drill: // Drilluser: пароль @ Drill-server : порт

Конечно, задача состоит в том, чтобы преобразовать схему источника данных в простой sql.
Буду рад, если вы протестируете его и отправите мне отзыв. Пожалуйста, откройте как можно больше проблем, и я постараюсь исправить их как можно скорее.
Заранее спасибо.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / grafana / grafana", "title ":" grafana / grafana "," subtitle ":" Репозиторий 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": "Открыть в GitHub", "url": " https://github.com/grafana/grafana "}}, "updates": {"snippets": [{"icon": "PERSON", "message": " @gbrian в # 1542: @osigida , спасибо! \ r \ n \ r \ nДа, основная идея состоит в том, чтобы иметь файл \ "xxxproxy.js \" для каждого SQL-подобного источника данных. \ r \ n \ r \ nСледующим в моем списке является Apache Drill (https://drill.apache.org/)\r\nЕсли я поступил правильно, это должно быть так, как создание прокси и настройка коннектора, например \ r \ n http://simple-sql-server:port/?con=drill://drilluser:password@drill-server:port \ r \ n, конечно, задача преобразует схему источника данных в простой sql. \ r \ n \ r \ nЯ буду рад, если вы протестируете его и отправите мне обратно, чтобы мне обратная связь. Пожалуйста, откройте как можно больше проблем, и я постараюсь исправить их как можно скорее. \ R \ n \ r \ nСпасибо заранее. "}]," Action ": {" name ":" Просмотреть проблему "," url ": " https://github.com/grafana/grafana/issues/1542#issuecomment -280272622"}}}

@anayrat , @ gsaray101

Выглядит осуществимо и должно быть довольно легко:
https://www.npmjs.com/package/pg
https://www.npmjs.com/package/strong-oracle

+1 MySQL

+1 MySQL

+1 Кассандра

+1 MSSQL +1 MYSQL

К вашему сведению

Теперь есть официальный плагин Oracle премиум-класса (платный).
https://grafana.com/plugins/grafana-oracle-datasource

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

HI @epizut : Этот плагин премиум-класса находится в стадии разработки в рамках общих усилий. Плагин премиум-класса будет использовать преимущества будущих основных функций.

Больше сюда приехать!

Существуют ли какие-либо известные ограничения использования кассандры в качестве источника данных графаны? Или о каких-либо других проблемах, о которых следует знать, прежде чем внедрять подключаемый модуль источника данных?

Cassandra - это не база данных временных рядов, поэтому я не думаю, что вы можете использовать ее в качестве
источник данных в графане. Я использую opentsdb в качестве источника данных Grafana

19 мая 2017 г. в 10:28 "mtnxplorer7" [email protected] написал:

Существуют ли какие-либо известные ограничения использования кассандры в качестве данных графаны?
источник? Или любые другие проблемы, о которых следует знать, прежде чем внедрять
плагин источника данных?

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/1542#issuecomment-302763176 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ARG51ZdZ6qbzst8m7mx-tsSZ9cRoBe5Lks5r7dEggaJpZM4DndgD
.

Cassandra поддерживает моделирование данных временных рядов. Любые мысли, основанные на этом

+1 за Apache Drill.

Я вижу, что внутренняя часть этого PR была объединена, но каков общий статус? Есть ли расчетное время прибытия для обзора и объединения любой необходимой фронтенд-работы?

Для MySQL есть внутренняя и внешняя части с поддержкой предупреждений. Пока нет поддержки Postgres

Было бы здорово использовать поддержку Postgres с http://www.timescale.com/.

Я бы хотел увидеть поддержку SQL для athena: http://docs.aws.amazon.com/athena/latest/ug/what-is.html

@torkelo Мне нужна помощь с источником данных MySQL. У меня установлена ​​последняя версия Grafana (v4.4.3)

Предположим, что мой хост grafana - это grafana.host.org, и у меня есть база данных SQL для приложения, размещенного на другом хосте, скажем, application.host.org. У меня есть mysql db на том же application.host.org

Когда я добавляю новый источник данных типа MySQL на grafana (например, grafana.host.org), он запрашивает у меня детали подключения. Добавляю к нему следующие детали:

Хост: application.host. org: 3306
База данных: dbname
Пользователь: dbuser
Пароль: dbpassword

Теперь, когда я сохраняю и проверяю это соединение, появляется сообщение об ошибке:

«Ошибка 1045: доступ запрещен для пользователя 'dbuser'@'grafana.host.org' (с использованием пароля: ДА)»

Есть ли какие-либо указания на решение этой проблемы? Почему он пытается получить доступ к grafana.host.org, когда я указал хост db как application.host.org? Я могу подключиться с grafana.host.org к application.host.org нормально. Однако это дает мне эту ошибку.

Насколько я понимаю, он должен попытаться подключиться к базе данных на application.host.org. Когда я подключаюсь к базе данных на этом хосте на бэкэнде, я справляюсь без проблем.

Мы будем очень благодарны за вашу помощь.

Спасибо,
Джиоти

Ошибка 1045: доступ запрещен для пользователя dbuser'@'grafana.host.org (с паролем: ДА)

Это ошибка MySQL. Он обнаружил, что dbuser подключается _из_ сетевого адреса, который разрешается в grafana.host.org . Проверьте разрешения, пароль и т. Д. В MySQL.

Есть мысли о поддержке диалекта Redshift SQL?

Redshift SQL - это просто семейство Postgres 8.x, которое должно быть совместимо с недавно появившейся поддержкой Postgres. Еще не пробовал, но тоже интересовался, есть ли ошибки.

Если вы не против проксирования данных через postgres, вы можете подключить grafana к (почти) любой базе данных с помощью оболочки внешних данных postgres (https://wiki.postgresql.org/wiki/Foreign_data_wrappers).

+1 Oracle DB

+1 для MS SQL

+1 для SQLite

привет, всем, кто интересуется mssql, проверьте pr # 10093

Кто-нибудь работал с Oracle в качестве источника данных? Я хотел бы видеть его.

@ gsaray101 и всем, кому интересно - свяжитесь с [email protected], если вы хотите протестировать бета-источник данных Oracle.

Мы объединили источник данных Microsoft SQL Server с Grafana, и он будет выпущен в Grafana 5.1 (# 10093, # 11298).

Это означает, что Grafana теперь в ядре поддерживает MySQL, Postgres и MS SQL Server в качестве источников данных. Мы не будем добавлять больше баз данных sql в качестве источников данных в ядро ​​Grafana, поэтому, наконец, пора закрыть эту проблему.

В ближайшем будущем у нас будет поддержка внутренних плагинов, поэтому можно будет использовать другие источники данных sql в качестве внешних плагинов.

Кто-нибудь хочет добавить поддержку DB2 LUW?

@daniellee А как насчет Oracle и SQLite? : Thinking: Есть новости по этому поводу?

@mnlbox Уже существует плагин Oracle: https://grafana.com/plugins/grafana-oracle-datasource (однако это не открытый исходный код)

Sqlite как источник данных вообще не входит в наш список невыполненных работ, и я не слышал, чтобы кто-нибудь работал над ним.

+1 в ближайшее время

Есть какие-нибудь обновления по SQLite @daniellee ?

Источник данных SQLite был бы очень полезен!

Sqlite !!!!!

Sqlite !!!!!

Sqlite !!!!!

Sqlite !!!!!

Используйте функцию 👍, чтобы показать свое одобрение и комментарий, только если вы можете предоставить дополнительную информацию, полезные примечания, исправления и аналогичные - хорошо - комментарии, помогающие решить проблему. Спам разработчиков, участников или участников, вероятно, никого не убедит реализовать ваши запросы.

Дэниелли заявил выше, что никаких дальнейших усилий по поддержке дополнительных источников данных в ядре не предпринимается, и плагины - это то, что нужно. Также, похоже, никто не начал работать над SQLite. Если вам нужно быстрое и грязное решение и вы не хотите писать / заказывать / адаптировать весь плагин для / для SQLite, должно быть несколько легко создать прокси-скрипт smapp для обслуживания ваших SQLite-данных как JSON, аналогично doublemarkets RRD -Прокси . Не лучшее решение для скорости, но вы, вероятно, не стали бы использовать SQLite, если это вызывает беспокойство.

Как сообщает @adlerweb , в настоящее время у основной команды Grafana нет планов для основного источника данных Sqlite. Я не думаю, что мы тоже примем за это пиар. Однако мы, конечно, опубликуем плагин внешнего источника данных на grafana.com, если бы кто-нибудь его написал.

Есть какие-нибудь обновления по SQLite @daniellee ?

Тем, кто заинтересован в поддержке SQLite (или фактически тем, кто ждет каких-либо источников данных), долго ждать не нужно. На Python довольно легко написать собственный источник данных. Документация немного скудна (см. Https://github.com/grafana/simple-json-datasource), но это возможно. Я создал довольно обширный пример в этом репозитории и сообщение в блоге о том, как визуализировать SQLite с помощью Grafana . Репозиторий также включает рабочий пример SQLite и небольшую базу данных для этого примера.

  • SQLite голосование!

проголосовать за sqlite

С бэкэндом появляется возможность иметь источник данных SQL.

Я думаю, что когда вы добавляете источник данных, вы

  • тип db (изначально только mysql, postgres и sqlite3)
  • детали подключения к базе данных
  • укажите шаблон запроса метрики (в основном SQL-запрос с параметрами)
  • указать шаблон запроса аннотации

Возможно, также есть возможность разрешить запросы RAW SQL из интерфейса запроса метрики панели.

Есть другие идеи?

Для Sqlite

Проголосуйте за sqlite.

Sqlite, пожалуйста

Была ли эта страница полезной?
0 / 5 - 0 рейтинги