Зависимости триггеров от шлюза

[DeV1L]

Добрый день!
Необходимо настроить мониторинг удалённых площадок так, тобы триггеры хостов каждой площадки зависили доступности шлюза на этой площадке?
Можно ли это реализовать, не делая отдельные шаблоны для каждой площадки?

[yukra]

Добрый день!
Необходимо настроить мониторинг удалённых площадок так, тобы триггеры хостов каждой площадки зависили доступности шлюза на этой площадке?
Можно ли это реализовать, не делая отдельные шаблоны для каждой площадки?

В именах выражении триггеров можно использовать пользовательские макросы, поэтому можно попробовать закостыли (я не проверял что это будет работать) триггер типа: "{Template ICMP Ping:icmpping.max(#3)}=0 AND {{$IP_GATE}:icmpping.min(#3)}=1". При этом макрос {$IP_GATE} видимо придется прописывать на каждый хост отдельно (можно через апи, например в зависимости от группы).

Зы у себя я использую такую схему: на удаленных площадках стоит прокси, и все хосты на площадки мониторяться через нее. Сама хост с проксей тоже мониториться через эту же прокси (иначе не работают внутренние проверки zabbix[]) и отдельно заведем хост с адресом прокси, но мониторищайся без указания прокси.

Соответственно если связь падает, то триггер появляется только о том, что прокси недоступен (ну и если статистику используете, то она может поехать, ведь потом связь починят, данные на сервер доедут и получится что прокси 2 часа в день не работала, а сервер за ней (с точки зрения прокси) работал отлично).

[DeV1L]

С макросом идея хорошая, попробую. В принципе, можно просто добавлять его при заведении сервера в Zabbix.

Про прокси не совсем понял. Если хосты за прокси и канал упадёт, то Zabbix это отработает даже без настроенных зависимостей?
Меня интересуют только проверки доступности, типа: ICMP, TCP, Agent ping. Сейчас при падении канала они для каждого хоста срабатывают.

[Semiadmin]

Про прокси не совсем понял. Если хосты за прокси и канал упадёт, то Zabbix это отработает даже без настроенных зависимостей?

Триггеры просто не сработают, т.к. опрос будет вестись с прокси, который сам находится за шлюзом, и с него хосты доступны. Когда связь восстановится, собранные прокси данные сольются на сервер заббикса, если разрыв связи не больше заданного в конфиге прокси времени хранения данных.
В принципе, в вашем случае можно не использовать предложенную yukra схему с 2 хостами для прокси, достаточно мониторить с заббикс-сервера доступность шлюза. Хотя я тоже использую эту схему, она позволяет настроить автоматический перезапуск демона zabbix-proxy в случае, если напрямую данные идут, а через него - нет.

[yukra]

Триггеры просто не сработают, т.к. опрос будет вестись с прокси, который сам находится за шлюзом, и с него хосты доступны. Когда связь восстановится, собранные прокси данные сольются на сервер заббикса, если разрыв связи не больше заданного в конфиге прокси времени хранения данных.
В принципе, в вашем случае можно не использовать предложенную yukra схему с 2 хостами для прокси, достаточно мониторить с заббикс-сервера доступность шлюза. Хотя я тоже использую эту схему, она позволяет настроить автоматический перезапуск демона zabbix-proxy в случае, если напрямую данные идут, а через него - нет.

Ага, именно это я и имел в виду. Главное не делать триггеров с nodata