Мониторинг маршрутизатора по нескольким ip

[MadBear541]

Кто подскажет как организовать в Zabbix мониторинга маршрутизаторов по нескольким ip. Объясняю ситуацию.
Есть более 200 маршрутизаторов, на разных объектов, у которых на разных сетевых портах, как правило 3, прописаны свои ip в разных vlan. Это ip основного провайдера, ip резервного провайдера и ip КСПД. По ip КСПД через snmp мониторим сами железки. Для мониторинга активности самих ip, прописанных на маршрутизаторах, ввиду того что первоначально оборудование вводилось в эксплуатацию "срочно", была массовое обновление оборудования, ввели одно и тоже оборудование в систему как несколько узлов, каждый со своим ip. Ввиду роста ресурсов и данных для мониторинга развернули новый сервер Zabbix и встал вопрос как написать шаблон на маршрутизаторы, который позволил бы в системе создать один узел с несколькими ip для мониторинга. сразу скажу что варианты открыть доступ до устройства по SNMP на все ip не вариант из-за ИБ и обнаружение по LLD тоже не подходит так как если связь легла на основном адресе, то устройство в системе определяется как не доступное.

[Hamardaban]

А в чем именно задача мониторинга? Какие метрики хотите снимать?
Для данных по устройству достаточно SNMP подключения по одному IP (я понял у вас ак и сделано)
Для мониторинга доступости 2х интерфейсов у одного хоста можно использовать простую проверку icmpping[{HOST.IP},x,y] выбрав в элементах разные интерфейсы и параметры для уникальности ключа.
в шаблоне заранее сказать какой интерфейс использовать в элементе данных не получиться. так что дополнительная работа через руки или API

[MadBear541]

простая проверка, пинг, кол-во пакетов, потери.
если же возникает какая-то проблема через порт КСПД, в который открыт SNMP трафик, то получается что мы не узнаем какая ситуация с другими портами. А через них при определённых манипуляциях можно подключиться и разобраться с проблемой или узнать что лежит сама железка или какой-то провайдер.

[Whols]

Вопрос как я понял в автоматизации при развертывании шаблона. Так как номерные макросы {HOST.IP<1-9>} поддерживаются только в выражениях триггеров, вам надо создать хост с одним интерфейсом и к нему добавить два пользовательских макроса (с именем {$HOSTIP2} и 3 соответственно) под два других интерфейса. Тогда у вас будет единый шаблон icmpping для трех элементов с ключами - icmpping[{HOST.IP}], icmpping[{$HOSTIP2}], icmpping[{$HOSTIP3}].
-
Узлы можно добавить через автообнаружение и там же повесить на них них шаблон icmpping с ручными макросами $HOSTIP2(3)=127.0.0.1 (временно, чтоб не спамил алёртами). Но адреса в эти макросы (внешние IP адреса) придется все же руками потом внести.

[MadBear541]

Вопрос как я понял в автоматизации при развертывании шаблона. Так как номерные макросы {HOST.IP<1-9>} поддерживаются только в выражениях триггеров, вам надо создать хост с одним интерфейсом и к нему добавить два пользовательских макроса (с именем {$HOSTIP2} и 3 соответственно) под два других интерфейса. Тогда у вас будет единый шаблон icmpping для трех элементов с ключами - icmpping[{HOST.IP}], icmpping[{$HOSTIP2}], icmpping[{$HOSTIP3}].

я пробовал так. но почему-то выдает значения "0" хотя зайдя в консоль на сервер пинги идут.

[Whols]

Что то неправильно делаете. Я так мониторил 200 шлюзов с разными интерфейсами. Развертывал одним унифицированным шаблоном всё.

icmpping[{HOST.IP}], icmpping[{$HOSTIP2}], icmpping[{$HOSTIP3}]

Ключи верно прописали, точно, как в цитате? (обратите внимание на знаки и символы)

[Semiadmin]

А что нужно-то? Пинговать все ip, прописанные как интерфейсы хоста в Zabbix? Отдискаверить их через внутреннее LLD rule zabbix[host,discovery,interfaces] и сделать прототипы проверок.

[MadBear541]

Что то неправильно делаете. Я так мониторил 200 шлюзов с разными интерфейсами. Развертывал одним унифицированным шаблоном всё.

Ключи верно прописали, точно, как в цитате? (обратите внимание на знаки и символы)

Да, единственное делал не Ping, а его время так как если время не нулевое, то и пинг есть, и потери смотрел. ( icmppingsec[{HOST.IP}], icmppingsec[{$HOSTIP2}], icmppingsec[{$HOSTIP3}], icmppingloss[{HOST.IP}], icmppingloss[{$HOSTIP2}], icmppingloss[{$HOSTIP3}] )
Сам Ping проверил и он действительно работает, но это в условиях моей организации не очень информативно.

А что нужно-то? Пинговать все ip, прописанные как интерфейсы хоста в Zabbix? Отдискаверить их через внутреннее LLD rule zabbix[host,discovery,interfaces] и сделать прототипы проверок.

Нужны время ping и потери. Так как у нас есть три интерфейса через которые подключены внешние провайдеры, один из них предоставляет услуги по связи нашей КСПД, и мы мониторим через него. Отделения где стоят данные железки работать могут и минуя КСПД, как правило это доступ в сеть интернет через второго провайдера и третий резерв для интернета и КСПД. Если канал КСПД падает, то если я правильно понял как работает внутренний LLD (по первому интерфейсу / ip), мы перестаем данные получать при наличии других активных интерфейсов, которые мы можем мониторить с сервера через написанные маршруты. Так что это не вариант

[Semiadmin]

то если я правильно понял как работает внутренний LLD (по первому интерфейсу / ip)

Вот тут уже я ничего не понял. Это LLD для того и предназначено, чтобы находить ВСЕ прописанные на хосте интерфейсы.

[Whols]

если я правильно понял как работает внутренний LLD (по первому интерфейсу / ip), мы перестаем данные получать при наличии других активных интерфейсов, которые мы можем мониторить с сервера через написанные маршруты. Так что это не вариант

Неверно поняли. LLD в данном случае предложен как процесс обнаружения прописанных (на хосте Zabbix) интерфейсов с целью создания нужных вам элементов данных. Добавляете интерфейс на хосте (например, для 3-его IP), процесс обнаружения его подхватит и создаст доп элемент из прототипа + подцепит нужный шаблон (пинг, лосс и тд). В итоге: с вас только прописать IP адреса, а Zabbix всю остальную работу сделает сам.
-
По поводу "нерабочих" элементов. Если взять отдельных хост (три интерфейса на нем) - что конкретно не работает? Все три элемента не получают данные?

[MadBear541]

Неверно поняли. LLD в данном случае предложен как процесс обнаружения прописанных (на хосте Zabbix) интерфейсов с целью создания нужных вам элементов данных. Добавляете интерфейс на хосте (например, для 3-его IP), процесс обнаружения его подхватит и создаст доп элемент из прототипа + подцепит нужный шаблон (пинг, лосс и тд). В итоге: с вас только прописать IP адреса, а Zabbix всю остальную работу сделает сам.
-
По поводу "нерабочих" элементов. Если взять отдельных хост (три интерфейса на нем) - что конкретно не работает? Все три элемента не получают данные?

С LLD я не разобрался. Я так понимаю: завожу узел, в макросах прописываю дополнительные IP (адреса интерфейсов), потом эти макросы я подставляю в правиле обнаружения например icmppingloss[{$HOSTIP3}], накидываю соответствующие элементы данных и прототипы графиков?

-

Попытаюсь объяснить. На одном хосте - Межсетевой экран / Маршрутизатор, есть три основных порта, они же интерфейса в которые заведены три разных провайдера (так вышло). Один это провайдер предоставляющий нам связь внутри нашей КСПД, он же канал для управления этим хостом. Второй это провайдер для интернета местного отделения. Третий это резервный канал для первых двух. Второй и третий можем мониторить через маршрут на главной железке. Надо мониторить на втором интерфейсе нагрузку и доступность (время пингов, потери) так же хотелось бы размер пакетов и их кол-во. На втором смотрим время пинга и потери, нас интересует только его работа. В новом шаблоне выходит что если падает основной канал у нас перестает мониториться все остальное.

И до сих пор не могу понять почему icmpping работает с макросом, а icmppingloss и icmppingsec нет, показывает значение 0

[Whols]

Попробуйте обозвать макрос как-то иначе или пропишите числовое значение (IP).

[MadBear541]

Попробуйте обозвать макрос как-то иначе или пропишите числовое значение (IP).

Пробовал. Не прокатывает