Мониторинг хоста с 2-мя IP

[Someone]

Доброго времени суток, aLL.

Наверняка вопрос уже задавался, если да - ссылочку на решение бы...

Дано:
Zabbix-сервер 5.0.2 на конторе, у конторы - два выхода в интернет, на обоих стоят VPN-сервера (равнозначные), каждый со своей подсетью. Удаленные клиенты подключаются к этим VPN

Необходимо:
Мониторить удаленного клиента - собирать метрики, отображать доступность. В основном нужно управлять иконкой доступности хоста, которая ZBX.

Описание задачи:
Клиент подключается то к одному, то к другому VPN-серверу. Схема подключения- на изображении ниже. Для упрощения выкинем Zabbix-proxy и считаем, что VPN-сервера напрямую подключаются к Zabbix-серверу.


При создании хоста на Zabbix-сервере в "Интерфейсах" указываю 2 IP - по адресу от каждой подсети VPN. Пример описания хоста - на изображении ниже.


Проблема в том, что если клиент подключен к VPN-серверу с подсетью 10.30.0.0/16 и адрес 10.30.0.10 в описании хоста указан как "по умолчанию", то иконка доступности хота АКА "ZBX" светится зеленым. Если же клиент подключается ко второму VPN-серверу (и получает адрес из сети 10.40.0.0.16) то иконка "краснеет" - хост, типа, недоступен. Но метрики, естественно, при этом собираются. У клиента стандартный шаблон Zabbix_agent.

Вопрос:
Как сказать (если это возможно) Zabbix-серверу проверять ВСЕ интерфейсы из описания хоста и, если НИ ОДИН не отвечает - тогда только "краснеть" иконку ZBX?
Или чем заменить стандартную проверку агента так, чтобы самому устанавливать статус иконки доступности хоста кастомной внешней проверкой или еще как...

Что было опробовано:
1. Создано правило обнаружения (на изображении)



2. Написан скрипт, выполняемый на сервере, который пингует хост и ставит (посредством Zabbix-API) хосту IP-адрес "по умолчанию" тот, который ответил. Это работает, но, ИМХО, как-то это не решение...

[Hamardaban]

ИМХО не верна сама постановка задачи с использованием ZBX ico.
Иконка ZBX - это всего лишь нечто вторичное указавающее что на по адресу основного интерфейса доступен пассивный агент zabbix.....
Подходите к задаче с точки зрения сбора метрик и реагирования на их отклонения за рамки нормы путем срабатывания триггеров.
Ну и визуализации этих событий.

UP
вот еще один взгляд на проблему
https://blog.zabbix.com/monitoring-a...-zabbix/11349/
Очень похоже на псевдо DDNS.

Может имеет смысл опереться именно на DDNS? В свойствах интерфейса указать dns имя, а клиентский комп заставить регистрироваться в днс?

[Someone]

Спасибо за ответ.

Иконка ZBX - это всего лишь нечто вторичное указавающее что на по адресу основного интерфейса доступен пассивный агент zabbix.....

Как я понимаю, возможно неверно, но: в картах сети состояние хоста (ОК или ПРОБЛЕМА) опирается именно на состояние "иконки", то-есть то, что получено или не получено от пассивного агента, так? То-есть уже есть как минимум два "экрана", где информация о хосте не отражает действительность, если использовать именно ZBX-иконку и инфу от пассивного агента.
Срабатывание триггеров и реакция - это все верно и понятно, но вот есть страница "Узлы сети", где есть колонка "Доступность". Получается, что мне нужно понимать и помнить, что хосты с одним IP я могу смотреть именно тут, а если не один IP - где-то еще. Путаница выходит...
Опять же, зачем тогда в хосте в "Интерфейсах" можно указать несколько адресов Zabbix-агентов, если сервер всегда использует только первый (вернее, тот, который "по-умолчанию")?
На иконку ZBX как-то можно "влиять", менять ее значение напрямую?

вот еще один взгляд на проблему
https://blog.zabbix.com/monitoring-a...-zabbix/11349/
Очень похоже на псевдо DDNS.

Спасибо, посмотрел. Я изначально и думал сделать какой-нибудь DNS-keepalive и привязать хосты по имени. Но в итоге вышло так, что в целом сейчас вот такой вот "костыль" у нас и сделан, только оперируем адресами, а не ДНС-записями. А именно: питон-скрипт на сервере со своим конфигов хостов, по крону пингующий хосты и меняющий IP-адрес в описании хоста на сервере через Zabbix-API. КМК, не совсем решение в плане оптимальности, когда счет хостов пойдет на сотни, плюс - вести отдельную базу адресов хостов...

[Kos]

Как я понимаю, возможно неверно, но: в картах сети состояние хоста (ОК или ПРОБЛЕМА) опирается именно на состояние "иконки", то-есть то, что получено или не получено от пассивного агента, так?

Мне кажется, не совсем так.
Т.е. первая часть утверждения - согласен (в картах сети отображается, есть ли какие-то проблемы, т.е. сработавшие триггеры, которые относятся к этому хосту).
Со второй частью - нет (с состоянием иконки "ZBX" это никак не связано).

На мой взгляд, самый простой вариант - это перевести работу агентов на всех клиентах на active-only режим. Тогда будет совершенно всё равно, какие у них IP-адреса и что там прописано в интерфейсах (это важно только для пассивного режима). А нет, так тоже не получится: у вас два разных прокси-сервера с разными IP-адресами... А можно ли настроить так, чтобы использовалось фиксированное DNS-имя прокси-сервера, а в зависимости от того, через какой VPN подключился, это имя разрешалось бы в IP-адрес ближайшего к нему прокси?

[Hamardaban]

Судя по схеме с точки зрения сервера забикс прокси один - что упрощает ситуацию (в настройках хоста не нужно менять прокси)
Сделать разрешение одного днс имени в разные ip в зависимости от сети клиента тоже довольно просто...
Наверно вариант с активным агентом наиболее приемлем, если отойти от концепции иконки ZBX. ;-)

[Someone]

Kos

Нет, zabbix-прокси один, он смотрит на две сети, к которым клиенты подключаются.

А можно ли настроить так, чтобы использовалось фиксированное DNS-имя прокси-сервера, а в зависимости от того, через какой VPN подключился, это имя разрешалось бы в IP-адрес ближайшего к нему прокси?

Эмм, немножко не понял схему...

Hamardaban

Сделать разрешение одного днс имени в разные ip в зависимости от сети клиента тоже довольно просто...

Разрешение имени в ЖИВОЙ НА ДАННЫЙ МОМЕНТ ВРЕМЕНИ IP-адрес удаленного хоста - это не так просто. Тут round-robin и прочие подобные dnsmasq-решения не проходят. Как-то внятных решений не нашел, может, плохо искал...Так-то да - с именем, развязываемым в живой IP, проблемы c агентами не будет и этого топика бы не было
Если отойти от иконки ZBX: чем тогда сделать сводную таблицу "хост - жив, хост - мертв"? И как это отображать на картах сети - ну, какой-то индикатор прицепить под хостом, что он жив или мертв?

Я конечно, извиняюсь за занудство, просто для себя хочу понять: пассивный zabbix-агент из интерфейсов хоста берет на проверку только один, который "по умолчанию" и все, остальные интерфейсы ему по боку? Это все, так сказать, by design и нечего тут мозги колупать себе и людям. Или нет?
И на это все никак не повлиять, скажем, другим способом определять доступность и самому эту иконку "красить" в красное или зеленое?

[Hamardaban]

Про DNS:
речь шла о том, чтобы клиент подключаясь к разным VPN серверам получал для прописанного в его забикс_агент конфиге dns имени в ServerActive различные IP адреса соответствующие сети к которой он подключен.Это просто - или vpn сервер впихивает клиенту записи в hosts , или 2 dns сереера с различными записями для одной и тойже заны , или 1 dns с разделением зон (bind == view).
Про активного агента:
т.к. при этой схеме агент обращается к серверу и уже не важно какой интерфейс основной\не основной. главное чтобы он был у узла.
Про доступность :
попробуйте сами провести простые эксперименты с активным агентом и ключем agent.ping
Про иконку:
"Красить" ее произвольно не получиться (имеется ввиду штатно)
Состояние проблема\Ок у узла сети (по-простому) определяется есть ли по нему сработавшие триггеры . Если сделаете например триггер на nodata на agent.ping то он будет определять в каком состоянии узел сети.Иконку zbx не покрасит! Но например на картах можно визуализировать доступен хост или нет.

[Kos]

Kos

Нет, zabbix-прокси один, он смотрит на две сети, к которым клиенты подключаются.

Эмм, немножко не понял схему...

Я имел в виду, что при использовании агента в активном режиме в его настройках задаётся ссылка на Zabbix-сервер или прокси (в виде IP-адреса либо DNS-имени).
На вашей схеме изображены два прокси с разными IP-адресами (из 30-й сетки и из 40-й). Это меня и смутило, т.к. указать в настройках агента ссылки на два разных активных сервера технически можно, но в данном случае неправильно (данные с двух проксей дублировались бы).

Хотя, возможно, я и неправ, т.к. то, через какой прокси мониторится конкретный агент, указывается ещё и в свойствах самого хоста...
Да, при отсылке данных напрямую на единственный Zabbix-сервер (либо единственный Zabbix-прокси) проблем бы не возникало.

Если отойти от иконки ZBX: чем тогда сделать сводную таблицу "хост - жив, хост - мертв"? И как это отображать на картах сети - ну, какой-то индикатор прицепить под хостом, что он жив или мертв?

Это вообще разные вещи. Если у вас хост недоступен, то в нормальной ситуации сработает какой-то триггер (типа, Agent unreachable - агент не отвечает на agent.ping более N минут), и этот триггер подсветит своим цветом иконку хоста на карте сети. Безотносительно к цвету иконки ZBX, с вопроса о которой началась данная тема.

Добавлено:
Ну вот, пока писал, коллега Hamardaban уже успел ответить!

просто для себя хочу понять: пассивный zabbix-агент из интерфейсов хоста берет на проверку только один, который "по умолчанию" и все, остальные интерфейсы ему по боку?

Пассивный zabbix-агент вообще ничего не берёт, он отвечает на запросы сервера.
Интерфейс по умолчанию влияет лишь на то, какой из интерфейсов будет по умолчанию подставляться при создании новых элементов данных, больше ни на что. Для хостов с несколькими интерфейсами каждый элемент данных будет принадлежать к какому-то одному из них (и можно выбрать, к какому именно). Это не относится к тем элементам данных, для которых неважно, к какому интерфейсу они относятся - в частности, Zabbix agent (active) или Trapper.
Для элементов данных с типом "Zabbix agent" (пассивный) не агент, а сервер (либо прокси) использует указанный интерфейс, чтобы знать, куда делать запрос. И если на все запросы в течение какого-то времени ответа не приходит, то сервер считает, что агент не отвечает и помечает его как "host unreachable", чтобы тратить на него меньше ресурсов (подробнее здесь). Какой из интерфейсов при этом указан у хоста в качестве умолчабельного - совершенно без разницы.

[Someone]

Hamardaban

речь шла о том, чтобы клиент подключаясь к разным VPN серверам получал для прописанного в его забикс_агент конфиге dns имени в ServerActive различные IP адреса соответствующие сети к которой он подключен.Это просто - или vpn сервер впихивает клиенту записи в hosts , или 2 dns сереера с различными записями для одной и тойже заны , или 1 dns с разделением зон (bind == view).

Хм, а это мысль, это надо подумать, спасибо большое за "наколку".

Состояние проблема\Ок у узла сети (по-простому) определяется есть ли по нему сработавшие триггеры . Если сделаете например триггер на nodata на agent.ping то он будет определять в каком состоянии узел сети.Иконку zbx не покрасит! Но например на картах можно визуализировать доступен хост или нет.

Ага, теперь понятнее становится "вся эта кухня", благодарю.

Kos

На вашей схеме изображены два прокси с разными IP-адресами

Не, zabbix-прокси один. 30 и 40 сети - это ВПН-сервера.

Да, при отсылке данных напрямую на единственный Zabbix-сервер (либо единственный Zabbix-прокси) проблем бы не возникало.

Простите, не понимаю. Или я Вас запутал.
По схеме- один zabbix-прокси, который имеет маршруты в ВПН сети 10.30.х.х и 10.40.х.х через внутреннюю подсеть. zabbix-сервер подключен к zabbix-прокси своей сетью. Удаленные хосты цепляются через один из ВПН-северов к одному zabbix-прокси.

... этот триггер подсветит своим цветом иконку хоста на карте сети. Безотносительно к цвету иконки ZBX, с вопроса о которой началась данная тема.

Ага. То-есть, создав свой триггер, проверяющий (не важно как) ОБА интерфейса я могу, в случае отсутствия ответа "покрасить" на карте цветом триггера отдельно взятый хост, так? Если так, то - пес с ней - c ZBX-иконкой

Пассивный zabbix-агент вообще ничего не берёт, он отвечает на запросы сервера.

Тут я неправильно выразился, прошу прощения.
Имелось ввиду, что сервер "пинает" удаленного агента ТОЛЬКО по адресу "по-умолчанию", не смотря на другие адреса, прописанные в "Интерфейсы".
Касательно остального - мне надо время осознать это

Спасибо за ответы.

В целом, промежуточно подытоживая:
- для мониторинга хоста с несколькими адресами zabbix-агентом (пассивным) нужно хост или по имени адресовать, перекладывая развязывание имени в ЖИВОЙ IP-адрес на кого-то другого;
- если во вкладке "Интерфейсы" UI-сервера в настройках хоста прописаны несколько IP-адресов для Zabbix-агентов, zabbix-агент (пассивный) берет только установленный "По умолчанию";
- доступность хоста иконкой ZBX делается тупо обращением по интерфейсу "По умолчанию", игнорируя остальные;
- управлять напрямую цветом ZBX-иконки низзя;

[Kos]

Kos


Не, zabbix-прокси один. 30 и 40 сети - это ВПН-сервера.
Простите, не понимаю. Или я Вас запутал.

Действительно, я сам запутался.
Если Zabbix-proxy имеет один IP, то проблем вообще нет: используйте active-only режим на агентах, и не надо париться со всем остальным :-)

- если во вкладке "Интерфейсы" UI-сервера в настройках хоста прописаны несколько IP-адресов для Zabbix-агентов, zabbix-агент (пассивный) берет только установленный "По умолчанию";
- доступность хоста иконкой ZBX делается тупо обращением по интерфейсу "По умолчанию", игнорируя остальные;

Вот это не так. См. мой предыдущий ответ (часть "Добавлено:").

[Someone]

"Чем дальше в лес - тем толще партизаны"... Вконец запутался.
Застрял на банальном: Проверить доступность хоста простым пингом с сервера ОБОИХ интерфейсов удаленного хоста. В результате ответит один из них или никто. Соответственно, в триггере применить ИЛИ к обоим результатам и если 1 - хост на связи.
Можно пример того, как это сделать? В каких переменных на сервере хранятся значения, в частности, Интерфейсы агентов?
icmpping пингует только хост по умолчанию. А мне нужно ему сказать, что есть еще интерфейсы.
Настройка триггеров на {HOST.IP1} и {HOST.IP2} посылает в ошибку "Name or service not known"
Продулблировал IP-адреса узла в макросы узла и через них пытаясь пинговать - тоже шляпа.

[Kos]

"Чем дальше в лес - тем толще партизаны"... Вконец запутался.
Застрял на банальном: Проверить доступность хоста простым пингом с сервера ОБОИХ интерфейсов удаленного хоста. В результате ответит один из них или никто. Соответственно, в триггере применить ИЛИ к обоим результатам и если 1 - хост на связи.
Можно пример того, как это сделать? В каких переменных на сервере хранятся значения, в частности, Интерфейсы агентов?
icmpping пингует только хост по умолчанию. А мне нужно ему сказать, что есть еще интерфейсы.
Настройка триггеров на {HOST.IP1} и {HOST.IP2} посылает в ошибку "Name or service not known"
Продулблировал IP-адреса узла в макросы узла и через них пытаясь пинговать - тоже шляпа.

Если решать задачу "в лоб", т.е. делать именно то, что Вы пытаетесь в процитированном фрагменте, то это делается так:

• делается два разных элемента данных, каждый из которых пингует свой IP-адрес.
• в триггере, как Вы верно пишете, проверяем значения обоих (если не пингуется ни один - то проблема).

Но здесь будет, как минимум, два затруднения:

• это сложнее, чем пинговать один адрес;
• нужно как-то поддерживать актуальность пингуемых адресов (где-то хранить каждый из них, если они меняются - своевременно модифицировать и т.п.).

Тем более, что штатных макросов, содержащих все интерфейсы хоста, чтобы их можно было использовать при определении элента данных, в Zabbix-е просто нет. Те нумерованные макросы, которые Вы упоминаете ({HOST.IP1} и {HOST.IP2}) можно использовать только в триггерах (не в айтемах!), и означают они не "первый и второй интерфейсы хоста" (как многие часто ошибочно полагают), а "интерфейсы первого и второго айтемов, упомянутых в данном триггере".

Я бы предложил другой подход, что значительно упрощает задачу, а именно: пинговать не агентов со стороны сервера, а сервер со стороны агентов. Самый простой способ - использовать активный режим работы агента, метрику agent.ping (которая всегда возвращает единицу) и триггер с функцией nodata(), который бы срабатывал, когда данных (тех самых единиц) не получено дольше ожидаемого времени.
Совершенно штатная вещь, доступна, что называется, "из коробки", и не надо возиться с разными интерфейсами. Какая Вам разница, через какой из интерфейсов агент работает; важно ведь, что он работает.