AK
https://stackoverflow.com/questions/54931888/query-tags-from-influxdb-with-respect-of-timefilter-for-grafana-variables-templa
Вот еще вариант как выбрать теги по времени
Вот еще вариант как выбрать теги по времени
Size: a a a
2020 January 16
AK
не пробовал, просто нагуглил, пусть тут и полежит
ВС
Точно. DISTINCT даст тот же эффект, что и GROUP BY
ВС
Вот такой получилась доска для Gatling. На одной странице отображается сначала
* общая информация ("General Information")
* потом сводная информация по всем выбранным в фильтре подзапросоам и группам — раздел "Detail"
* потом ниже для каждого запроса детальная информация (за счёт Repeat панелей)
Страница выходит длинной при большом количестве запросов. Но фильтры сделаны гибко.
* общая информация ("General Information")
* потом сводная информация по всем выбранным в фильтре подзапросоам и группам — раздел "Detail"
* потом ниже для каждого запроса детальная информация (за счёт Repeat панелей)
Страница выходит длинной при большом количестве запросов. Но фильтры сделаны гибко.
ВС
Ещё надо, чтобы детальная статистика по группам отображалась. И будет готово.
KY
#grafana #influxdb
Есть проблема, что в выпадающих списках Grafana, может быть очень много данных. Если не применять фильтрацию по времени.
И простой способ применить фильтр по времени выглядит так:
При применении Query options / Refresh = On Time Range Change.
Но у этого способа есть недостаток. SHOW TAG VALUES применяет фильтр по $timeFilter, округляя его до размера InfluxDB Shard.
Некоторое время назад советовал даже уменьшить временной интервал Shard для большой точности. В результате @login40k потерял историю данных InflxuDB, так как шарды пересоздались.
Есть безопасный способ сократить длину фильтра. Для этого понадобится просто переписать запрос выбора значений. Не меняя настройки InfxluDB:
Тут выбирается измерение, в котором есть нужный тег и большое количество точек ("gatling"). Выбирается поле, которое заполнено для всех точек ("mean"). Значения поля группируются по нужному тегу, берётся только последнее значение для тега, а далее из результатов выводится только сам тег.
Это позволяет сделать выпадающий список только с теми значениями, что точно соотвествуют выбранному интервалу времени в Grafana.
Есть проблема, что в выпадающих списках Grafana, может быть очень много данных. Если не применять фильтрацию по времени.
И простой способ применить фильтр по времени выглядит так:
SHOW TAG VALUES FROM "gatling" WITH KEY = "simulation" WHERE $timeFilter
При применении Query options / Refresh = On Time Range Change.
Но у этого способа есть недостаток. SHOW TAG VALUES применяет фильтр по $timeFilter, округляя его до размера InfluxDB Shard.
Некоторое время назад советовал даже уменьшить временной интервал Shard для большой точности. В результате @login40k потерял историю данных InflxuDB, так как шарды пересоздались.
Есть безопасный способ сократить длину фильтра. Для этого понадобится просто переписать запрос выбора значений. Не меняя настройки InfxluDB:
SELECT "simulation" FROM (SELECT last("mean") FROM "gatling" WHERE $timeFilter GROUP BY "simulation")Тут выбирается измерение, в котором есть нужный тег и большое количество точек ("gatling"). Выбирается поле, которое заполнено для всех точек ("mean"). Значения поля группируются по нужному тегу, берётся только последнее значение для тега, а далее из результатов выводится только сам тег.
Это позволяет сделать выпадающий список только с теми значениями, что точно соотвествуют выбранному интервалу времени в Grafana.
я тоже столкнулся с этой проблемой, делаю все переменные с фильтром билда/проекта/еще чего нибудь, а саму переменную билда тоже делаю выборной. к слову вот так можно селектить тэги select b from (select key, tag as b from table where some filter) - суть в том что просто тег селектнуть нельзя с фильтром
KY
билд приписываю каждой записи в бд
ВС
я тоже столкнулся с этой проблемой, делаю все переменные с фильтром билда/проекта/еще чего нибудь, а саму переменную билда тоже делаю выборной. к слову вот так можно селектить тэги select b from (select key, tag as b from table where some filter) - суть в том что просто тег селектнуть нельзя с фильтром
Тег можно выбрать с фильтром:
Но тот, способ, что у тебя уже есть — лучше. Так как там фильтрация по времени точная.
SHOW TAG VALUES FROM "gatling.users" WITH KEY = "request" WHERE ("simulation" =~ /^$simulation$/ AND ...) AND $timeFilterНо тот, способ, что у тебя уже есть — лучше. Так как там фильтрация по времени точная.
KY
но в jmeter проще - передал как параметр -J.... дальше в back-end listener кладу его в nodeName
KY
Тег можно выбрать с фильтром:
Но тот, способ, что у тебя уже есть — лучше. Так как там фильтрация по времени точная.
SHOW TAG VALUES FROM "gatling.users" WITH KEY = "request" WHERE ("simulation" =~ /^$simulation$/ AND ...) AND $timeFilterНо тот, способ, что у тебя уже есть — лучше. Так как там фильтрация по времени точная.
странно, но у меня не работало и я даже в SO находил схожие проблемы у людей. я попробую
2020 January 17
VG
Господа, а почему через несколько часов работы с окном логов Jmeter создаётся желание заделать я в контрибуторы Jmeter. Например добавить контекстное меню очистки. И, да, перевод на русский они тоже забыли
У меня во всех сценариях добавлена setup thread group, в которой только один скрипт - очищающий все логи при старте сценария
VG
https://t.me/qa_automation - тут Баранцев тоже есть и очень часто вступает в дискуссии)
Чёт на первый взгляд, основное, что там обсуждается - это с какими тупыми вопросами к ним приходят
Ну их
Ну их
AK
У меня во всех сценариях добавлена setup thread group, в которой только один скрипт - очищающий все логи при старте сценария
К стати да, каждый раз себе скрипт пишу по удалению логов
AK
Может пора его в поставку включить 😂
AK
Чёт на первый взгляд, основное, что там обсуждается - это с какими тупыми вопросами к ним приходят
Ну их
Ну их
Ахахахаха 😭 вот это пипец конечно 🥺
VG
Может пора его в поставку включить 😂
Лучше в виде галочки «очищать результаты при запуске»
AK
Да, имбовое решение
AK
Лучше чем батник
AK
Ибо после не нужно будет растартовать жметр