Веб-мониторинг и ложные срабатывания

[Arsen Azgaldov]

Коллеги,

Есть задача мониторить 100 одинаковых веб-страниц (камеры). Типовой веб-сценарий настроил так:
http://ip_addressort/Login.htm
Интервал обновления - 60.
Попыток - 5.
Время ожидания - 15.
Требуемый код состояния - 200.

Подскажите, с т.з. best practice, как лучше настроить триггеры (да и остальные параметры), чтобы избежать ложных срабатываний?

Вариант №1.
{site01:web.test.fail[site01: HTTP-test].last()}<>0

Вариант №2.
{site01:web.test.fail[site01: HTTP-test].avg(#5)}<>0

Вариант №3.
{site01:web.test.fail[site01: HTTP-test].avg(300)}<>0

Вариант №4.
{site01:web.test.rspcode[site01: HTTP-test].avg(300)}=0

И еще... Как лучше настроить часы работы, чтобы по ночам не вскакивать? Через триггер или как-то иначе? Так нормально будет?

{site01:web.test.fail[site01: HTTP-test].time()}>100000 and
{site01:web.test.fail[site01: HTTP-test].time()}<210000

Собсно, откуда ноги растут... Ранее было настроено по вар. №4 + часы работы, как в примере. Это привело к тому, что по ночам датчики начинали хаотично менять статус - с Unknown на Normal и обратно - каждые 5 мин. Утром в п/ящике обнаруживал до 10 тыс. сообщений... ((( Сейчас вычитал, что для триггера веб-сценария лучше использовать конструкцию web.test.fail. Но вот с какими параметрами? Менять настройки на всех 100 камерах весьма затруднительно. Поэтому хотелось бы сразу сделать все правильно. Я новичок. Буду страшно благодарен всем, кто откликнется!

[sadman]

Алгоритм мониторинга-то у вас какой задумывался: мониторить камеры на предмет чего и сколько часов в сутки?

[Arsen Azgaldov]

Алгоритм самый простой - доступность html-странички видеорегистратора. Тупо - можно зайти или нет. И только в рабочие часы (днем), каждые 5 или 10 мин.

[aydar]

Интервал обновлений 120сек

{ххх:web.test.rspcode[ххххх,Главная страница].count(600,200)}<3

[Arsen Azgaldov]

Интервал обновлений 120сек

{ххх:web.test.rspcode[ххххх,Главная страница].count(600,200)}<3

Т.е. Вы предлагаете вернуться к web.test.rspcode, вместо web.test.fail... как у меня было изначально, только считать фэйлы за 10 мин. ОК, спасибо! А при таких настройках у Вас не случалось хаотичной смены статусов с Unknown - Normal - Unknown?

[sadman]

Если с web.test.fail, то, полагаю, что-то навроде

{...min(300)}>0;

Т.е. за 300 секунд проверка ни разу не отдала значение "0" - камера плотно висит. Секундные выбросы не должны учитываться.

Время у вас правильно описано в триггере.

[Arsen Azgaldov]

Если с web.test.fail, то, полагаю, что-то навроде

{...min(300)}>0;

Т.е. за 300 секунд проверка ни разу не отдала значение "0" - камера плотно висит. Секундные выбросы не должны учитываться.

Время у вас правильно описано в триггере.

Спасибо!
Осталось решить: делать все-таки через web.test.fail или через web.test.rspcode... Для web.test.rspcode вроде как не требуется настраивать Группы элементов данных - днем все и так работает, зато по ночам кошмарит, правда с другими настройками. Для web.test.fail Группы элементов, как я понял, обязательны. Этот вариант днем - ОК, а ночью еще не успел опробовать...

[Arsen Azgaldov]

Провел эксперимент, может кому пригодится.
Разделил все камеры на 3 группы с примерно равным количеством узлов, но разными настройками. Общее у всех 3-х групп:
Требуемый код состояния: 200
Часы работы: [].time()}>100000 and [].time()}<210000
Время ожидания: 15

1 группа:
Интервал обновления: 60
Попыток: 5
Триггер: web.test.fail[].last()}<>0
-----------------------------------
2 группа:
Интервал обновления: 120
Попыток: 1
Триггер: web.test.rspcode[].count(600,200)}<3
-----------------------------------
3 группа:
Интервал обновления: 120
Попыток: 1
Триггер: web.test.rspcode[].avg(600)}=0

В итоге: 1-я и 3-я группа ночью отработали штатно (т.е. без ложных срабатываний). А вот 2-ю группу продолжало колбасить. Т.е. ночью камеры начинали произвольно менять статус с "Проблема" на "ОК" и обратно. Причем, когда начинается такой период, частота смены статуса примерно равна 10 мин. (иногда больше, иногда меньше).

Теперь вот думаю, какие настройки оставить: вариант 1 или вариант 3... Пока склоняюсь к 1-му, т.к. в большинстве примеров, найденных в инете, веб-мониторинг настраивается через триггер web.test.fail.
Еще сегодня вечером планирую попробовать 4-й вариант, как советует уважаемый sadman:

4 группа:
Интервал обновления: 60
Попыток: 5
Триггер: {web.test.fail[].min(300)}>0

[Arsen Azgaldov]

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

Группа элементов данных - настроить обязательно!
Интервал обновления (в сек): 60-120
Попыток: 3-5
Требуемые коды состояния: 200 (можно воткнуть заголовки)
Триггеры:
{host:web.test.fail[host: доступ по HTTP].last()}<>0 and
{host:web.test.fail[host: доступ по HTTP].time()}>100000 and
{host:web.test.fail[host: доступ по HTTP].time()}<210000
Действия/Условия: A and B
A Состояние обслуживания не в обслуживании
B Значение триггера = ПРОБЛЕМА

Может кому пригодится... Тему можно закрывать.