Сравнение двух текстовых элементов данн&

[a.filatov]

Добрый день!

Имею следующую ситуацию: есть 2 элемента данных. Оба имеют тип данных character.
Задача вроде бы элементарная - сравнить, совпадают ли их значения, если нет - зажечь триггер.

Проблема в том, что стандартные операторы сравнения не умеют работать со строками - выражение в духе {character_item_1.last()}<>{character_item_2.last( )} всегда вернёт FALSE. А стандартные функции работы со строками regexp и str умеют сравнивать только с константной строкой, выражение {character_item_1.str({character_item_2.last()})}= 0 zabbix не пропускает.

Собственно, есть ли у кого-нибудь мысли на этот счет?

PS: видел решение в виде {character_item_1.change()}<>{character_item_2.cha nge()}, но это все-таки немного не то. Например, смущает тот факт, что триггер потухнет сразу же после очередного обновления элемента данных.

[rough-84]

А данные это реально строка или число но в текстовом формате ?
Просто я таскал из логов числа, но не мог сделать триггер из за того что это был текстовый формат, в итоге я перегонял текст в число через calculated item.

[a.filatov]

Это, действительно, текст. Если быть точным, это состояние smf-сервиса (online, disabled, maintenance) solaris и его "ожидаемое" состояние. Получаю их с помощью autodiscovery-скрипта - первый итем - это реальное текущее состояние, второй - "ожидаемое", которое получаю на основе отдельного конфигурационного файла.

[yukra]

Решение в лоб: на стороне агента делать преобразования вида: "online => 1, disabled => 2, maintenance => 3", и сравнивать уже числа.

Для красоты можно в "Администрирование - Общее - Преобразование значений" забить таблицу обратных преобразований.

[Kos]

Если этих значений немного, то можно решить "в лоб" (хоть и некрасиво), просто перебрав все возможные значения.
Что-то вроде:

({character_item_1.str("online")}=1 & ({character_item_2.str("online")}=0)
|
({character_item_1.str("disabled")}=1 & ({character_item_2.str("disabled")}=0)
|
({character_item_1.str("maintenance")}=1 & ({character_item_2.str("maintenance")}=0)

[a.filatov]

Решение в лоб: на стороне агента делать преобразования вида: "online => 1, disabled => 2, maintenance => 3", и сравнивать уже числа.

Для красоты можно в "Администрирование - Общее - Преобразование значений" забить таблицу обратных преобразований.

Да, я в другом случае уже пробовал такое решение в лоб, после чего получил уведомления вроде "Статус сервиса nginx 3 отличается от 1". По всем возможным таким вариантам держать "таблицу преобразований" в голове будет очень сложно, поэтому зарекся делать так

А вот про "Администрирование - Общее - Преобразование значений" не знал, если честно, почитал документацию, действительно, именно то, что требуется, именно так и сделаю. Спасибо большое за наводку!

[Evgeniy]

Апну темку. Не могу сообразить как попроще составить триггер:
Есть шаблон с 5 элементами данных типа "текст", период опроса 5 мин. (опрашивается значение времени события, например "11.07.2016 10:10:10")
По шаблону опрашивается 6 устройств.
Необходимо сравнить полученные значения по каждому элементу данных между устройствами, и если отличается хоть одно из значений, то взвести триггер. В идеале еще прикрутить nodata(5m) по каждому из устройств.
На ум приходит только что-то типа:
(1.1.last(#2)=...=6.1last(#2)) & (1.1.last()=...=6.1.last() и т.д.)
|
(1.2.last(#2)=...=6.2last(#2)) & (1.2.last()=...=6.2.last() и т.д.) , т.е. сравнивать предпоследние и последние значения, чтобы не было ложных срабатываний... Но тут получается нужно инвертировать X=X=X=X=X=X, т.к. может быть X#X=X=X=X=X, и не соображу как...

Может кто подскажет какой-нибудь другой путь?

[Kos]

Перечитал ещё раз дискуссию.

Проблема в том, что стандартные операторы сравнения не умеют работать со строками - выражение в духе

{character_item_1.last()}<>{character_item_2.last( )}

всегда вернёт FALSE.

Ой, правда? А у меня, оказывается, именно такая конструкция используется (сравниваются даты в текстовом формате, вроде "2016-07-07", полученные из разных источников). И, вроде бы, успешно работает. Так правда нельзя было делать? Zabbix v2.2.13.

[Evgeniy]

Перечитал ещё раз дискуссию.Ой, правда? А у меня, оказывается, именно такая конструкция используется (сравниваются даты в текстовом формате, вроде "2016-07-07", полученные из разных источников). И, вроде бы, успешно работает. Так правда нельзя было делать? Zabbix v2.2.13.

А как, если не секрет? У меня тоже last и текстовые значения не катят, приходит преобразовывать в unixtime...
И еще вопрос, у Вас "источники" это разные узлы сети? Если да, то удалось как-нибудь привязать этот триггер к какому-то одному из этих узлов, т.е. чтобы при отличающихся значениях триггер срабатывал только по узлу сети №2?

[Kos]

А как, если не секрет? У меня тоже last и текстовые значения не катят, приходит преобразовывать в unixtime...
И еще вопрос, у Вас "источники" это разные узлы сети? Если да, то удалось как-нибудь привязать этот триггер к какому-то одному из этих узлов, т.е. чтобы при отличающихся значениях триггер срабатывал только по узлу сети №2?

По первому вопросу -- выражение триггера на первый взгляд, достаточно навороченное:

(({TRIGGER.VALUE}=0 and {EGARDB:db2[focus,db1].count(30)}>0 and {EGARDB:mssql[focus_lastdate,db2].count(30)}>0) or ({TRIGGER.VALUE}=1)) and ({EGARDB:db2[focus,db1].last()}<>{EGARDB:mssql[focus_lastdate,db2].last()} and {EGARDB:db2[focus,db1].prev()}<>{EGARDB:mssql[focus_lastdate,db2].prev()})

На самом деле не так уж сложно. Сравниваем значения (дата последней записи) из двух разных баз данных, между которыми данные должны отреплицироваться. Оба значения имеют тип "Character". Ругаемся в случае, когда последнее значение из одной базы отличается от последнего значения из другой базы и, одновременно с этим, предпоследние пары значений тоже отличаются (это два последних условия в триггере). Кроме того, поскольку триггер пересчитывается при приходе каждого нового значения из входящих в него, а регулировать момент опроса до Zabbix v3.0 невозможно (а синхронизировать их между собой и до сих пор нельзя), то для перехода триггера в состояние PROBLEM дополнительно проверяем, что каждое из входящих в триггер значений было получено недавно. Другими словами, чтобы при новом цикле опроса значение, пришедшее к нам первым, не сравнивалось со значением, которое в другой базе является последним на данный момент, но пришло к нам ещё в предыдущий цикл опроса.

По второму вопросу: данный триггер включает в себя элементы данных, которые относятся к одному узлу сети (хосту). В то же время, есть и триггеры, которые включают в себя элементы данных и разных хостов.
Например:

({DB2_Requestor:db2[MON-253,db2].last()}<>{INET:vfs.file.contents[C:\Lotus\Domino\quizrecordnumber.txt].last()}) and {DB2_Requestor:db2[MON-253,db2].nodata(60)}=0

(данные из базы данных - количество записей в таблице DB2 - сравнивается с количеством записей в лотусной базе, которое отдельным скриптом запихнуто в текстовый файл). Но здесь попроще, поскольку проверять надо раз в сутки, и моменты опроса каждого из источников разнесены (сначала берутся данные из текстового файла, через полчаса - из базы). Правда, тут оба значения имеют целочисленный тип.
А в чём проблема?

[Evgeniy]

Большое спасибо за ответ.
Когда я сравнивал текстовые значения функцией last, получал что-то типа : "Cannot evaluate function и т.д." С числовыми же значениями проблем не возникло... Сравнивал между разными хостами, на одном не пробовал, может дело в этом.
Кстати, логику в триггере использую такую же, только приходится сравнивать три последних значения (на двух иногда ложные срабатывания бывают). Но мыслю шаблонно, у меня выражение порядком длинней, не догадался общую часть вынести за скобки. Надо будет оптимизировать у себя, спасибо.
По второй части постараюсь объяснить. Есть хост-эталон (хост №1), триггеры сравнивают значения между ним и другими хостами (например, хостом №2). При возникновении проблемы значение на хосте №2 отличается, но вот событие почему-то возникает "Хост №1 : название триггера". Приходится выходить из ситуации используя макрос {HOST.NAME2} в названии триггера, чтобы хоть как-то понять на каком хосте проблема, но это жутко неудобно (особенно в настройке действий).

Время     Узел сети     Описание    
xx:xx:xx   Хост №1       Хост №2: Рассинхронизация

Кажется, что это связано со временем опроса значения с каждого из хостов, но почему-то я никогда не видел событий "Хост №2:название триггера" и что-то тут не вяжется...

[yukra]

По второй части постараюсь объяснить. Есть хост-эталон (хост №1), триггеры сравнивают значения между ним и другими хостами (например, хостом №2). При возникновении проблемы значение на хосте №2 отличается, но вот событие почему-то возникает "Хост №1 : название триггера". Приходится выходить из ситуации используя макрос {host.name2} в названии триггера, чтобы хоть как-то понять на каком хосте проблема, но это жутко неудобно (особенно в настройке действий).

Время     Узел сети     Описание    
xx:xx:xx   Хост №1       Хост №2: Рассинхронизация

Кажется, что это связано со временем опроса значения с каждого из хостов, но почему-то я никогда не видел событий "Хост №2:название триггера" и что-то тут не вяжется...

Попробуйте поменять местами хосты в триггере

[Evgeniy]

Попробуйте поменять местами хосты в триггере

Это было самое первое, что я сделал, но увы...

UPD:
1) Для наглядности создал два триггера:
Test alarm1 -- {Test 1:item1.last()} # {Test 2:item1.last()}
Test alarm2 -- {Test 2:item1.last()} # {Test 1:item1.last()}
Вот что получилось:
Вкладка "События"- savepic.ru/10853474.jpg
Вкладка "Триггеры" - savepic.ru/10859621.jpg
2) По поводу сравнения текстовых значений, видимо все-таки дело в версиях (2.2.7)
savepic.ru/10814549.jpg
savepic.ru/10848343.jpg

[Evgeniy]

Методом "научного тыка" выяснил, что аварийное событие выскакивает по тому хосту, который был создан раньше. Тут получается два варианта, либо пересоздавать эталонный хост, либо править в базе...

[Kos]

2) По поводу сравнения текстовых значений, видимо все-таки дело в версиях (2.2.7)
savepic.ru/10814549.jpg
savepic.ru/10848343.jpg

Ну, не знаю. Мы у себя стараемся сервер обновлять своевременно, последняя версия была 2.2.13 (недавно обновились на 3.0.4). Но, мне кажется, что и в версии 2.2.7 у нас это работало.
В любом случае, обновления в рамках одной мажорной версии (например, 2.2.7 -> 2.2.14) проходят достаточно безболезненно: остановить сервер, подменить бинарники и файлы веб-интерфейса, запустить сервер. Делов на пару минут.

Методом "научного тыка" выяснил, что аварийное событие выскакивает по тому хосту, который был создан раньше.

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