Примеры сценариев для нагрузочного тестирования#

1) Клиент-генератор подключается к очереди запросов потребителя и эмулирует нагрузку.
2) Тестируемая система/сервис вычитывает сообщение из данной очереди и отправляет сообщение в конечную очередь запроса 
   поставщика.
3) Заглушка вычитывает данное сообщение из конечной очереди запроса поставщика, генерирует и отдает ответ в очередь ответа 
   (обычно в ответ копируется rquid и часть заголовков).
4) Тестируемая система вычитывает сообщение из очереди ответа поставщика и отправляет сообщение в конечную очередь ответа 
   потребителя.
5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом

1) В блоке transport указать подключения к менеджерам:
   Для генератора:
       queueManager – имя менеджера, применяется для протокола IBM MQ и Artemis MQ;
       host – адрес сервера, где "развернут" сервер Artemis MQ (например: 10.хх.хх.хх);
       port – порт подключения (например: 1414);
       request – очередь, куда должен отправлять сообщения генератор;
       response – очередь, откуда должен вычитывать ответные сообщения генератор;
       protocol – наименование протокола;
       channel – Для MQ указывается канал подключения (например: SC.ITECO), применяется для протокола IBM MQ, Artemis MQ, REST.
   Для заглушки:
       queueManager – имя менеджера, применяется для протокола IBM MQ и Artemis MQ;
       host – адрес сервера, где "развернут" сервер IBM MQ (например: 10.хх.хх.хх);
       port – порт подключения (например: 1414);
       request – очередь, откуда должна вычитывать сообщения заглушка;
       response – очередь, куда должна отправлять ответные сообщения заглушка;
       protocol – наименование протокола;
       channel – Для MQ указывается канал подключения (например: SC.ITECO), применяется для протокола IBM MQ, Artemis MQ, REST.
   Если требуется отправить сообщение в очередь, расположенную в другом менеджере, тогда не заполняем поле queueManager

2) В блоке testdata прописываем шаблоны сообщения для генератора и заглушки.
С помощью переменной ${rq_uid} управляем уникальным id сообщения;
С помощью переменной ${rnd_date|<format>} заполняем заголовки и тело сообщения случайными датами и временем заданного формата;
С помощью переменной ${rnd_number|<length>} заполняем заголовки и тело сообщения случайными числовыми строками фиксированной длины.

3) В блоке testplan описать сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    startTPS – начальный TPS в тесте;
    maxTPS – максимальный TPS в тесте;
    stepSize – шаг увеличения нагрузки;
    stepTimeMS – интервал увеличения нагрузки в миллисекундах;
    longTestMin – предельная длительность тестирования НТ в минутах, по завершению которой тест останавливается;
    sendMetricsToKafka – Параметр задает, требуется ли отправлять метрики в kafka (для дальнейшего отображения в Grafana).
        Для генератора:
        Значение по умолчанию – true. Возможные значения:
            true – метрики отправляются.
            false – метрики не отправляются. Но если на генераторе requestTimeStorage = ignite, то генератор будет 
            отправлять метрики при получении ответов с ошибками или в случае таймаутов. Ошибками считаются ответы с тэгами:
            statusCode!=0, statusCode!=200 или expectedStatus !=0 (для HTTP смотри еще expectedStatus).
        Для заглушки:
        Значение по умолчанию – false. Возможные значение:
            true – метрики отправляются.
            false – метрики не отправляются
    requestTimeStorage:"ignite|header|local_cache|none" – 
        Для генератора. Значение по умолчанию – ignite. 
        Возможные значения:
            header – параметр не учитывается
            none – уникальный идентификатор и время отправки каждого запроса, нигде не сохраняются. При локальном запуске 
                   SyTester используется для тестирования 
            ignite – в in-memory кеш ignite записывается уникальный идентификатор и время отправки каждого запроса. 
                     При локальном или централизованном запуске SyTester используется для тестирования:
                     a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ,
                        Artemis MQ, Active MQ, Kafka).
                     b) асинхронных взаимодействий или нотификации для любого протокола, когда метрики будут отсылаться 
                        с заглушки. Т.е. когда нужно вычислить время прохождения запроса от генератора до заглушки. Для 
                        этого случая также нужно выставить sendMetricsToKafka=true на заглушке.
            local_cache – уникальный идентификатор и время отправки каждого запроса сохраняются в локальном кеше. 
                          Используется при локальном запуске SyTester для тестирования:
                          a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ, 
                             Kafka, Artemis MQ, Active MQ).
        Для заглушки параметр следует применять в случае формирования метрик на заглушке (путем выставления параметра 
        sendMetricsToKafka = true), например, когда используется сторонний генератор запросов совместно с заглушкой 
        SyTester или для асинхронных интеграционных сценариев (квитанция/нотификация). Значение по умолчанию – none. 
        Возможные значения:
            ignite – заглушка получает время запроса из in-memory кеша ignite
            header – время запроса берется из заголовка сообщения (requestTime)
            none – используется фиксированная константа 1 мс, кроме протокола IBM MQ (для IBM MQ время запроса берется 
                   из тэга PutTime структуры MQMD).
            local_cache – параметр не учитывается
    metricsServiceName – имя сервиса, соответствующего тестовому плану, при отсылке метрик. Другими словами, имя, 
                         по которому будут отображаться данные в Grafana;
    messageTimeout – таймаут в миллисекундах, в течении которого ожидается ответ для синхронных взаимодействий. 
                     По истечении этого времени в БД метрики отправляется отчет с кодом -105. Необязательный параметр. 
                     Применяется только на генераторе.

1) Клиент-генератор отправляет сообщения (xml/json) в тестируемый сервис/систему;
2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в заглушку.
    Есть два способа настроить заглушку: а) http Route напрямую в заглушку, б) https Route через Ingress;
3) Тестируемый сервис/система получает ответное сообщение от заглушки и отдает ответ в генератор.

1) В блоке transport:
    для генератора указывается:
        host – адрес нагружаемого сервиса (например: sytester-http-stub-XXX.ru);
        port – порт нагружаемого сервиса (например: 80);
        request – path нагружаемого сервиса (например: /stub/json).
    для заглушки заполняется только request – path на котором поднять заглушку (например: /stub/json), 
    после запуска она будет доступна по адресу:
        а) http://sytester-http-stub-XXX.ru/stub/json (пример http Route напрямую в заглушку);
        б) https://sytester-http-ssl-XXX.ru/stub/json (пример https Route через Ingress).
    для соединения по https:
        host – адрес нагружаемого сервиса полностью (например: https://sytester-http-ssl-XXX.ru/stub/json)
        port – порт нагружаемого сервиса (например: 443);
        request – path нагружаемого сервиса (например: /stub/json);
        ssl – сертификаты, привязанные к Pod генератора.

2) В блоке testdata прописываем шаблоны сообщения для генератора и заглушки.
    С помощью переменной ${rq_uid} управляем уникальным id сообщения;
    С помощью переменной ${rnd_date|<format>} заполняем заголовки и тело сообщения случайными датами и временем заданного формата;
    С помощью переменной ${rnd_number|<length>} заполняем заголовки и тело сообщения случайными числовыми строками фиксированной длины.
    В блоке headers можно задать заголовки в формате ключ / значение.

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    startTPS – начальный TPS в тесте;
    maxTPS – максимальный TPS в тесте;
    stepSize – шаг увеличения нагрузки;
    stepTimeMS – интервал увеличения нагрузки в миллисекундах;
    longTestMin – предельная длительность тестирования НТ в минутах, по завершению которой тест останавливается;
    sendMetricsToKafka – Параметр задает, требуется ли отправлять метрики в kafka (для дальнейшего отображения в Grafana).
        Для генератора:
        Значение по умолчанию – true. Возможные значения:
            true – метрики отправляются.
            false – метрики не отправляются. Но если на генераторе requestTimeStorage = ignite, то генератор будет 
            отправлять метрики при получении ответов с ошибками или в случае таймаутов. Ошибками считаются ответы с тэгами:
            statusCode!=0, statusCode!=200 или expectedStatus !=0 (для HTTP смотри еще expectedStatus).
        Для заглушки:
        Значение по умолчанию – false. Возможные значение:
            true – метрики отправляются.
            false – метрики не отправляются
    requestTimeStorage:"ignite|header|local_cache|none" – 
        Для генератора. Значение по умолчанию – ignite. 
        Возможные значения:
            header – параметр не учитывается
            none – уникальный идентификатор и время отправки каждого запроса, нигде не сохраняются. При локальном запуске 
                   SyTester используется для тестирования 
            ignite – в in-memory кеш ignite записывается уникальный идентификатор и время отправки каждого запроса. 
                     При локальном или централизованном запуске SyTester используется для тестирования:
                     a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ,
                        Artemis MQ, Active MQ, Kafka).
                     b) асинхронных взаимодействий или нотификации для любого протокола, когда метрики будут отсылаться 
                        с заглушки. Т.е. когда нужно вычислить время прохождения запроса от генератора до заглушки. Для 
                        этого случая также нужно выставить sendMetricsToKafka=true на заглушке.
            local_cache – уникальный идентификатор и время отправки каждого запроса сохраняются в локальном кеше. 
                          Используется при локальном запуске SyTester для тестирования:
                          a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ, 
                             Kafka, Artemis MQ, Active MQ).
        Для заглушки параметр следует применять в случае формирования метрик на заглушке (путем выставления параметра 
        sendMetricsToKafka = true), например, когда используется сторонний генератор запросов совместно с заглушкой 
        SyTester или для асинхронных интеграционных сценариев (квитанция/нотификация). Значение по умолчанию – none. 
        Возможные значения:
            ignite – заглушка получает время запроса из in-memory кеша ignite
            header – время запроса берется из заголовка сообщения (requestTime)
            none – используется фиксированная константа 1 мс, кроме протокола IBM MQ (для IBM MQ время запроса берется 
                   из тэга PutTime структуры MQMD).
            local_cache – параметр не учитывается
    metricsServiceName – имя сервиса, соответствующего тестовому плану, при отсылке метрик. Другими словами, имя, 
                         по которому будут отображаться данные в Grafana;
    messageTimeout – таймаут в миллисекундах, в течении которого ожидается ответ для синхронных взаимодействий. 
                     По истечении этого времени в БД метрики отправляется отчет с кодом -105. Необязательный параметр. 
                     Применяется только на генераторе.

1) Клиент-генератор отправляет сообщения в тестируемый сервис/систему;
2) Тестируемый сервис/система получает сообщение от генератора и отправляет сообщение в заглушку;
3) Тестируемый сервис/система получает ответное сообщение от заглушки и отдает ответ в генератор.

1) В блоке transport
  для генератора указывается, port, request – это адрес
      host – адрес нагружаемого сервиса (например: sytester-http-stub-XXX.ru);
      port – порт нагружаемого сервиса (например: 80);
      request – <полный путь до пакета>.<имя grpc сервиса>.<имя метода> (например io.github.helloworlde.grpc.HelloService.SayHello);
      ssl.ssl_certfile – путь до клиентского сертификата;
      ssl.ssl_keyfile – путь до клиентского ключа.
  для заглушки заполняется только response – <полный путь до пакета>.<имя grpc сервиса>.<имя метода> 
  (например io.github.helloworlde.grpc.HelloService.SayHello).

2) В блоке testdata прописываем шаблоны сообщения для генератора и заглушки в формате json (они автоматически будут преобразованы к proto формату).
    С помощью переменной ${rq_uid} управляем уникальным id сообщения;
    С помощью переменной ${rnd_date|<format>} заполняем заголовки и тело сообщения случайными датами и временем заданного формата;
    С помощью переменной ${rnd_number|<length>} заполняем заголовки и тело сообщения случайными числовыми строками фиксированной длины.
    В блоке headers можно задать заголовки в формате ключ/значение.

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    startTPS – начальный TPS в тесте
    maxTPS – максимальный TPS в тесте
    stepSize – шаг увеличения нагрузки
    stepTimeMS – время в миллисекундах, после которого увеличивать нагрузку на stepSize
    retryCount – Кол-во переподключений заглушки по протоколам: MQ (IBM, Active, Artemis) и Kafka или кол-во перезапусков 
                 всех шагов интеграционных тестов (action: ONERUN/NT). По-умолчанию равен 0. Работает вместе с retryDelayTime
    retryDelayTime – Время в миллисекундах между попытками переподключения (для заглушек) или попытками перезапуска всех 
                     шагов интеграционного теста (action: ONERUN/NT). По-умолчанию равен 30000 (30 секунд). Работает вместе с retryCount

1) Клиент-генератор отправляет сообщения в тестируемый сервис/систему по протоколу gRPC;
2) Тестируемый сервис/система получает сообщение от генератора, на его основе формирует MQ запрос и отправляет его в заглушку;
3) Тестируемый сервис/система получает ответное сообщение от MQ заглушки, на его основе обратно формирует ответное gRPC 
   сообщение и отправляет его в заглушку gRPC.

Из особенностей:
    messageFormat – xmlInJson, данный параметр позволяет достать для анализа (например, для извлечения rquid) xml сообщение 
    из тега body json сообщения, т.к в шлюзе MQ xml сообщение передается внутри тега body grpc сообщения
    sendMetricsToKafka – true, данный параметр установлен на заглушке, которая получает асинхронный ответ

1) Клиент-генератор подключается к topic(s) запросов потребителя и эмулирует нагрузку;
2) Тестируемая система/сервис вычитывает сообщение из данного topic(s) и отправляет сообщение в конечный topic(s) запроса поставщика;
3) Заглушка вычитывает данное сообщение из конечного topic(s) запроса поставщика, генерирует и отдает ответ в topic(s) ответа;
4) Тестируемая система вычитывает сообщение из topic(s) ответа поставщика и отправляет сообщение в конечный topic(s) ответа потребителя;
5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

1) В блоке transport указываем подключения к брокерам:
    protocol: "KAFKA";
    host/port брокеров kafka;
    request - topic(s), в который будет писать генератор (или topic(s) из которого будет читать заглушка);
    response - topic(s), из которого будет читать генератор (или topic(s) в который будет отвечать заглушка);

2) В блоке testdata прописываем шаблоны сообщения для генератора и заглушки
    С помощью переменной ${rq_uid} управляем уникальным id сообщения;
    С помощью переменной ${rnd_date|<format>} заполняем заголовки и тело сообщения случайными датами и временем заданного формата;
    С помощью переменной ${rnd_number|<length>} заполняем заголовки и тело сообщения случайными числовыми строками фиксированной длины.

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    startTPS – начальный TPS в тесте;
    maxTPS – максимальный TPS в тесте;
    stepSize – шаг увеличения нагрузки;
    stepTimeMS – время в миллисекундах, после которого увеличивать нагрузку на stepSize.

1) Клиент-генератор подключается к очереди запросов потребителя и эмулирует нагрузку;
2) Тестируемая система/сервис вычитывает сообщение из данной очереди и отправляет сообщение в конечную очередь запроса
   поставщика;
3) Заглушка вычитывает данное сообщение из конечной очереди запроса поставщика, генерирует и отдает ответ в очередь
   ответа (обычно в ответ копируется rquid и часть заголовком);
4) Тестируемая система вычитывает сообщение из очереди ответа поставщика и отправляет сообщение в конечную очередь
   ответа потребителя;
5) Клиент-генератор получает данный ответ и коррелирует его со своим запросом.

1) В блоке transport указываем подключения к серверам:
    Для генератора:
        host – адрес сервера, где "развернут" сервер Active MQ (например: tcp://active-mq:61616);
        port – порт для тестовых планов по протоколу Active MQ указывать не требуется. Можно указать значение "0";
        request – очередь, куда должен отправлять сообщения генератор;
        response – очередь, откуда должен вычитывать ответные сообщения генератор;
        login – если требуется авторизация при подключении к серверу, в данное поле укажите логин, применяется для протокола Active MQ;
        password – если требуется авторизация при подключении к серверу, в данное поле укажите пароль, применяется для протокола Active MQ.
   Для заглушки:
        host – адрес сервера, где "развернут" сервер Active MQ (например: tcp://active-mq:61616);
        port – порт для тестовых планов по протоколу Active MQ указывать не требуется. Можно указать значение "0";
        request – очередь, откуда должна вычитывать заглушка;
        response – очередь, куда должна отправлять ответные сообщения заглушка;
        login – если требуется авторизация при подключении к серверу, в данное поле укажите логин, применяется для протокола Active MQ;
        password – если требуется авторизация при подключении к серверу, в данное поле укажите пароль, применяется для протокола Active MQ.

2) В блоке testdata прописываем шаблоны сообщения для генератора и заглушки.
    С помощью переменной ${rq_uid} управляем уникальным id сообщения;
    С помощью переменной ${rnd_date|<format>} заполняем заголовки и тело сообщения случайными датами и временем заданного формата;
    С помощью переменной ${rnd_number|<length>} заполняем заголовки и тело сообщения случайными числовыми строками фиксированной длины.

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    startTPS – начальный TPS в тесте;
    maxTPS – максимальный TPS в тесте;
    stepSize – шаг увеличения нагрузки;
    stepTimeMS – интервал увеличения нагрузки в миллисекундах;
    longTestMin – предельная длительность тестирования НТ в минутах, по завершению которой тест останавливается;
    sendMetricsToKafka – Параметр задает, требуется ли отправлять метрики в kafka (для дальнейшего отображения в Grafana).
        Для генератора:
        Значение по умолчанию – true. Возможные значения:
            true – метрики отправляются.
            false – метрики не отправляются. Но если на генераторе requestTimeStorage = ignite, то генератор будет 
            отправлять метрики при получении ответов с ошибками или в случае таймаутов. Ошибками считаются ответы с тэгами:
            statusCode!=0, statusCode!=200 или expectedStatus !=0 (для HTTP смотри еще expectedStatus).
        Для заглушки:
        Значение по умолчанию – false. Возможные значение:
            true – метрики отправляются.
            false – метрики не отправляются
    requestTimeStorage:"ignite|header|local_cache|none" – 
        Для генератора. Значение по умолчанию – ignite. 
        Возможные значения:
            header – параметр не учитывается
            none – уникальный идентификатор и время отправки каждого запроса, нигде не сохраняются. При локальном запуске 
                   SyTester используется для тестирования 
            ignite – в in-memory кеш ignite записывается уникальный идентификатор и время отправки каждого запроса. 
                     При локальном или централизованном запуске SyTester используется для тестирования:
                     a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ,
                        Artemis MQ, Active MQ, Kafka).
                     b) асинхронных взаимодействий или нотификации для любого протокола, когда метрики будут отсылаться 
                        с заглушки. Т.е. когда нужно вычислить время прохождения запроса от генератора до заглушки. Для 
                        этого случая также нужно выставить sendMetricsToKafka=true на заглушке.
            local_cache – уникальный идентификатор и время отправки каждого запроса сохраняются в локальном кеше. 
                          Используется при локальном запуске SyTester для тестирования:
                          a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ, 
                             Kafka, Artemis MQ, Active MQ).
        Для заглушки параметр следует применять в случае формирования метрик на заглушке (путем выставления параметра 
        sendMetricsToKafka = true), например, когда используется сторонний генератор запросов совместно с заглушкой 
        SyTester или для асинхронных интеграционных сценариев (квитанция/нотификация). Значение по умолчанию – none. 
        Возможные значения:
            ignite – заглушка получает время запроса из in-memory кеша ignite
            header – время запроса берется из заголовка сообщения (requestTime)
            none – используется фиксированная константа 1 мс, кроме протокола IBM MQ (для IBM MQ время запроса берется 
                   из тэга PutTime структуры MQMD).
            local_cache – параметр не учитывается
    metricsServiceName – имя сервиса, соответствующего тестовому плану, при отсылке метрик. Другими словами, имя, 
                         по которому будут отображаться данные в Grafana;
    messageTimeout – таймаут в миллисекундах, в течении которого ожидается ответ для синхронных взаимодействий. 
                     По истечении этого времени в БД метрики отправляется отчет с кодом -105. Необязательный параметр. 
                     Применяется только на генераторе.

1) В блоке transport для генератора указывается port, request – это адрес:
   Для генератора:
      queueManager – имя менеджера, применяется для протокола IBM MQ и Artemis MQ;
      host – адрес сервера, где "развернут" сервер Artemis MQ (например: 10.хх.хх.хх);
      port – порт подключения (например: 1414);
      request – очередь, куда должен отправлять сообщения генератор;
      response – очередь, откуда должен вычитывать ответные сообщения генератор;
      protocol – протокол доставки сообщений, одно значение из списка (HTTP, MQ, Kafka, gRPC, Active MQ, Artemis MQ);
      channel – Для MQ указывается канал подключения (например: SC.ITECO), применяется для протокола IBM MQ, Artemis MQ, REST
                возможные значения: GET – для GET вызова, PUT – для PUT вызова (Если не указано значение, будет выполнен post запрос).
   Для заглушки:
      queueManager – имя менеджера, применяется для протокола IBM MQ и Artemis MQ;
      host – адрес сервера, где "развернут" сервер Artemis MQ (например: 10.хх.хх.хх);
      port – порт подключения (например: 1414);
      request – очередь, откуда должна вычитывать сообщения заглушка;
      response – очередь, куда должна отправлять ответные сообщения заглушка;
      protocol – наименование протокола;
      channel – Для MQ указывается канал подключения (например: SC.ITECO), применяется для протокола IBM MQ, Artemis MQ, REST.
                возможные значения: GET – для GET вызова, PUT – для PUT вызова (Если не указано значение, будет выполнен post запрос).
  
   Настройка ssl подключения, сертификаты из примера уже доступны из коробки, их будет достаточно для большинства случаев.
   Настройки SSL:
      ssl.ssl_cafile – файл доверенных ключей SSL;
      ssl.ssl_capass – пароль к файлу доверенных ключей;
      ssl.ssl_keyfile – файл SSL ключей шифрования;
      ssl.ssl_keypass – пароль к ключу шифрования;
      ssl.ssl_keyfilepass – Пароль к файлу ключей шифрования;
      ssl.sslPeerName – Для MQ – идентификатор канала при подключении по SSL;
      ssl.ssl_certfile – файл сертификат.

2) В блоке testdata прописываем шаблоны сообщения для генератора и заглушки.
  С помощью переменной ${rq_uid} управляем уникальным id сообщения;
  С помощью переменной ${rnd_date|<format>} заполняем заголовки и тело сообщения случайными датами и временем заданного формата;
  С помощью переменной ${rnd_number|<length>} заполняем заголовки и тело сообщения случайными числовыми строками фиксированной длины.

3) В блоке testplan описываем сам сценарий тестирования, связывая его с сообщениями и подключениями по их именам:
    startTPS – начальный TPS в тесте;
    maxTPS – максимальный TPS в тесте;
    stepSize – шаг увеличения нагрузки;
    stepTimeMS – интервал увеличения нагрузки в миллисекундах;
    longTestMin – предельная длительность тестирования НТ в минутах, по завершению которой тест останавливается;
    sendMetricsToKafka – Параметр задает, требуется ли отправлять метрики в kafka (для дальнейшего отображения в Grafana).
        Для генератора:
        Значение по умолчанию – true. Возможные значения:
            true – метрики отправляются.
            false – метрики не отправляются. Но если на генераторе requestTimeStorage = ignite, то генератор будет 
            отправлять метрики при получении ответов с ошибками или в случае таймаутов. Ошибками считаются ответы с тэгами:
            statusCode!=0, statusCode!=200 или expectedStatus !=0 (для HTTP смотри еще expectedStatus).
        Для заглушки:
        Значение по умолчанию – false. Возможные значение:
            true – метрики отправляются.
            false – метрики не отправляются
    requestTimeStorage:"ignite|header|local_cache|none" – 
        Для генератора. Значение по умолчанию – ignite. 
        Возможные значения:
            header – параметр не учитывается
            none – уникальный идентификатор и время отправки каждого запроса, нигде не сохраняются. При локальном запуске 
                   SyTester используется для тестирования 
            ignite – в in-memory кеш ignite записывается уникальный идентификатор и время отправки каждого запроса. 
                     При локальном или централизованном запуске SyTester используется для тестирования:
                     a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ,
                        Artemis MQ, Active MQ, Kafka).
                     b) асинхронных взаимодействий или нотификации для любого протокола, когда метрики будут отсылаться 
                        с заглушки. Т.е. когда нужно вычислить время прохождения запроса от генератора до заглушки. Для 
                        этого случая также нужно выставить sendMetricsToKafka=true на заглушке.
            local_cache – уникальный идентификатор и время отправки каждого запроса сохраняются в локальном кеше. 
                          Используется при локальном запуске SyTester для тестирования:
                          a) синхронных взаимодействий (ожидание ответа заданное время) для асинхронных протоколов (IBM MQ, 
                             Kafka, Artemis MQ, Active MQ).
        Для заглушки параметр следует применять в случае формирования метрик на заглушке (путем выставления параметра 
        sendMetricsToKafka = true), например, когда используется сторонний генератор запросов совместно с заглушкой 
        SyTester или для асинхронных интеграционных сценариев (квитанция/нотификация). Значение по умолчанию – none. 
        Возможные значения:
            ignite – заглушка получает время запроса из in-memory кеша ignite
            header – время запроса берется из заголовка сообщения (requestTime)
            none – используется фиксированная константа 1 мс, кроме протокола IBM MQ (для IBM MQ время запроса берется 
                   из тэга PutTime структуры MQMD).
            local_cache – параметр не учитывается
    metricsServiceName – имя сервиса, соответствующего тестовому плану, при отсылке метрик. Другими словами, имя, 
                         по которому будут отображаться данные в Grafana;
    messageTimeout – таймаут в миллисекундах, в течении которого ожидается ответ для синхронных взаимодействий. 
                     По истечении этого времени в БД метрики отправляется отчет с кодом -105. Необязательный параметр. 
                     Применяется только на генераторе.