Зависимости триггеров между шаблонами

[Gleb]

Добрый день!

Мониторю некоторые параметры конечных устройств (пусть - компьютеры), в том числе их доступность с помощью icmpping.
Каждый компьютер за своим коммутатором: отвалиться может как компьютер отдельно, так и коммутатор и компьютер.
Шаблоны (templates) компьютеров и коммутаторов не имеют связи (link) между собой, а схожие item для проверок icmpping есть у обоих.

При попытке указать в триггере недоступности по icmp шаблона компьютеров зависимость от триггера недоступности по icmp шаблона коммутаторов получаю

Cannot add dependency from a host to a template

Помогите внести ясность в вопрос зависимостей триггеров между разными устройствами

Zabbix 2.4.6

[Vandoyn]

Да, через интерфейс не получается создать зависимость между узлами,
но такую зависимость почему то можно создать через API.

Zabbix 2.2.1

[aib]

Вообще-то, создать зависимости "Шаблонных элементов" от элементов из другого шаблона невозможно.

Увы.

[Vandoyn]

Через api можно создать зависимости между шаблонными тригерами разных узлов.

[aib]

Через api можно создать зависимости между шаблонными тригерами разных узлов.

Это здорово.
Но вот как "это" будет работать в случае, если к хосту будет прикреплен только один шаблон, а не оба, имеющие зависимости?

[DRVTiny]

Как это сделать правильно:

1) Добавляете в шаблон хоста icmpping до шлюза, причём шлюз указываете пользовательским макросом {$GATEWAY_IP}. Хинт: icmpping - это простая проверка, она осуществляется с сервера и по сути никакого отношения к хосту не имеет, кроме того, что если не указать в icmpping IP хоста, то по дефолту будет пинговаться тот хост, к которому прицеплен итем.

2) Прописываете на самом хосте в настройках хоста значение макроса {$GATEWAY_IP}

3) Теперь вы можете использовать метрику доступности шлюза для построения каких угодно триггеров, не выходя за рамки хоста.

Положительные стороны такого решения:
- По значению {$GATEWAY_IP} вы можете легко определить, какой шлюз у данного узла и поменять это значение при необходимости
- Вы можете свободно использовать метрику доступности шлюза хоть в триггерах, хоть в прототипах триггеров

Отрицательные стороны:
- Шлюз будет пинговаться без всякой на то разумной необходимости (для каждого хоста за шлюзом)
- Если шлюз выйдет из строя, то это всё равно будет выглядеть как падение всех хостов: для каждого хоста будет сгенерировано своё сообщение "Аааа, я знаю, что шлюз недоступен!!"