2й ip узла и зависимые тригеры

[kharkov_max]

Добрый день.

Давно использую zabbix у себя в локальной сети предприятия.
Лет 5 назад сам писал шаблоны для мониторинга управляемых свичей HP и разной другой лабуды...

Вот пришлось окунуться в тонкости настроек, не понятно несколько вопросов:

1. У узла можно прописать 2 IP мониторинга к примеру по SNMP, при этом один из IP является основным.
Значит ли это что при отсутствии данных по default IP, zabbix начнет снимать данные по 2му IP узла?
Собственно в каких целях можно использовать 2й IP и зачем он нужен?
Если возможно разъясните на каких то логических примерах....

2. Пришлось настраивать зависимые тригеры.
Много узлов находится за роутером в интренет с белыми IP.
Схема выхода заббих в интернет следующая.
Zabbix-Server -> Mikrotik (роутер) -> Передающая антена -> Принимающая антена -> (Шлюз провайдера, интернет) -> (куча узлов с белыми IP)

Как пробовал:
Cхема 1
Есть шаблон пинга хостов, в шаблон добавлены все узлы кроме Zabbix-Server
В Zabbix-Server настроил элемент данных пинг на 8.8.8.8 и 8.8.4.4 и создал тригер "Доступность Интернет" (если не доступен пинг на 8.8.8.8 и 8.8.4.4 то считать что интернета нет)

Сделал зависимым от тригера "Доступность Интернет" все тригеры узлов в интернете (тригеры пинга из шаблона).
Тригер "Доступность Интернет" сделал зависимым от тригера доступности узла "Принимающая антена"
Тригер узла "Принимающая антена" сделал зависимым от тригера доступности узла "Передающая антена"
Тригер узла "Передающая антена" сделал зависимым от тригера доступности узла "Mikrotik"

Выдергиваю кабель из узла "Микротик" и получаю срабатывание тригера "Доступность Интернет" и тригера доступности узла "Mikrotik".
Почему? Где логическая ошибка?
По идее должен сработать только тригер доступности узла "Микротик" ...

Схема 2
Есть шаблон пинга хостов, в шаблон добавлены все узлы кроме Zabbix-Server
Создал новый узел "Доступность интернет" с IP 8.8.8.8 и добавил его в шаблон пинга.

Сделал зависимым от тригера "Доступность Интернет" все тригеры узлов в интернете (тригеры пинга из шаблона).
Тригер "Доступность Интернет" сделал зависимым от тригера доступности узла "Принимающая антена"
Тригер узла "Принимающая антена" сделал зависимым от тригера доступности узла "Передающая антена"
Тригер узла "Передающая антена" сделал зависимым от тригера доступности узла "Mikrotik"

При выдергивании кабеля из узла "Микротик" срабатывают несколько тригеров узлов в интернет, и через приличную задержку срабатывает тригер доступности узла "Микротик" ...
Почему так ?
Может нужно какие то правильные таймауты пинга сделать или еще какие то настройки ...

Ну и собственно как правильно мониторить при моей схеме выход Zabbix-Server в интернет, может я иду не верным путем и есть другие решения.

Схему 2 пробовал потому что в мане нашел следующее

Зависимость триггера может быть добавлена от любого триггера узла сети к триггеру любого другого узла сети, пока это не приведет к циклической зависимости.
Зависимость триггера может быть добавлена от шаблона к шаблону. Если триггер из шаблона А зависит от триггера из шаблона B, то шаблон A может быть соединен с узлом сети (или с другим шаблоном) только вместе с шаблоном B, но шаблон B может быть соединен с узлом сети (или с другим шаблоном) в одиночку.
Зависимость триггера может быть добавлена от шаблонного триггера к триггеру узла сети. В этом случае, соединение шаблона с узлом сети создаст триггер у узла сети, который будет зависеть от такого же триггера, что и шаблонный триггер. Это позволяет, например, иметь шаблон, в котором некоторые триггеры зависят от триггеров роутера (узла сети). Все узлы сети соединенные с этим шаблоном будут зависеть от этого конкретного роутера.
Зависимость триггера узла сети от шаблонного триггера не может быть добавлена.
Зависимость триггера может быть добавлена от прототипа триггера к другому прототипу триггера (для одного и того же правила низкоуровневого обнаружения) либо к реальному триггеру. Прототип триггера не может быть зависим от прототипа триггера другого правила обнаружения или от триггера созданного из прототипа триггера. Прототип триггера узла сети не может быть зависим от шаблонного триггера.

Я так понимаю что моя схема 1 попадала под условие:

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

Заранее спасибо за помощь.

[Kos]

Опишу, насколько я это понимаю.

У узла можно прописать 2 IP мониторинга к примеру по SNMP, при этом один из IP является основным.
Значит ли это что при отсутствии данных по default IP, zabbix начнет снимать данные по 2му IP узла?

Нет, не значит. Это значит лишь то, что после добавления второго IP к свойствам узла в настройках каждого элемента данных появится возможность выбора - с какого из этих IP запрашивать данные. Переключаться между ними никто не будет: как сконфигурировано, так и будет опрашивать.

Собственно в каких целях можно использовать 2й IP и зачем он нужен?

Ну, например, у нас есть дисковый массив с двумя контроллерами - каждый со своим менеджмент-интерфейсом и со своим IP-адресом. Хотя "железяка" одна, но мониторить надо оба контроллера.
Другой пример: навороченный свитч, к которому можно обращаться как по IP-адресу, назначенному для работы в качестве маршрутизатора (проверять, пингуется ли default route для этажа), так и по IP-адресу, опять-таки, менеджмент-интерфейса (собирать данные по SNMP).

Выдергиваю кабель из узла "Микротик" и получаю срабатывание тригера "Доступность Интернет" и тригера доступности узла "Mikrotik".
Почему? Где логическая ошибка?

Логическая ошибка в предположении, что данные опроса разных устройств будут приходить и обрабатываться строго синхронно, хотя на самом деле всё строго наоборот.

Во-первых, данные разных опросов никак между собой не синхронизированы: Вы не можете быть уверены, что при "выдёргивании кабеля" первый отрицательный пинг придёт именно в результате пингования Микротика, а не антенны или кого-то дальше. Вполне возможно, что первым пришёл ответ на попытку пропинговать, например, 8.8.8.8.

Во-вторых, каждое пришедшее значение обрабатывается индивидуально, даже если они пришли в течение одной секунды. Пришёл отрицательный пинг от 8.8.8.8 - получили срабатывание триггера "Доступность Интернет", сразу после этого пришёл отрицательный результат пинга Микротика - сработал триггер доступности узла "Mikrotik".

Я сам не очень увлекаюсь зависимыми триггерами, но другие завсегдатаи этого форума советуют в таких случаях делать условия триггеров такими, чтобы гарантировать правильный порядок срабатывания. Например: 1) триггер недоступности Микротика должен срабатывать при получении двух отрицательных проверок подряд; 2) триггер недоступности передающей антенны - после четырёх неудачных проверок подряд, 3) триггер недоступности следующей за ней антенны - после шести неудачных проверок подряд; ну и так далее.

[kharkov_max]

Я сам не очень увлекаюсь зависимыми триггерами, но другие завсегдатаи этого форума советуют в таких случаях делать условия триггеров такими, чтобы гарантировать правильный порядок срабатывания. Например: 1) триггер недоступности Микротика должен срабатывать при получении двух отрицательных проверок подряд; 2) триггер недоступности передающей антенны - после четырёх неудачных проверок подряд, 3) триггер недоступности следующей за ней антенны - после шести неудачных проверок подряд; ну и так далее.

Я вот то же не увлекался, но для красоты мероприятия сделать необходимо.
Планируется подключение gsm шлюза к серверу и рассылка sms по критическим проблемам т.к. большая часть узлов находится за шлюзом при срабатывании будет куча ложных sms ...

Хм .. увеличивать кол-во проверок это идея ...
Значит ли это что мне придется отвязать шаблон от некоторых узлов и добавлять элементы данных и тригеры вручную на каждый узел?
Я так понимаю что увеличить кол-во пингов до узла в элементах узла созданных через шаблон нельзя ...

[Kos]

Ну, можно извратиться через макросы. Что-нибудь вроде:

{Template ICMP Ping:icmpping.max(#{#MAX_PINGS})}=0

При этом для макроса {#MAX_PINGS} определить значение по умолчанию на уровне шаблона, а при необходимости - переопределять на уровне конкретного хоста.

[kharkov_max]

Kos

Огромное спасибо за наводку, буду пробовать ...

[kharkov_max]

Создал макрос в шаблоне и сзменил тригер.
Но получилось обновить только так

{Template ICMP Ping:icmpping.max({$MAX_PINGS})}=0

Без #
Вроде данные есть, чем чревато без # ?

[Kos]

Было:
Параметр функции без решётки задаёт время (в секундах), с решёткой - количество значений. Наверное, если иначе не позволяет, то можно эту решётку в значение макроса вставить.

Исправлено:
Ой, это я лажанулся. Конечно, в имени макроса должен быть доллар, а не решётка. Это я последнее время lld занимался, вот меня и "переклинило" (тамошние макросы как раз через решётку пишутся).

[yukra]

Создал макрос в шаблоне и сзменил тригер.
Но получилось обновить только так

{Template ICMP Ping:icmpping.max({$MAX_PINGS})}=0

Без #
Вроде данные есть, чем чревато без # ?

Ничем. На тему синтаксиса лучше всегда сверяться с офф. документацией, а не постами на форуме

https://www.zabbix.com/documentation/3.0/ru/manual/config/macros/usermacros

[kharkov_max]

Вроде все заработало как нужно ...

Хочу вернуться к вопросу 2х IP.

Предположим что устройство в интернет (шлюз в интернет для удаленной локальной сети) имеет несколько внешних IP.
Данное устройство необходимо мониторить, в моем случае это mikrotik который чудесно работает по SNMP.

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

По факту моя хотелка сводится к следующему:
Если доступен провайдер 1 удаленного узла, то снимаем данные по 1му провайдеру.
Если проайдер 1 не работает и работает провайдер 2 то снимаем по провайдеру 2.
Если работают оба провайдера. то снимаем данные по провайдеру 1 т.к. он основной...

Может у гуру есть подобные логические решения?

[ssh39]

Я у себя сделал на узел 2 макроса {$HOST_IP1} и {$HOST_IP2}, дальше сделал шаблон с айтемами на оба макроса простая проверка по ключу icmpping[{$HOST_IP1},,,,], и навесил тригерров на оба канала {шаблон:icmpping[{$HOST_IP1},,,,].max(#3)}=0

[kharkov_max]

Суть сводится не только к мониторингу доступности внешнего IP провайдера, а и к мониторингу самого устройства (mikrotik) и другого железа которое стоит за ним ...

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

Пишем скрипт переключения на резервный канал при отваливании основного с задержкой 3-5 мин, VPN поднимется сам через дефолтное подключение шлюз становится доступен для zabbix по серому IP через туннель.
Ну и придется поставить большее время на срабатывания триггера о проблеме, учтется переключение на резервный канал и т.д. ...

Как то так ...