Не всегда отрабатывают {item.value2}, {item.value3} и пр.

[pzabortsev]

После обновления с 2.0.10 до 2.0.11 перестали отрабатывать макросы {ITEM.VALUE2}, {ITEM.VALUE3} в названиях триггеров.

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

Требуется установка {ITEM.VALUE1} обновлений системы: {ITEM.VALUE2}/{ITEM.VALUE3}

и выражение:

{Template OS Linux:system_updates[total].last(0)}>0 | {Template OS Linux:system_updates[security].last(0)}>0 | {Template OS Linux:system_updates[optional].last(0)}>0

Все три элемента - это трапперы, в которые данные записываются одним скриптом с помощью zabbix_sender, запускаемым на сервере.

На версии 2.0.10 все три макроса отрабатывали корректно и приходили вот такие оповещения:
mx02: PROBLEM: Требуется установка 6 обновлений системы: 4/2

после обновления на 2.0.11 {ITEM.VALUE1} отрабатывает, остальные - через раз. Вот примеры оповещений, полученных, например, сегодня:
gtw02: PROBLEM: Требуется установка 6 обновлений системы: *UNKNOWN*/0
mx02: PROBLEM: Требуется установка 6 обновлений системы: *UNKNOWN*/*UNKNOWN*

Данные все на месте, приходят одновременно, в одну и ту же секунду.

Можно как-то исправить ситуацию?

[Jimson]

Возможно у вас триггер срабатывает по "total" раньше чем данные по "security" заносятся в trends. На самом деле событие не имеет своего имени, имя есть только у триггера и оно статично, то что вы задали в конфигурации, а вот при визуализации (web/actions) раскрываются макросы и подставляются значения и, на сколько я помню, эти данные берутся всегда только из trends. Как следствие, если trends почистить, то вы у всех эвентов и активных триггеров увидите эти *UNKNOWN*.
Если я угадал, то надо репортить проблему, для интерфейса не страшно, а с actions не хорошо вышло.

P.S. в вашем случае дополнительные условия фейковые, попробуйте переписать через &, например
{Template OS Linux:system_updates[security].last(0)}#10000 & {Template OS Linux:system_updates[optional].last(0)}#10000

[pzabortsev]

В trends эти данные есть (в trends_uint).
Вы хотите сказать, что при визуализации в веб-интерфейсе при вызове, скажем, dashboard'а все подобные данные в названии триггера подтягиваются из trends? Тогда тут однозначно какая-то бага, т.к. данные присутствуют, а в веб-нитерфейсе написано
Требуется установка 6 обновлений системы: 0/0
т.е. подставлены нули (откуда они взялись - непонятно).

PS. Эти условия намеренно сделаны фейковыми, чтобы подтянуть данные в название триггера. Предложенные Вами условия точно такие же фейковые, разве не так? Не почувствовал принципиальной разницы...

[Jimson]

В trends эти данные есть (в trends_uint).
Вы хотите сказать, что при визуализации в веб-интерфейсе при вызове, скажем, dashboard'а все подобные данные в названии триггера подтягиваются из trends?

да, но значения берутся за то время когда произошло событие

ps. Эти условия намеренно сделаны фейковыми, чтобы подтянуть данные в название триггера. Предложенные Вами условия точно такие же фейковые, разве не так? Не почувствовал принципиальной разницы...

разница в том что в случае & для вычисления значения триггера нужно проанализировать все три элемента данных, а в вашем случае достаточно только одного
возможно это и не важно, зависит от алгоритма реализующего вычисление выражений

[pzabortsev]

Спасибо, так и сделаю!

Посмотрю дальше, будут появляться подобные проблемы или нет.

[pzabortsev]

К сожалени, ошибка сохраняется.
Описал триггеры, как советовал Jimson:

{mx01:system_updates[total].last(0)}>0 & {mx01:system_updates[security].last(0)}#10000 & {mx01:system_updates[optional].last(0)}#10000

Все-равно вижу текст сообщения триггера неверный:
Требуется установка 2 обновлений системы: 0/0

Причем на части хостов оно выглядит так:
mx01: PROBLEM: Требуется установка 2 обновлений системы: 0/0

А на других - так:
gtw01: PROBLEM: Требуется установка 1 обновлений системы: *UNKNOWN*/*UNKNOWN*

Видимо бага закралась в версию 2.0.11. Попробую создать тикет

[pzabortsev]

Завел багу: https://support.zabbix.com/browse/ZBX-7878

[pzabortsev]

Пока откатился на zabbix_server 2.0.10.

С ним все работает.

[pzabortsev]

Вчера обновил сервер до версии 2.0.12, и проблема снова вернулась:
Требуется установка 5 обновлений системы: 0/0
Напомню, как выглядит выражение триггера:

{HOST:system_updates[total].last(0)}>0 & {HOST:system_updates[security].last(0)}#10000 & {HOST:system_updates[optional].last(0)}#10000

Вот так выглядит имя триггера:

Требуется установка {ITEM.VALUE1} обновлений системы: {ITEM.VALUE2}/{ITEM.VALUE3}

Реальные значения:
HOST.system_updates[total].last(0) = 5
HOST.system_updates[security].last(0) = 5
HOST.system_updates[optional].last(0) = 0

В данном случае {ITEM.VALUE2} отработал неверно.

[pzabortsev]

Понаблюдав за работой версии 2.0.12, мне кажется, я понял причину ошибки.
В версии 2.0.10 zabbix server генерил триггер только после поступления всех элементов, включенных в выражение (не совсем понимаю, как это получалось у него, но это факт).
Видимо в версиях после 2.0.10 решили исправить эту ошибку (), и теперь триггер генерится сразу после получения первого из значений. При чем первым может попасть в обработку любое из трех значений. Поэтому и имя триггера получется различное:
Требуется установка 0 обновлений системы: 6/0
Требуется установка 0 обновлений системы: 0/1
Требуется установка 10 обновлений системы: 0/0
и даже такое:
Требуется установка 0 обновлений системы: *UNKNOWN*/3

Кто-нибудь кроме меня использует макросы {ITEM.VALUE2}, {ITEM.VALUE3} и т.д. в названиях триггеров? Наблюдаются подобные проблемы или нет? Может дело в типа элементов?

[pzabortsev]

Дополнение:
На вкладке Триггеры имя триггера выглядит как надо, т.е. без ошибки.

Таким образом, ошибочное имя триггера возникает на ПАНЕЛИ и в оповещениях, приходящих по почте.

[pzabortsev]

Я так понимаю, в версии 2.0 уже не будут исправляться ошибки... Жаль.

Так и придется жить на 2.0.10.

[pzabortsev]

Немножко поныл (см. выше), полез в отладчик, поковырялся в php-скриптах и обнаружил чудесный факт: если все мои ITEM.VALUE заменить на ITEM.LASTVAULE, то все названия триггеров отображаются корректно!
Видимо это не совсем корректно, т.к. если с момента возникновения события/ошибки данные, на основе которых строится название триггера, изменятся, то получится путаница. Но в качестве workaround для моей ситуации этот вариант подойдет - проверка наличия обновлений происходит раз в сутки, и большой разница между VALUE и LASTVALUE мы не увидим.

[pzabortsev]

Видимо ошибка в обработке поля ns в таблице history_uint.
Вот один пример:

mysql> SELECT DISTINCT f.triggerid,f.functionid,i.itemid,i.lastvalue,i.lastclock,i.value_type,i.units,i.valuemapid,m.mappingid,m.newvalue FROM functions f INNER JOIN items i ON f.itemid=i.itemid INNER JOIN hosts h ON i.hostid=h.hostid LEFT JOIN mappings m ON i.valuemapid=m.valuemapid AND i.lastvalue=m.value WHERE f.functionid IN ('20475','20476','20477') order by i.itemid;
+-----------+------------+--------+-----------+------------+------------+-------+------------+-----------+----------+
| triggerid | functionid | itemid | lastvalue | lastclock  | value_type | units | valuemapid | mappingid | newvalue |
+-----------+------------+--------+-----------+------------+------------+-------+------------+-----------+----------+
|     19073 |      20476 |  38600 | 1         | 1409202042 |          3 |       |       NULL |      NULL | NULL     |
|     19073 |      20477 |  38601 | 0         | 1409202042 |          3 |       |       NULL |      NULL | NULL     |
|     19073 |      20475 |  38603 | 1         | 1409202042 |          3 |       |       NULL |      NULL | NULL     |
+-----------+------------+--------+-----------+------------+------------+-------+------------+-----------+----------+
3 rows in set (0.00 sec)

mysql> SELECT itemid,value,ns FROM history_uint WHERE itemid in ('38603','38600','38601') AND clock='1409202042';
+--------+-------+-----------+
| itemid | value | ns        |
+--------+-------+-----------+
|  38600 |     1 | 105456357 |
|  38601 |     0 | 109697456 |
|  38603 |     1 | 108967015 |
+--------+-------+-----------+
3 rows in set (0.00 sec)

mysql>

Это данные для раскрытия макросов ITEM.VALUE1, ITEM.VALUE2 и ITEM.VALUE3 в названии триггера.

Как видно, все три значания пришли в одно и то же время (clock у всех один и тот же - 1409202042). А вот поле ns у всех разное (это нормально).

Однако при отображении применяется некоторая странная хитрость: выбираются только те данные, у которых не только поле clock равно 1409202042, но и поле ns равно 105456357. Видимо это значение получается из того времени, когда приходит первое значение из моей тройки данных, которое генерит событие.

А дальше происходит совсем уж плохо: не найдя значений двух других данных с полем ns=105456357, отображалка ищет те же данные, но с полем ns<105456357. Конечно она ничего не находит, т.к. в моем случае у двух других данных значение ns больше 105456357, т.е. они были обработаны на мгновение позже. Тогда отображалка тупо берет предыдущие данные (в моем случае это данные за прошлый день).

Видимо как-то подобным образом происходит и генерация уведомлений, отправляемых по почте.

Немного сумбурно, но надеюсь суть можно уловить ))

Пока не знаю, что с этим делать. Буду еще думать...

PS. Не понятно, почему до выхода версии 2.0.11 все работало как часы. Отображалка никак не поменялась. Видимо сервер версии 2.0.10 и раньше как-то подругому обрабатывал триггеры и генерил события....