Если специфичный можно его импортнуть в jks файл с помощью keytool

Ну, в логе что ты показал ошибка при попытке использовать файл jks (java key store, это типа хранилище сертификатов, ключей)

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

Твой сервер требует клиентский сертификат?
Проверить это можно просто:
Попробуй постучаться на сервер из браузера, где сертификата точно нету

Например, мозилла использует своё хранилище сертификатов. Если ты её не использовал - поставь и попробуй поработать со своим сайтом.

Если ты и так используешь мозиллу - запусти её с ключиком -p и создай новый профиль, попробуй из него.

Вот в PostgreSQL 13 и 14 мой мониторинг надо будет переписать. Там теперь Total time (колонка time) из pg_stat_statements разделилась на execTime и planTime.

И вообще много чего можно улучшить в плане детализации.

Но основной момент с InfluxDB в том, что это приемник данных, в котором есть механизм continuous query, встроенный и retention policy из коробки.

Так и получается долговременное хранение. Месяцы, может годы.

С Prometheus ориентируются на дни и недели.

Ckickhouse также планирую попробовать. Через такую связку: telegraf -> json в kafka -> адаптер kafka-clickhouse -> ckickhouse.

Retention policy там есть. Механизм continuous query сделаю внешним. Потенциально будет более высокая скорость, чем с InfluxDB.

А текущий механизм будет, как первый рабочий вариант, который нужно повторить

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

Комментарий - это очень хорошо. Тот который из Hibernate. Часто только он позволяет найти запрос, участок кода. А иногда запроса на HQL вообще нет, есть только JPA вызов из repository, который все сгенерировал. Комментарии да, нужны, удобно, что они включаются через опции.

Кстати залью, счас примеры, где пробовал сохранять комментарии, и смотрел, меняется ли QueryID при смене комментария.

У меня получилось, что в статистику попадал только первый запрос с комментарием. То есть. Комментарий в статистику попадет. Но если у одного запроса каждый раз новый комментарий, то множественное попадание не будет делаться.

Причин не знаю. Может просто "единичные" запросы, не всегда попадают в статистику. Или их статистика объединяется со статистикой по запросам с таким же Query ID. Тут я ещё не понял до конца

Для генерируемых в Hibernate комментариев такой проблемы нет. Там же в комментарии текст на HQL, а он не меняется от выполнения к выполнению. Там лишь иногда случаются сбои вида добавления в where условий

And (1=1) ...

Угу, интересно.

А если сервис небольшой, и в нем лишь одно место, где например, получаем мы курс валюты. То найти его можно по смыслу

В этом удобство микросервисов. Они небольшие

Ну да, в маленьком сервисе можно и руками все найти.

А influx2 не пробовал вместо кликхауса?

Подумал. 80% случаев, даже 90%. Это когда не надо кастомизировать JPA или что-то менять на HQL, SQL. А надо просто индекс добавить нужный.
Поэтому искать участок кода надо если утечка транзакций. Или если видно, что вместо простого запроса сгенерировалось что-то с подзапросами.
А в основном достаточно статистики, по которой будет принято решение добавить индекс, а запрос останется прежним.

Как пример. Недавно видел такую генерацию со стороны JPA, код правильный, но медленный:

select *
from myTable t1
where 
    field1='test' and 
    begin_date=(
        select max(begin_date) 
        from myTable t2 
        where t1.field1=t2.field1)

ее вот стоит переписать на такое
select *
from myTable t1
where
   field1='test' and
oder by begin_date DESC
limit 1

Пока нет. Все еще планирую использовать Gatling. Для него нет возможности интегрироваться с InfluxDB 2.0. Только если свой адаптер написать. И это меня как-то останавливает.

Хотя, тоже небольшая проблема. Надо бы сделать утилитку на Java, которую можно встроить куда угодно, передав ей параметры - путь к логу gatling и адрес InfluxDB. Будет работать по завершению тестирования.

А вот InfluxDB 1.8 с Flux синтаксисом пробую, начал изучать

Без сомнения протокол InfluxDB даже первой версии удобнее, чем Graphite. Хотя бы потому, что при передаче пробелов они не теряются.

Для хранения имен транзакций из теста не так критично. Что будет в отчете.

Авторизация пользователя (TC)

или

Авторизация-пользователя-(TC)

А вот хранить так тексты SQL-запросов было бы крайне сложно.

Поэтому написать адаптер Gatling->InfluxDB 1/2 перспективнее.
Во время теста будет отправляться только Summary, штатными средствами, как в Graphite. Чтобы смотреть - хорошо ли идет тест.
А после теста будет заливаться вся статистика, уже утилиткой. Возможно с разными настройками шага группировки: 10 сек, 2 минуты, 5 минут. И сразу в разные retention policy. Чтобы не пришлось городить continious query на стороне InfluxDB вообще.

Нет, Gatling с Influx 2.0 отлично работает

И как?

Нашел, что vector умеет читать Graphite
https://github.com/timberio/vector/issues/674

А в InxluxDB 2.0 можно из vactor отправить:
https://vector.dev/docs/reference/configuration/sinks/influxdb_metrics/

Доберусь до дома, скину конфиг
Там довольно все тривиально

Там суть что надо поднять telegraf с таким вот конфигом
[[outputs.influxdb_v2]]
 urls = ["http://influxdb:8086"]
 token = "mytoken"
 organization = "org"
 bucket = "gatling"

[[inputs.socket_listener]]
service_address = "tcp://:2003"
data_format = "graphite"
templates = [
   ….
]

и стрелять с гатлинга так же само на 2003 порт

Здорово. Спасибо!
#gatling #influxdb2

не за что)
вообще надо будет какую-то подробную инструкцию написать… как это всё поднять и завести
плюс выложить свою борду для gatling на flux..

никак руки не дойдут)