Ложные срабатывания триггера. Неверное использование .last() ?

[uscr]

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

{catalog_version[local,version].last(,86400)}={catalog_version[local,version].last()} and {catalog_timestamp.delta(86400)}>86000

Здесь я пытался записать следующий алгоритм:
Если версия "боевого" каталога совпадает с той, что была сутки назад (каталог в бою не обновился) и при этом, в БД таймстемп новой версии больше того, что был сутки назад (в БД каталог обновился), то у нас проблемы.

Однако, такой триггер переходит в состояние аварии, хотя последнее обновление в БД было 4 дня назад, ровно тогда же обновился и каталог. Третий день смотрю в выражение триггера и не могу ничего придумать. Что я упустил?

[kernbug]

Здравствуйте,

Если версия "боевого" каталога совпадает с той, что была сутки назад (каталог в бою не обновился)

хотя последнее обновление в БД было 4 дня назад,

Что-то не понял, что вложено в понятие "должен своевременно обновляться", в одном месте у Вас требование 1 день, в другом за 4 дня. Уточните, пожалуйста!

[uscr]

Что-то не понял, что вложено в понятие "должен своевременно обновляться", в одном месте у Вас требование 1 день, в другом за 4 дня. Уточните, пожалуйста!

Здравствуйте.
Возможно, немного сумбурно описал проблему в первом посте. Попробую ещё раз.

Для ясности, каталог, который является результатом выгрузки из БД я буду называть "каталог на диске", а в БД, соответственно, "каталог в БД".

Каталог в БД может не обновляться сколько угодно долго. Но как только он обновится, каталог на диске тоже должен быть обновлён. При этом, между обновлением каталога в БД и обновлением каталога на диске может пройти 24 часа и это не фатально.

В триггере я пытаюсь отловить как раз ситуацию, когда в БД каталог обновлён менее, чем сутки назад, а на диске уже больше суток обновлений нет.

При этом триггер, который я привёл выше, даёт ложное срабатывание. Он сработал, но при ручной проверке я вижу, что в БД каталог обновился более 4 суток назад (таймстэм 1530700621). На диске, соответственно, тоже обновился своевременно (более четырёх суток назад, версия всё это время 4231).

Как я понимаю, выражения триггера принимают следующие значения:

 
 {catalog_version[local,version].last(,86400)}={catalog_version[local,version].last()} = TRUE

(поскольку уже пятые сутки catalog_version[local,version] = 4231)

{catalog_timestamp.delta(86400)}>86000 = FALSE

(поскольку уже пятые сутки тамстэмп тут неизменен: 1530700621)

TRUE and FALSE = FALSE

Однако, поскольку триггер срабатывает, я думаю что неверно указал какие-то параметры в функции триггера и в упор не могу этого увидеть. Потому и пришёл на форум.

[kernbug]

Покажите Latest Data списком за сутки для элемента catalog_timestamp.

[uscr]

Покажите Latest Data списком за сутки для элемента catalog_timestamp.

Вот:

09.07.2018 12:42:41    1530859399
09.07.2018 12:12:41    1530859399
09.07.2018 11:42:41    1530859399
09.07.2018 11:12:41    1530859399
09.07.2018 10:42:41    1530859399
09.07.2018 10:12:41    1530859399
09.07.2018 09:42:41    1530859399
09.07.2018 09:12:41    1530859399
09.07.2018 08:42:41    1530859399
09.07.2018 08:12:41    1530859399
09.07.2018 07:42:41    1530859399
09.07.2018 07:12:41    1530859399
09.07.2018 06:42:41    1530859399
09.07.2018 06:12:41    1530859399
09.07.2018 05:42:41    1530859399
09.07.2018 05:12:41    1530859399
09.07.2018 04:42:41    1530859399
09.07.2018 04:12:41    1530859399
09.07.2018 03:42:41    1530859399
09.07.2018 03:12:41    1530859399
09.07.2018 02:42:41    1530859399
09.07.2018 02:12:41    1530859399
09.07.2018 01:42:41    1530859399
09.07.2018 01:12:41    1530859399
09.07.2018 00:42:41    1530859399
09.07.2018 00:12:41    1530859399
08.07.2018 23:42:41    1530859399
08.07.2018 23:12:41    1530859399
08.07.2018 22:42:41    1530859399
08.07.2018 22:12:41    1530859399
08.07.2018 21:42:41    1530859399
08.07.2018 21:12:41    1530859399
08.07.2018 20:42:41    1530859399
08.07.2018 20:12:41    1530859399
08.07.2018 19:42:41    1530859399
08.07.2018 19:12:41    1530859399
08.07.2018 18:42:41    1530859399
08.07.2018 18:12:41    1530859399
08.07.2018 17:42:41    1530859399
08.07.2018 17:12:41    1530859399
08.07.2018 16:42:41    1530859399
08.07.2018 16:12:41    1530859399
08.07.2018 15:42:41    1530859399
08.07.2018 15:12:41    1530859399
08.07.2018 14:42:41    1530859399
08.07.2018 14:12:41    1530859399
08.07.2018 13:42:41    1530859399
08.07.2018 13:12:41    1530859399

[uscr]

Дело раскрыто. При удалении шаблона я нажал "отсоединить", вместо "отсоединить и очистить". На хостах остались старые триггеры, которые проверку даты в БД не проводили, зажигали триггер только по неизменности версии каталога на диске. Так что срабатывали старые триггеры, а выражение вверху рабочее. Прошу прощения за потраченное впустую время.