Триггер web мониторинга

[niklep]

Доброго дня.
Использую следующий триггер для определения того, что веб-мониторинг сбойнул из-за превышения таумаута:

{<hostname>_FROM_BARNAUL:web.test.fail[Check HTTPS port 8081].[B]min([/B]#2[B])[/B]}>0 and {<hostname>_FROM_BARNAUL:web.test.error[Check HTTPS port 8081].[B]str([/B]Timeout was reached,#2[B])[/B]}=1

В двух словах его смысл: если в сценарии возникла ошибка "Timeout was reached" (при этом для уверенности берется 2 проверки), то поднимаем триггер.

Так вот возникла проблема, что триггер сработал в ситуации, когда ошибка была другая.
Все данные на скриншоте, но я еще прокомментирую словами:
- В 12:22:09 поднимается триггер "Timeout error".
- По номеру сбойного шага (=1) проверки видно, что к 12:22:09 2 проверки завершились ошибкой.
- По содержанию ошибок видно, что в последних 2 сообщениях об ошибке нет строки "Timeout was reached". Текущая проблема - это код 502.
--- Но тем не менее триггер сработал, чего по моей задумке не должно было произойти.

Мое предположение: в момент проверки триггера в таблице с ошибками еще нет данных за 12:22:09, так как СУБД их еще не скинула на диск. И в итоге проверка проходит не так, как задумано. А виновата конкретно опция СУБД
innodb_flush_log_at_trx_commit = 2


Вопросы:
1. Верно ли мое предположение насчет СУБД?
2. Чтобы не менять innodb_flush_log_at_trx_commit на =1 в ущерб производительности, может кто посоветует более удачные триггеры для мониторинга web ресурсов?
Применять item net.tcp.service[http] не хочу, так как он подчиняется параметру Timeout из конфиг файла, и увеличивать его не хочу.

[Kos]

Если я правильно понимаю логику работы сервера Zabbix, то одной из его особенностей является то, что все поступающие новые данные сериализуются и обрабатываются последовательно независимо друг от друга: на каждое новое значение полностью пересчитывается триггер, в состав которого входит данная метрика. И никто не гарантирует порядок обработки этих значений в случае, когда, по Вашему мнению, они приходят "одновременно".

Скажем, в данном случае используются две метрики: web.test.fail и web.test.error. По логике, они приходят одновременно; но обрабатываться всё равно будут последовательно и неизвестно, в каком именно порядке. Запросто может оказаться, что первой будет обработано новое значение метрики web.test.fail (пришедшая в 12:22:09 вторая подряд единица). Триггер пересчитывается, в состав триггера входит также и метрика web.test.error; однако, новое её значение ещё находится в очереди на обработку, и выражение web.test.error[...]str(Timeout was reached,#2) обрабатывает последние два значения из базы (за 12:20:58 PM и за 01:37:37 AM), одно из которых искомую строку содержит - поэтому триггерная функция str() возвращает единицу, и триггер срабатывает.
Сразу же за этим обрабатывается следующее значение из очереди: новое значение для метрики web.test.error. Триггер снова пересчитывается целиком, в этот раз уже функция str() вернёт ноль; но поздно: триггер уже сработал, и более того - условие для Recovery не позволяет ему тут же закрыться обратно (он будет висеть в состоянии PROBLEM, пока последние три значения метрики web.test.fail не вернут нули).

Решением может являться, например, проверка "свежести" последнего значения нужной метрики с помощью функции count().
"Свежим" можно считать значение, возраст которого заведомо меньше интервала опроса.
Скажем, для данного случая можно модифицировать условие триггера следующим образом:

{<hostname>_FROM_BARNAUL:web.test.fail[Check HTTPS port 8081].min(#2)}>0
and
{<hostname>_FROM_BARNAUL:web.test.error[Check HTTPS port 8081].count(60)}>0
and
{<hostname>_FROM_BARNAUL:web.test.error[Check HTTPS port 8081].str(Timeout was reached,#2)}=1

Как видно из скриншота, интервал опроса составляет около 70 секунд. Поэтому для count() используем параметр "60 секунд": функция str() будет вычисляться только в том случае, если последнее значение для метрики web.test.error пришло не ранее чем минуту назад.