Создать триггер для узла сети на основе (Item) элемента данных другого хоста

[Proz01]

Добрый день!
Есть сервер A с работающим агентом. В файле конфигурации прописан

UserParameter=sqlTECH,powershell -NoProfile -ExecutionPolicy Bypass -File C:\zabbix\scripts\MSSQL.ps1

Который запускает скрипт powershell для проверки базы данных на сервере В. В зависимости от состояния выдает 0 или 1.
На сервере Zabbix создаю узел сети сервер В, но не могу прикрутить к нему триггер на основе элемента данных сервера А.

Можно ли создавать триггеры на основе элементов данных другого сервера? Либо нужно создать сначала элемент данных на основе элемента данных сервера А, и на его основе создать триггер?

[Kos]

Тут можно идти двумя путями.

1) Отвечая на непосредственно заданный вопрос: да, в одном триггере можно сослаться на элементы данных от нескольких хостов одновременно; при этом триггер будет виден в конфигурации каждого из этих хостов, а генерируемое событие будет, вероятно, относиться к тому хосту, чей элемент данных в условиях триггера был перечислен первым. Т.е. на хосте "serverB" можно сделать триггер, который будет выглядеть примерно так:

{ServerB:system.uptime.last()}>0 and {ServerA:sqlTECH.last()}=0

Первое условие в данном примере - фикция, т.к. оно будет выполняться всегда; но оно обеспечит привязку события к нужному хосту.
Недостаток: в оповещениях придётся использовать макрос {ITEM.VALUE2}, а не {ITEM.VALUE1}, да и выглядит это несколько громоздко.

2) Я бы делал проще. Указал бы для хоста ServerB в качестве IP-адреса агента (возможно, второго, если первый уже используется) адрес сервера ServerA. И прямо на хосте ServerB создавал бы нужный элемент данных, указывая тип: "Zabbix agent" (пассивный режим) и выбирая для него IP-адрес сервера ServerA. Всё.

[Proz01]

Спасибо большое за оперативный ответ!
1) Действительно реализация первого варианта несколько громоздка, но она более универсальна, позволяет добавлять проверки не только с сервера A, но и непосредственно с Zabbix сервера. Например ping.
Единственный недостаток или фича в данной реализации это при срабатывании триггера появление двух узлов на дашборде. Приложил скриншот.

2) Второй вариант идеально подходит, но в нем как раз нет этой универсальности описанной в первом варианте.

Пошел по первому пути. Еще раз большое спасибо!

[Kos]

она более универсальна, позволяет добавлять проверки не только с сервера A, но и непосредственно с Zabbix сервера. Например ping.

Ну так ping и так делается с сервера Zabbix, а привязывается к нужному хосту, если настраивать проверку как simple check. Не вижу необходимости в данном случае вообще упоминать другой хост в триггерах.

[Proz01]

Item Ping здесь только для примера, так как его было просто клонировать. Я в zabbix новичок поэтому не понял пока как построить вами предложенный триггер.
{ServerB:system.uptime.last()}>0

[Kos]

Item Ping здесь только для примера, так как его было просто клонировать.

Ну, я стараюсь придерживаться принципов бритвы Оккама: не делать лишних сущностей без необходимости.
Если есть возможность обойтись без указания в триггере ссылок на данные с разных хостов, то лучше так и делать.
А ping, сделанный через simple check, клонируется ровно так же :-)

Я в zabbix новичок поэтому не понял пока как построить вами предложенный триггер.
{ServerB:system.uptime.last()}>0

Очевидно, нужно сначала на хосте ServerB создать элемент данных system.uptime, если его там ещё нет. Тогда на него можно будет ссылаться в триггере.