Последнее значение итема в триггере

[Sunrise_94]

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

Подскажите пожалуйста, хотел бы чтоб имя кулера отображалось в имени триггера, как вставить последнее значение итема?
Версия zabbix 7.0

[Kos]

Почитать про настройку триггера в документации по версии 6.0 (в 7.0 в этом отношении ничего принципиально не изменилось, просто ещё не дошла очередь корректно перевести эту часть). Особое внимание уделить разнице между понятиями "Имя" триггера и "Оперативные данные", а также использованию системных макросов {ITEM.VALUE} и {ITEM.LASTVALUE}.

[Sunrise_94]

Прочитал, но из-за небольшого опыта в написании триггеров возникают трудности
Почему-то, zabbix не распознает макросы {ITEM.VALUE} и {ITEM.LASTVALUE}.

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

Уж извините, я только учусь))

[Diesel315]

Значение элемента в имя это в вашем случае SNMPINDEX надо указывать.
{ITEM.VALUE} и {ITEM.LASTVALUE} вставляются как правило в Оперативные данные, и нужно как правило для вывода значений. Например скорости вращения вентиляторов, напряжение на входе и тд и тп

[Sunrise_94]

Значение элемента в имя это в вашем случае SNMPINDEX надо указывать.
{ITEM.VALUE} и {ITEM.LASTVALUE} вставляются как правило в Оперативные данные, и нужно как правило для вывода значений. Например скорости вращения вентиляторов, напряжение на входе и тд и тп

Если выставить {#SNMPINDEX}, то в имени будет отображаться индекс элемента, а я бы хотел сделать так, чтоб отображалось имя.
Приведу пример: есть кулер с именем FRNT_FAN1, это значение выдается с соответствующего элемента по запросу. Мне надо создать триггер, который будет срабатывать когда кулер будет вообще недоступен, и в имени сделать так, чтоб отображалось имя кулера, а не индекс. Пример: Кулер [FRNT_FAN1] недоступен. Элемент который выдает в результате запроса имя кулера, элемент который определяет доступен кулер или нет - это два разных элемента

[Kos]

Вот именно. В данном случае то, что вы хотите добавить в имя триггера, не является значением того элемента данных, который используется в этом триггере. Это значение совершенно другого элемента данных, поэтому моя первая рекомендация (использовать макросы {ITEM.VALUE} и {ITEM.LASTVALUE}) тут не подойдёт. Я, кстати говорил о системных макросах {ITEM.VALUE} и {ITEM.LASTVALUE}, а не о несуществующем LLD-макросе {#ITEM.VALUE}, который вы пытались использовать.

Однако, судя по использованию LLD-макроса {#SNMPINDEX}, вы нам показываете не триггер, а прототип триггера из правила низкоуровневго обнаружения (LLD).
Вы нам ничего не говорили о том, что в данном случае используется LLD. Вероятнее всего, в самом правиле LLD опрашивается по SNMP таблица (или несколько таблиц), содержащих какие-то параметры, относящиеся к вашим кулерам. Логичнее всего было бы добавить прямо в это же правило ещё и таблицу, содержащую имена ваших кулеров (если её там ещё нет). Тогда правило LLD на выходе генерировало бы, в том числе, LLD-макросы, содержащие эти имена - и вы могли бы использовать их непосредственно в прототипах триггеров (вместо несуществующих {#ITEM.VALUE}). Примеры того, как эта техника работает, можно на примере сетевых интерфейсов посмотреть здесь.

[Diesel315]

Я кажется понял более точно вашу задачу.
Я у себя её решил так. С помощью LLD собираю данные и "создаю" пользовательские макросы. Например по FAN:
discovery[{#SNMPVALUE},1.3.6.1.4.1.2.3.51.3.1.3.2.1.1,{#FAN_ LOCATION},1.3.6.1.4.1.2.3.51.3.1.3.2.1.2,{#FAN_SPE ED},1.3.6.1.4.1.2.3.51.3.1.3.2.1.3]

Далее на основе этого сбора данных создаются элементы данных (прототипы). Как пример:
Fan #{#SNMPINDEX} {#FAN_LOCATION}: Fan status
И триггер (прототип) соответствующий:
{HOST.HOST} - Fan #{#SNMPINDEX} {#FAN_LOCATION}: Health Status is not 'Normal' state!

В итоге на хосте это выглядит уже так (элемент данных):
Fan #1 Fan 1A Tach: Fan status
Ну и триггер:
{HOST.HOST} - Fan #1 Fan 1A Tach: Health Status is not 'Normal' state!

[Sunrise_94]

Вот именно. В данном случае то, что вы хотите добавить в имя триггера, не является значением того элемента данных, который используется в этом триггере. Это значение совершенно другого элемента данных, поэтому моя первая рекомендация (использовать макросы {ITEM.VALUE} и {ITEM.LASTVALUE}) тут не подойдёт. Я, кстати говорил о системных макросах {ITEM.VALUE} и {ITEM.LASTVALUE}, а не о несуществующем LLD-макросе {#ITEM.VALUE}, который вы пытались использовать.

Однако, судя по использованию LLD-макроса {#SNMPINDEX}, вы нам показываете не триггер, а прототип триггера из правила низкоуровневго обнаружения (LLD).
Вы нам ничего не говорили о том, что в данном случае используется LLD. Вероятнее всего, в самом правиле LLD опрашивается по SNMP таблица (или несколько таблиц), содержащих какие-то параметры, относящиеся к вашим кулерам. Логичнее всего было бы добавить прямо в это же правило ещё и таблицу, содержащую имена ваших кулеров (если её там ещё нет). Тогда правило LLD на выходе генерировало бы, в том числе, LLD-макросы, содержащие эти имена - и вы могли бы использовать их непосредственно в прототипах триггеров (вместо несуществующих {#ITEM.VALUE}). Примеры того, как эта техника работает, можно на примере сетевых интерфейсов посмотреть здесь.

Спасибо вам огромное за помощь и наводку, у меня все получилось)

Прочитал пример в статье, и на её примере создал свой триггер. В правиле обнаружения добавил макрос {#IFNAME} и нужный OID, затем этот макрос вставил в имя триггера, по итогу триггер отображает нужную информацию.

Я еще не до конца выучил всю механику, но я на верном пути)

[Sunrise_94]

Я кажется понял более точно вашу задачу.
Я у себя её решил так. С помощью LLD собираю данные и "создаю" пользовательские макросы. Например по FAN:
discovery[{#SNMPVALUE},1.3.6.1.4.1.2.3.51.3.1.3.2.1.1,{#FAN_ LOCATION},1.3.6.1.4.1.2.3.51.3.1.3.2.1.2,{#FAN_SPE ED},1.3.6.1.4.1.2.3.51.3.1.3.2.1.3]

Далее на основе этого сбора данных создаются элементы данных (прототипы). Как пример:
Fan #{#SNMPINDEX} {#FAN_LOCATION}: Fan status
И триггер (прототип) соответствующий:
{HOST.HOST} - Fan #{#SNMPINDEX} {#FAN_LOCATION}: Health Status is not 'Normal' state!

В итоге на хосте это выглядит уже так (элемент данных):
Fan #1 Fan 1A Tach: Fan status
Ну и триггер:
{HOST.HOST} - Fan #1 Fan 1A Tach: Health Status is not 'Normal' state!

Да, все верно