Триггер, срабатывающий на последние 3 измерения

[Jehn]

Всем привет.
Имею веб-сценарий, который всегда отдает 302. Хочу, чтобы если 3 измерения подряд были не равны 302, то триггер выстреливал.
Насколько правильно будет использовать count? Вот так: count(код_веб_сценария,#3,,"302")=0

В шаблонах из инета везде используется min и max, но не могу понять логику работы и как применить их к моему триггеру.

[Semiadmin]

На мой взгляд, лучше добавить 302 в список Required status codes и делать триггер не на status code 302, а на неуспешно выполненный сценарий. Хотя весьма вероятно, что после установки галки Follow redirects будет получен код 200, а не 302.

[Kos]

Всем привет.
Имею веб-сценарий, который всегда отдает 302. Хочу, чтобы если 3 измерения подряд были не равны 302, то триггер выстреливал.
Насколько правильно будет использовать count? Вот так: count(код_веб_сценария,#3,,"302")=0

В шаблонах из инета везде используется min и max, но не могу понять логику работы и как применить их к моему триггеру.

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

Примеры из Интернета, наверное, относились к другим метрикам - чему-то вроде icmpping, которые возвращают либо ноль, либо единицу. Тогда да, max(#5)=0 будет означать, что из пяти последних значений ни одной единицы не было.

[Semiadmin]

Предполагаю, что в "шаблонах из интернета" был триггер вроде web.test.fail[Scenario].min(#3)>0, т.е. на неоднократное неудачное завершение сценария.
Это лучше, чем считать web.test.rspcode[Scenario,Step], ибо при таймауте статус код не будет получен (старые версии, если не ошибаюсь, до 3.2, возвращали 0).
Т.о., триггер с подсчетом кодов 302 не среагирует на провал сценария из-за таймаута.

[Jehn]

Предполагаю, что в "шаблонах из интернета" был триггер вроде web.test.fail[Scenario].min(#3)>0, т.е. на неоднократное неудачное завершение сценария.
Это лучше, чем считать web.test.rspcode[Scenario,Step], ибо при таймауте статус код не будет получен (старые версии, если не ошибаюсь, до 3.2, возвращали 0).
Т.о., триггер с подсчетом кодов 302 не среагирует на провал сценария из-за таймаута.

Реализовал с count все же. Там логика понятна и работает. А с min\max не могу понять как работает. Если вот такое выражение min(/New Windows/system.cpu.util,5m)>95 то как работает? Если хотя бы одно измерение за 5 минут будет больше 95, то триггер сработает. Просто задержка у него будет 5 минут. А с count тут можно сделать, чтобы срабатывало, если все значения в течение 5 минут были больше 95.

[Kos]

А с min\max не могу понять как работает. Если вот такое выражение min(/New Windows/system.cpu.util,5m)>95 то как работает? Если хотя бы одно измерение за 5 минут будет больше 95, то триггер сработает. Просто задержка у него будет 5 минут.

Нет, не сработает. С min()>95 триггер сработает только если не одно, а все значения за указанный период были строго больше.
Поскольку если уж минимальное значение больше 95, то остальные значения - тем более не меньше, чем минимальное.
А как только появится хоть одно значение, не превышающее этот порог, то триггер сразу же и закроется (поскольку условие перестанет выполняться).

[Jehn]

Нет, не сработает. С min()>95 триггер сработает только если не одно, а все значения за указанный период были строго больше.
Поскольку если уж минимальное значение больше 95, то остальные значения - тем более не меньше, чем минимальное.
А как только появится хоть одно значение, не превышающее этот порог, то триггер сразу же и закроется (поскольку условие перестанет выполняться).

Да, действительно работает. Спасибо зза разъяснение!