Grafana: Разрешить пользовательское сопоставление значения переменной шаблона -> отображать текст

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

+1

Я тоже мог бы использовать хотя бы более простую версию этого. Что-то вроде настроенного отображения из A -> B

В моем сценарии я хочу выбрать имя объекта в раскрывающемся списке переменных (CustomerName1, CustomerName2 и т. д.), но использовать внутренний числовой идентификатор, когда дело доходит до имени метрики.
app.requests.$customer1_ID.count

+1

Объединение с # 3138

Например, при создании пользовательской переменной шаблона со значениями fooBar и baz_quuxInternal , чтобы пользовательский интерфейс мог отображать флажки как «Foo bar» и «Baz».

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

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

Например, если графитовый запрос расширяет kafka.messagesByTopic.myservice_* для использования в шаблонах, то может потребоваться, чтобы пользовательский интерфейс удалил префикс. Но при использовании в реальных панелях префикс должен быть включен. Это можно обойти (в Grafana 2.x и более поздних версиях) теперь, когда переменные шаблона могут быть встроены в свойство метрики, поэтому можно жестко закодировать префикс во всех метриках во всех панелях и строках, но этого лучше избегать.

Когда эти значения «метки» существуют, было бы полезно иметь доступ к ним и внутри панелей. Например, при встраивании переменной в заголовок строки и/или панели. Либо мы можем заставить его использовать метку по умолчанию (если она встроена в поле заголовка), либо, возможно, с каким-то альтернативным синтаксисом (например, $$Variable или что-то еще)

http://play.grafana.org/dashboard/db/test?editview=templating показывает «Ярлык переменной» в качестве опции. Это можно закрыть?

РЕДАКТИРОВАТЬ: я неправильно понял ошибку, извините! :) Продолжать.

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

+1

+1

+1

+1

+1

+1

Каков статус этого?
Возможно ли это сделать?

Возможно ли это для финала 3.0?
Это похоже на функцию, которую многие ждут. Включая меня :-)

+1
Обычно я использую часть регулярных выражений, которые выглядят ужасно для пользователей.

+1

+1

+1
Без этого регулярные выражения неприменимы в переменных шаблона.

+1

+1

+1

+1

+1

+1

@mbell697 @ торкело

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

Можно ли добавить параметр «variable_translation_url», указывающий на URL-адрес, который может выполнять сопоставление? (с необязательным токеном авторизации, если необходимо) или variable_translation_script, который указывает на javascript src, который можно загрузить и подключить к templateValuesSrv.js в точках, где требуется перевод (если этот параметр установлен)?

Можете ли вы поделиться кодом templateValuesSrv.js? Я хочу попробовать.

@ZhuWanShan В основном это так:

https://github.com/sangoma/grafana/commit/fa109c23bc92c3121173579afbd87a04d7e2f523

Обратите внимание, что вы увидите 2 подхода. Первый должен был быть более общим, вводя новый тип переменной шаблона «http» со свойством «query», которое указывает на URL-адрес HTTP для выполнения сопоставления (см. _getHttpVariableOptions). Позже я реализовал второй метод, который определяет, соответствует ли текст параметра (отображаемое значение) регулярному выражению UUID, и принудительно отображает любую переменную, используя жестко запрограммированный HTTP-вызов /api/v1/nodes/grafana-hosts/, который возвращает сопоставление всех вариантов. До сих пор это работало хорошо, просто нужно указать, как преобразовать это в общий метод.

+1

+1

Для всех, кто заинтересован, я смог решить свой конкретный вариант использования с помощью плагина Simple JSON Datasource .

Тем не менее, плагин в настоящее время не поддерживает запросы переменных шаблона, но мой запрос на вытягивание , который устраняет проблему, был объединен с мастером. В какой-то момент должен появиться обновленный выпуск плагина Grafana.net.

С его помощью вы можете использовать пользовательские конечные точки HTTP в качестве источников данных в Grafana. Им просто нужно реализовать 4 метода . При использовании с переменными шаблона на основе запроса конечная точка HTTP получит запрос API /search , а тело будет представлять собой объект JSON в форме: { "target": "{template query content here}" } . Вы можете анализировать содержимое запроса, как хотите.

При возврате массива значений из вашей конечной точки будет создан базовый список значений переменных шаблона ["custom value 1", "custom value 2"] в форме: [{ "text": "custom value 1", value: 0 }] , где свойство text — это возвращаемое значение для каждого элемента массива. а свойство value — это индекс переменной в возвращаемом массиве.

В качестве альтернативы вы можете вернуть массив объектов текста/значения [{ "text": "label", "value": 123 }] , и Grafana будет использовать свойство text в качестве метки переменной шаблона, а свойство value в качестве необработанного значения переменная шаблона.

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

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

Я человек.

+1

+1

+1

+1

+1

+1

+1000

+1

+2

Было бы очень полезно иметь это. По сути, у меня есть куча объектов, у которых есть и имя, и uuid. Я хотел бы отобразить имя, но сохранить uuid в переменной.

Было бы здорово, если бы мы могли сделать что-то вроде have:

Запрос (существующий): SHOW TAG VALUES FROM "vcd_vm" WITH KEY = "uuid", где "OrgVdc" =~ /^$vDC$/)

Ярлык (новый): ПОКАЗАТЬ ЗНАЧЕНИЯ ТЕГА ИЗ "vcd_vm" С КЛЮЧОМ = "имя", где "uuid" =~ /^$tag$/)

+1

+1

+1

+1

+1

+1

+1

Было бы здорово, если бы переменная шаблона «Пользовательский» принимала в качестве входных данных как список «значений», так и список «меток» (по сути, пользовательский хэш/словарь)

+1

+1

Это было бы полезно для данных AWS CloudFront, экспортированных официальным экспортером CloudWatch. Данные для CloudFront отображаются с помощью идентификаторов, которые никто не использует. Людям, смотрящим на графики, гораздо проще увидеть "foo.example.com; bar.example.com" вместо "EAUUWLGUQEPFWV; EVWWU9PGWIB"...

+1

Во-первых, спасибо за разработку потрясающего продукта и за то, что поделились им со всем миром!

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

Реализация этого через конечную точку HTTP — изящное решение очень обобщенной версии этой проблемы, но кажется излишним для многих из описанных здесь случаев использования (включая мой), где все, что нужно, — это базовое статическое сопоставление на скромном количестве «дружественных отображаемое имя» -> пары «недружественное имя базы данных».

@svet-b Между прочим, мы перешли к предложению @meverett , и это было безболезненно и чисто. Всего несколько часов, чтобы создать плагин источника данных.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Обходной путь @meverett работает довольно хорошо, но терпит неудачу при использовании с переменными с несколькими значениями, потому что ряды могут быть помечены только тегами из (в моем случае) influxdb. Любые предложения по обходным путям там? :)

+1

+1

+1

+1

+1

Привет всем, поскольку эта проблема возникает довольно часто, я решил собрать пример веб-приложения Node.js, в котором используется мое решение, описанное выше .

Это довольно просто, но полностью реализует шаблон, который я упоминаю в своем первоначальном комментарии. И если вы можете поместить свои данные поиска в один файл JSON, который не будет обновляться очень часто, он может просто работать для вас.

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

Репозиторий примера веб-приложения находится здесь .

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

Ваше здоровье

+1

+1

Спасибо за ваше импровизированное решение, @meverett . Я сделал репозиторий с Dockerfile для создания контейнера Docker для запуска вашего решения. Он настроен на получение пользовательского data.json вместе с Dockerfile при сборке. Надеюсь, это поможет людям:

https://github.com/shirakaba/GrafanaSimpleJsonValueMapper-докер

＋1

+1

+1

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

+1

+1

+1

это было бы здорово! a иметь список длинных числовых значений, но должно быть намного лучше показывать метку, удобную для человека, для каждого из них, чем само значение
переменная: myListOfLongs {имя: значение toyota: 122321312332, имя: значение renault: 6666666}

+1!

+1

+1
Любые обновления о #11534 (Разрешить динамические заголовки при использовании повторяющихся панелей/рядов)

+1

+111111

+1

+1

+1, Очень нужна эта функция.

+1

+1

+1

+1

+1

Это работает для MySql и PostgreSQL:

Другой вариант — это запрос, который может создать переменную ключ/значение. Запрос должен вернуть два столбца с именами __text и __value. Значение столбца __text должно быть уникальным (если оно не уникально, то используется первое значение). Параметры в раскрывающемся списке будут иметь текст и значение, которые позволяют вам использовать понятное имя в виде текста и идентификатор в качестве значения. Пример запроса с именем хоста в качестве текста и идентификатором в качестве значения:

SELECT hostname AS __text, id AS __value FROM my_host

http://docs.grafana.org/features/datasources/mysql/#query — переменная

Я бы предложил пользовательскую переменную:

[{
        "__text": "Server 1",
        "__value": 1
    },
    {
        "__text": "Server 2",
        "__value": 2
    }
]

Может быть, новый тип под названием JSON?

Спасибо @johnymachine! Это прекрасно работало с источником данных PostgreSQL.

В дополнение к этому, есть ли способ получить раздел переменной __text ? Это было бы очень полезно для повторения графиков.

Эй, @MGinshe , у меня это отлично работает (отображает текст, использующий значение):

РЕДАКТИРОВАТЬ: неправильно понял первоначальный контекст этой ошибки, игнорируйте комментарий ниже, он больше предназначался для # 9292

@торкело @nmaniwa

https://github.com/grafana/grafana/pull/12609 , кажется, реализует то, о чем здесь просят большинство людей, по какой причине это закрыто и никогда не объединялось?

Нет, этот вопрос о чем-то совершенно другом, или вы ссылались не на тот вопрос?

До сих пор нет новостей об этом? Давай, мы в 2018 !! Спасибо!

@dmayan ответил @johnymachine . Вы можете использовать это.

Это работает для MySql и PostgreSQL:

Другой вариант — это запрос, который может создать переменную ключ/значение. Запрос должен вернуть два столбца с именами __text и __value. Значение столбца __text должно быть уникальным (если оно не уникально, то используется первое значение). Параметры в раскрывающемся списке будут иметь текст и значение, которые позволяют вам использовать понятное имя в виде текста и идентификатор в качестве значения. Пример запроса с именем хоста в качестве текста и идентификатором в качестве значения:

SELECT hostname AS __text, id AS __value FROM my_host

http://docs.grafana.org/features/datasources/mysql/#query — переменная

Я бы предложил пользовательскую переменную:

[{
      "__text": "Server 1",
      "__value": 1
  },
  {
      "__text": "Server 2",
      "__value": 2
  }
]

Может быть, новый тип под названием JSON?

Я не использую MySQL и PostgreSQL. Это должно быть функцией Grafana. Нет
какой-то хак.

Спасибо!

Эль Джуэ, 27 сент. де 2018 г., 05:52, Мухаммед Хендри, [email protected]
описание:

@dmayan https://github.com/dmayan был дан ответ. Вы можете использовать это.

Это работает для MySql и PostgreSQL:

Другой вариант — это запрос, который может создать переменную ключ/значение. Запрос
должен возвращать два столбца с именами __text и __value. Текст
значение столбца должно быть уникальным (если оно не уникально, то первое значение
использовал). Параметры в раскрывающемся списке будут иметь текст и значение, которые позволяют
чтобы у вас было понятное имя в виде текста и идентификатор в качестве значения. Пример
запрос с именем хоста в качестве текста и идентификатором в качестве значения:

ВЫБЕРИТЕ имя хоста КАК __текст, идентификатор КАК __значение ОТ my_host

http://docs.grafana.org/features/datasources/mysql/#query — переменная

Я бы предложил пользовательскую переменную:

[{
"__text": "Сервер 1",
"__значение": 1
},
{
"__text": "Сервер 2",
"__значение": 2
}
]

Может быть, новый тип под названием JSON?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/1032#issuecomment-425011676 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AWcYqEwxjXiXE07uM0ZG-A284TghEIR2ks5ufJG4gaJpZM4C4cjS
.

довольно полезная функция. Если бы эта функция была доступна, она могла бы нам очень помочь. Потому что графит не может хранить китайский иероглиф. Таким образом, мы должны использовать английский язык в Graphite, но мы бы очень хотели, чтобы китайский язык отображался в панели инструментов Grafana, чтобы пользовательский опыт был намного лучше.

Надеюсь, что эта функция станет реальностью в ближайшее время.

Мне удалось сделать сопоставление ID-> name с помощью двух переменных. Первая переменная перечисляет все возможные идентификаторы (значение), а вторая переменная перечисляет имя (отображаемый текст), которое соответствует идентификатору. Это не идеально или красиво, но это делает свое дело.

Я думаю, это называется вложенными переменными . И тогда вы можете скрыть один из селекторов переменных.

+1

+1

@FdeFabricio Вы использовали InfluxDB? Обновляет ли он автоматически одно значение при изменении другого? Если да, то как вы это делаете?

@bassie1995

Вы использовали InfluxDB?

да

Обновляет ли он автоматически одно значение при изменении другого?

да

Если да, то как вы это делаете?

Вы создаете переменную типа запроса, которая выбирает элемент, соответствующий уже выбранному значению (например, SELECT "name" FROM playlists WHERE ("id" =~ /^$playlist_id$/) . Итак, теперь у вас будет две переменные: одна с идентификатором, а другая с именем.

@bassie1995 @FdeFabricio Вы также можете сделать это в обратном порядке:

• Видимая переменная, которая позволяет выбрать имя плейлиста (например, Girl Power).
• Скрытая переменная, которая находит идентификатор плейлиста по названию (что-то вроде SELECT "id" FROM playlists WHERE ("name" =~ /^$playlist_name$/) )

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

Тем не менее, синтаксис __name и __value из источника данных PostgreSQL/MySQL по-прежнему идеален, поскольку он предотвращает любую двусмысленность id->name и уменьшает количество необходимых запросов к базе данных. Это должно быть базовой функцией IMO.

Я нашел другой обходной путь, основанный на комментарии @johnymachine выше. Это поддерживается в некоторых источниках данных. Если это не поддерживается в вашем источнике данных, вы можете создать базу данных MySQL, добавить туда данные и написать запрос для возврата __value и __text. Это работает, если данные статичны, в моем случае это состояние (географическое состояние). Для тех, кто хочет эту функцию для переменных, определенных как пользовательские, я думаю, что это хороший обходной путь и, возможно, лучшее решение в любом случае. Это позволяет хранить все списки переменных в одном месте и легко изменять их. Единственным недостатком является необходимость установки MySQL.

ВЫБЕРИТЕ SingleChar AS __value, ShortName AS __text ИЗ TSDB. State

Я должен добавить, что это решение работает для повторяющихся графиков, повторяющихся строк, а также если переменная имеет множественный выбор. Приведенный выше пример с использованием переменной 2 для отображения «Сила девушки» не работает в этих ситуациях.

Я просто возился с этой проблемой и нашел несколько хакерский обходной путь...
Мне нужен был хэш, который в нотации Perl записывается так:
Perl %units = ( 'μSv/h' => 1.0, 'mrem/h' => 0.1 );
Я создал переменную приборной панели Type : Custom , Values separated by comma : mrem/h, μSv/h , а затем отредактировал JSON Model следующим образом:
JSON { "allValue": null, "current": { "tags": [], "text": "mrem/h", "value": "0.1" }, "hide": 0, "includeAll": false, "label": null, "multi": false, "name": "units", "options": [ { "selected": true, "text": "mrem/h", "value": "0.1" }, { "selected": false, "text": "μSv/h", "value": "1.0" } ], "query": "mrem/h, μSv/h", "skipUrlSync": false, "type": "custom" }

Хотя это работает (какое-то время), редактирование приборной панели через графический интерфейс возвращает ее в нерабочее состояние :-|

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

Используйте плагин источника данных JSON, я использую: https://grafana.com/plugins/simpod-json-datasource

Реализуйте только конечную точку проверки работоспособности / и конечную точку /search в какой-либо системе, имеющей необходимые данные. Конечная точка /search должна возвращать JSON следующего вида: [{ "text": "A Human Name", "value": "123456" }, ...] . Свойство text будет отображаться в раскрывающемся списке выбора переменной, а свойство value будет использоваться в запросе метрик.

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

+1 по этому поводу. Мне бы очень хотелось сделать это, но не зависящим от бэкенда (мы используем графит).

+1 любое рабочее решение?

@ BlackRider97 Пожалуйста, просмотрите комментарии выше - есть несколько рабочих решений для PostgreSQL (и, возможно, MySQL, MSSQL и т. д.).

Решение 1: https://github.com/grafana/grafana/issues/1032#issuecomment -409124505

Решение 2: https://github.com/grafana/grafana/issues/1032#issuecomment -453242766

Правильная реализация обходного пути от @thinrope была бы действительно элегантным решением, имхо.
Если бы мы могли использовать JSON в пользовательской переменной или иметь тип переменной «JSON», мы могли бы решить эту проблему без хаков, и я не вижу никаких недостатков.

+1 есть новости по этому поводу?

+1

+1

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

Способ ввести это в пользовательское значение может быть таким простым, как:
label1:value1, value2, label3:value3, label5:value5

Этикетка будет необязательной. Если в строке присутствует : , то все до : является меткой, а все после — значением.
У нас должен быть способ избежать : , если он нам нужен в имени или значении метки, как мы можем сделать для символа , .

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

Используйте плагин источника данных JSON, я использую: https://grafana.com/plugins/simpod-json-datasource

Реализуйте только конечную точку проверки работоспособности / и конечную точку /search в какой-либо системе, имеющей необходимые данные. Конечная точка /search должна возвращать JSON следующего вида: [{ "text": "A Human Name", "value": "123456" }, ...] . Свойство text будет отображаться в раскрывающемся списке выбора переменной, а свойство value будет использоваться в запросе метрик.

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

Я сделал эту реализацию, и она у меня работает, но я застрял на маркировке тренда (легенды)... Я получаю либо id (число), либо не определено, либо еще какую-то ерунду.
Вы можете посоветовать?

М

+1

Я также сейчас использую JSON-хак, описанный @mbell697 , в Grafana моей компании. Но ИМХО кажется странной проблемой регулярного выражения.

Я установил небольшое приложение python flask, которое предоставляет мне необходимые группы для запросов Graphite, мои данные поиска выглядят так

@app.route('/search', methods=['POST'])
def search():
    data = [
        {"text": "fs-servers", "value": "{FS-server-1,FS-server-2,FS-server-3}"},
        {"text": "db-a-servers", "value": "{db-server-1,}"},
        {"text": "db-b-servers", "value": "{db-server-2,db-server-3}"}
    ]
    return jsonify(data)

Итак, на панели инструментов я создал переменную запроса под названием «группа», используя json-источник, а затем попытался отфильтровать группу «fs-servers» с помощью поля регулярного выражения, используя /fs-.*/ , но это не работает. как и ожидалось - после возни я понял, что регулярное выражение каким-то образом применяется к «значению», а не к «текстовому» полю. У кого-нибудь может быть какое-то обходное решение или идея?

+1

+1

Мой взгляд на требования для этого:

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

Пример 1 - простое преобразование имен в один. Таким образом, в этом случае у нас есть числовые коды стран, опубликованные в виде значений показателей. Но знайте, что вы запоминаете числовые коды. Итак, мы хотим отобразить «США» или «Канада».

{ "США" == "01" }
{ "Канада" == "02" }

Если выбрано «Канада», значение переменной шаблона, передаваемое в любой запрос, равно «02».

Пример 2 - это отображение один ко многим. Внутри у нас есть этапы для развертывания, например, s0, s1, s2, s3, s4. Однако конечные пользователи могут использовать это как «dev, beta, prod».
Поэтому они хотят отобразить их как:

{ "dev" == ["s1"] }
{ "бета" == ["s2", "s3"] }
{ "prod" == ["s4", "s5", "s6"] } или еще лучше "prod" == s[456]

Итак, если выбран «prod», в запрос передается «s4, s5, s6».

С точки зрения запроса (взяв пример 2), где имя переменной stageVar
а имя тега метрики — stage:

Мы не видим такой необходимости в aliasBy(), как вызовы, но больше таких вещей, как:
стадия=~${стадияVar. значение: регулярное выражение }
псевдоним ($ stageVar.label)

Для фильтрации результатов по выбранным значениям переменных шаблона. Конечно, возможно, что кто-то может попытаться использовать его в чем-то вроде функции aliasBy(), но если это синтаксическая ошибка, это нормально. Я бы не ожидал, что вы волшебным образом исправите преобразование массива, переданного в функцию, которая ожидает одно значение.

Что касается сопоставлений, я думаю, что пользователю достаточно статически определить их.
В идеале у вас должен быть запрос к MT, чтобы получить список значений, которые необходимо сопоставить для вас, например, «01», «02», «03», а затем вам будет легко добавить сопоставления/псевдонимы. Несопоставленные значения попадут в корзину «по умолчанию».

+1

+1

Я очень удивлен, что это не было включено - я потратил довольно много времени, пытаясь понять, как сделать эту «очевидную» вещь, и в конце концов нашел свой путь сюда, чтобы обнаружить, что ее не существует.

Возможность динамической перезаписи, как описано некоторыми выше, была бы фантастической. Тем не менее, я был бы доволен даже краткосрочным хаком (или постоянной «легкой» моделью), который представляет собой расширенную версию поля «Пользовательский», которая статически сопоставляет выборы с результатами с одним или несколькими вариантами выбора.

Наш пример — коды стран. Нам часто требуется просматривать кластеры систем по географическим регионам, а не по странам. Но мы храним только коды стран в качестве ключей на нашем сервере Prometheus. Так что прямо сейчас, если я хочу просмотреть все системы в Северной Америке, мне нужно вручную выбрать США, CA, MX из списка вариантов на основе запроса из почти 100 стран. Я даже не могу вам сказать, сколько времени я трачу на выбор каждой страны в Европе, Азии или Африке для проведения анализа. Практически стоит настроить совершенно разные информационные панели для каждого региона, что абсурдно, но это единственный способ решить проблему, кроме жестко запрограммированных графиков. Создание совершенно новой базы данных с сопоставлениями, а затем выполнение скрытых запросов также кажется очень и очень далеким от идеала.

Мой лихорадочный сон:
Казалось бы, это будет опция «Пользовательский список» как возможный новый тип переменной. Пользовательский список будет начинаться пустым, если его выбрать, но он будет очень похож на сегодняшнюю модель «Пользовательский». Появится кнопка «Добавить». Нажатие «Добавить» создаст входной массив из двух полей с «Отображаемое значение:» и «Поисковое значение:», где каждое из них может быть заполнено. «Отображаемое значение» будет тем, что пользователь хотел показать в раскрывающемся списке — в нашем случае, "Северная Америка". Тогда «Значение поиска» будет тем, что будет представлено в запросе — опять же, в этом примере для Северной Америки это будет «us,ca,mx». В любое время значок «удалить» (корзина?) удаляет отдельные строки. Повторное нажатие кнопки «Добавить» создаст новую пару, пока пользователь не заполнит свой список параметров. Параметры «Несколько значений» и «Выбрать все» останутся, как и в существующей пользовательской модели.

Я очень удивлен, что это не было включено - я потратил довольно много времени, пытаясь понять, как сделать эту «очевидную» вещь, и в конце концов нашел свой путь сюда, чтобы обнаружить, что ее не существует.

Я решил эту проблему, создав базу данных MySQL, я создаю таблицу с элементами, которые я хочу в раскрывающемся списке, например, Европа, Северная Америка и т. д. Во втором поле у ​​меня есть регулярное выражение, которое будет соответствовать записям, которые я хочу сопоставить. Затем добавьте MySQL в качестве источника данных и используйте их для создания переменных. Это хак, но на самом деле работает довольно хорошо. Я использую его практически для того, что вы пытаетесь сделать.

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

Я думал об этом немного больше, и есть еще более элегантный способ предоставления этой функциональности, чем то, что я описал выше. Я бы назвал это «переменным макросом». Это снова выглядит как пользовательский список, за исключением того, что он позволяет администратору указать, что при выборе одного (или нескольких) этих макросов будут установлены именованные переменные, а заданные значения будут добавлены к существующему набору значений. Это будет полностью модель, управляемая пользовательским интерфейсом, и вообще не изменит фактическую концепцию переменных — она просто создаст сахарный слой автозавершения поверх существующих переменных. Это делает его обратно совместимым без дополнительных переменных, необходимых для создания или интеграции в запросы.

Макрос, который устанавливает переменные, позволит пользователю видеть значения по мере их выбора, а затем позволит пользователю открывать каждую переменную и видеть/манипулировать выборками или данными вместо создания отдельной переменной, как в моих предыдущих комментариях. подразумевать. Это было бы гораздо более интуитивно понятно.

Пример:

Таким образом, переменный макрос под названием «Северная Америка — основной кластер» установит для моих переменных «Страна» значение «нас, ca, mx», а для моей переменной «Кластер:» — значение «основной». Эти настройки были бы видны, если бы я вытащил каждую именованную переменную (или нет, если они скрыты), чтобы я мог добавлять или вычитать страны из списка «Страна:», пока я снова не коснулся выпадающего списка «Макропеременная».

Возможно, есть логическое значение «очистить именованные переменные перед установкой», чтобы, если в списке выбора для этого макроса было сделано изменение, все другие настройки указанных переменных были очищены. Это может быть полезно для списков, в которых не очевидно, что вы можете включить что-то, что было установлено ранее. Я предполагаю, что если было выбрано более одного параметра Variable Macro, то последний в списке для проверки «выигрывает», если есть конкурирующие настройки определенного значения; никак не обойти эту проблему. (можно утверждать, что это очищающее действие должно быть указано для каждой переменной, но это кажется немного загроможденным... но так ли это?)

Вот снова мой гипотетический пример, где у меня есть уже существующие переменные «Страна» и «Кластер».

Имя переменной макроса: Регион

Name1: Северная Америка — основной кластер
Очистить именованные переменные перед установкой: Y
Переменная1: Страна
Значение1: сша, ca, mx
Переменная2: Кластер
Значение2: основное

Name2: Северные страны — вторичный кластер
Очистить именованные переменные перед установкой: Y
Переменная1: Страна
Значение1: se, fi, no, dk, is
Переменная2: Кластер
Значение2: вторичное

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

Я ожидал, что ты скажешь что-то вроде этого. Реальность такова, что вы попросили хак, и этот хак действительно решает проблему, его несложно настроить и несложно отменить в будущем. На самом деле мне очень удобно иметь там MySQL, поскольку мы продолжаем добавлять к нему новые наборы данных, это удобное место для их отслеживания и обновления. Если подумать, если вы собираетесь использовать эти наборы данных на нескольких информационных панелях и хотите, чтобы они обслуживались централизованно, то их нужно где-то хранить. Если ваша база данных временных рядов не может их хранить, вам нужно что-то настроить для их хранения. Так что на самом деле имеет смысл иметь MySQL. Дополнительным бонусом является также очень простая автоматизация заполнения MySQL.

Если у вас есть PostgreSQL, вам не нужно создавать реальную таблицу для сопоставления, вы можете сделать что-то вроде:

SELECT *
FROM
(
    VALUES
        ('London server 1', 'london_srv_1'),
        ('London server 2', 'london_srv_2'),
        ('New York server 1', 'ny_srv_1'),
        ('New York server 2', 'ny_srv_2')
) AS t (__text, __value)

Но это не работает с числовыми значениями:

SELECT * FROM (VALUES ('OK', '0'), ('ERROR', '1')) AS t (__text, __value)

При загрузке дашборда:

А при выборе другого параметра

При выборе: OK + ОШИБКА

Если вам нужны числовые значения, вам нужно удалить одинарные кавычки, иначе они интерпретируются как текст, т.е.

SELECT * FROM ( VALUES ( 'OK', 0), ( 'ERROR', 1) ) AS t (__text, __value)

Спасибо @GlennMatthys glenn за ответ, но я уже нашел, где возникает проблема.

SELECT * FROM (VALUES ('OK', 0), ('Warning', 1), ('Critical', 2)) AS t (__text, __value)

Настройка многозначности на:

Бывает

Выбор 3 состояний

И многозначное выключение:

GlennMathys - ваше решение идеально, большое спасибо

Для MySQL это:
SELECT * FROM ( VALUES row('a', 1), row('b', 2) ) AS t (__text, __value)

А Мариадб? У меня это не работает (версия mariaDB: 10.5.5)

SELECT * FROM ( VALUES row('a', 1), row('b', 2) ) AS t (__text, __value);
ERROR 1064 (42000)..............

Или предыдущий:

SELECT * FROM ( VALUES ( 'OK', 0), ( 'Warning', 1), ('Critical', 2) ) AS t (__text, __value);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your 
MariaDB server version for the right syntax to use near '(__text, __value)' at line 1

Похоже, что оператор Values ​​больше не доступен...

Или есть что-то еще, что я делаю неправильно?

@radoeka Для старых версий MariaDB/MySQL

SELECT * FROM
(
    SELECT 'London server 1' AS '__text', 'london_srv_1' AS '__value'
    UNION ALL SELECT 'London server 2', 'london_srv_2'
    UNION ALL SELECT 'New York server 1', 'ny_srv_1'
    UNION ALL SELECT 'New York server 2', 'ny_srv_2'
) AS t;

@GlennMatthys вау вау вау, какой быстрый ответ! И это работает.
Я думал, что использую довольно новую версию mariadb, но это не так (используя дистрибутив Linux, которому всего 2 месяца).
Спасибо.

Кажется, это не поддерживается для Prometheus.

Повторное открытие этой проблемы под номером #27829 решает ее только для статических данных.