Как в zabbix добавить коммутатор

Обновлено: 04.07.2024

ошибок при отправке

ошибок при получении

Помимо этого можно считать имя интерфейса, MTU, скорость и другие параметры. Полный список смотрите на сайте Cisco .

Cisco Catalyst, как правило, поддерживают дополнительно:
.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1 — процент загрузки CPU
.1.3.6.1.4.1.9.9.48.1.1.1.5.1 — занятая память (в байтах)
.1.3.6.1.4.1.9.5.1.2.13.0 — статус температуры (1 — нормальная, 2 — повышенная, 3 — критическая)

Заметив, то что идентификаторы стандартизованы, я написал простенький скрипт на PHP, который позволяет сгенерировать XML-шаблон для Zabbix с нужными OID для всех портов. Мы протестировали его на оборудовании Cisco (500G, 2960. 3550 и 3750), 3Com (2426, 2924, 2948), паре D-Link и Zyxel 4012. (Кто хочет, может скачать исходники ).
Генератор создает шаблоны, которые умеют:

отслеживать параметры интерфейсов (см. таблицу выше) и выводить их на графике;
устанавливать триггер на падение порта;
устанавливать триггер на превышение скорости прироста ошибок на порте;
отслеживать загрузку процессора, памяти и температуры для Cisco.

После того, как вы сгенерировали и сохранили шаблон для устройства, сымпортируйте его: перейдите в Configuration → Templates и нажмите справа вверху кнопку Import . Создайте новый Host или отредактируйте существующий — привяжите к нему ваш шаблон.
Если вы хотите изменить какие-либо параметры (например, SNMP community), то это можно сделать прямо в Zabbix: зайдите в шаблон в Configuration → Templates , в Items выделите нужные элементы галочками и внизу выберите из выпадающего списка Mass update

Если прошло несколько минут после добавления к устройству шаблона, а данные от SNMP так и не появились, необходимо проверить, может ли сервер Zabbix считать данные с устройства. Делается это утилитой snmpget:
snmpget -v версия_протокола -c комьюнити адрес_устройства OID

Например, получим число отправленных байт на первом гигабитном порту для Cisco:
snmpget -v 2c -c qwerty 192.168.1.1 .1.3.6.1.2.1.2.2.1.16.10101
IF-MIB::ifOutOctets.10101 = Counter32: 2044250092

Для не-Cisco железки:
snmpget -v 2c -c qwerty 192.168.1.2 .1.3.6.1.2.1.2.2.1.16.1
IF-MIB::ifOutOctets.1 = Counter32: 1691279168

Чтобы прочитать полный список параметров с устройства выполните:
snmpwalk -v версия_протокола -c комьюнити адрес_устройства

Любители GUI для чтения SNMP-данных с устройства могут воспользоваться программами типа MIB Browser.

Также в свойствах Link вы можете настроить отображении линии красным в случае падения порта в down.

Мониторинг состояния портов

К сожалению, в Zabbix нет удобного инструмента для просмотра состояния отдельных портов устройств, поэтому его пришлось написать. Информация импортируется из Zabbix и выводится администратору в удобном виде:

Серый цвет порта обозначает, то что он находится в down. Цвет от зеленого до красного меняется в зависимости от загрузки порта. Гигабитные порты выделены рамочкой.

Минус скрипта в том, что он писался «для себя», поэтому установка достаточно корявая (-:. Скачайте исходники и прочитайте readme.

Нельзя не упомянуть о возможной проблеме с производительностью zabbix-сервера. Предположим, что вы раз в минуту получаете информацию об 11 параметрах каждого порта 50-ти 24-портовых свитчей. На базу данных zabbix-сервера ляжет нагрузка в среднем 220 записей в секунду. Для слабой машины она может оказаться непосильной. Поэтому рекомендуется ограничивать количество item'ов или увеличивать интервал проверки. Мы считаем достаточным запрашивать статус порта, трафик, количество ошибок и широковещательных пакетов раз в 60 секунд.

В следующей версии генератора шаблонов хотелось бы добавить возможность получения остальных параметров интерфейсов, выбор цветов линий для графиков, возможность указания скорости портов для не-Cisco устройств. Предложения приветствуются.

Выражаю благодарность Бугаенко Владиславу за помощь в создании и тестирования скриптов.

После того как мы установили и настроили серверную часть Zabbix 5.0. LTS. Для организации мониторинга необходимо настроить сбор информации с узлов сети.

Содержание:

1. Добавление узла сети в панели управления Zabbix.

1.4. Выбираем из списка требуемые шаблоны и добавляем их:

Теперь переходим к настройке Zabbix-agent в операционной системе нашего узла.

2. Установка и настройка zabbix-agent в CentOS.

2.2. В разделе ниже будет сгенерирована команда для добавления репозитория Zabbix. В нашем случае это CentOS 7. Запускаем терминал на узле и вводи команды:

2.3. После установки агента переходим к редактированию конфигурационного файла:

И указываем параметры подключения к серверной части Zabbix:

2.4. Сохраняем изменения (F2) и запускаем процесс:

2.5. Переходим в Веб-панель управления Zabbix и фиксируем подключение узла сети:

3. Установка и настройка zabbix-agent в Debian.

3.2. В разделе ниже будет сгенерирована команда для добавления репозитория Zabbix. В нашем случае это CentOS 7. Запускаем терминал на узле и вводи команды:

3.3. После установки агента переходим к редактированию конфигурационного файла:

И указываем параметры подключения к серверной части Zabbix:

3.4. Сохраняем изменения (F2) и запускаем процесс:

3.5. Переходим в Веб-панель управления Zabbix и фиксируем подключение узла сети:

4. Установка и настройка zabbix-agent в Windows.

4.2. Скачиваем архив по сгенерированной ссылке:

4.10. Не лишним будет добавить правила в Бранмауер Windows:

4.11. Переходим в Веб-панель управления Zabbix и фиксируем подключение узла сети:

5. Установка и настройка zabbix-agent в pfSense.

5.4. Подтверждаем установку пакета:

5.5. Дожидаемся окончания установки пакета:

5.7. Включаем сервис и указываем параметры подключения к серверу:

5.8. Сохраняем изменения:

5.9. Переходим в Веб-панель управления Zabbix и фиксируем подключение узла сети.

Вы возможно захотите использовать SNMP мониторинг устройств таких как принтеры, сетевые коммутаторы, маршрутизаторы или ИБП, которые, как правило, поддерживают SNMP и для которых было бы непрактично пытаться настраивать комплексные системы управления или Zabbix агенты.

Чтобы была возможность получать данные переданные SNMP агентами с этих устройств, Zabbix сервер должен быть изначально сконфигурирован с поддержкой SNMP.

SNMP проверки выполняются только через UDP протокол.

Начиная с версии 2.2.3 демоны Zabbix сервера и прокси опрашивают устройства SNMP множественными значениями за один запрос. Это поведение повлияет на все виды SNMP элементов данных (простые SNMP элементы данных, элементы данных с динамическими индексами и также низкоуровневые SNMP обнаружения) и обработка SNMP элементов данных сейчас должна быть более эффективной. Пожалуйста обратите внимание на раздел с техническими подробностями ниже, описывающий как работает изнутри этот функционал. Начиная с Zabbix 2.4 у каждого интерфейса также имеется настройка “Использовать массовые запросы”, которая позволяет отключать массовые запросы у устройств, которые не способны обработать их должным образом.

Начиная с Zabbix 2.2.7 и Zabbix 2.4.2 процессы сервера и прокси будут журналировать строки похожие на следующие в случае получения неправильного/искаженного SNMP ответа: Пока они не покрывают все возможные проблемные случаи, но они являются удобным удобным идентификатором отдельных SNMP устройств на которых необходимо отключить массовые запросы.

Начиная с версии Zabbix 2.2 демоны сервера и прокси корректно обрабатывают параметр конфигурации Timeout при выполнении SNMP проверок. Дополнительно демоны не выполняют повторных запросов после одного неуспешного (по превышении времени ожидания/неверные настройки учетных данных) SNMP запроса. Ранее на самом деле использовались стандартные для библиотеки SNMP значения времени ожидания и количества повторов (1 секунда и 5 повторов соответственно).

Начиная с версии Zabbix 2.2.8 и Zabbix 2.4.2 демоны сервера и прокси всегда выполняют один повторный запрос: либо через механизм библиотеки SNMP, либо через внутренний механизм сбора множества значений за один запрос (bulk).

Если выполняется мониторинг устройств по SNMPv3, убедитесь что msgAuthoritativeEngineID (также известное как snmpEngineID или “Engine ID”) никогда не будет общим для двух и более устройств. Согласно RFC 2571 (раздел 3.1.1.1) оно должно быть уникальным для каждого устройства.

Настройка мониторинга по SNMP

Для начала мониторинга устройства по SNMP, должны быть выполнены следующие шаги:

Шаг 1

Создайте узел сети для устройства с SNMP интерфейсом.

Введите IP адрес. Вы можете использовать один из поставляемых шаблонов SNMP (Template SNMP Device и другие), которые автоматически добавят некоторый набор элементов данных. Тем не менее, шаблон может быть не совместим с узлом сети. Нажмите на Добавить для сохранения узла сети.

SNMP проверки не используют Порт агента, он игнорируется.

Шаг 2

Узнайте строку SNMP (или OID) элемента данных, которую вы хотите мониторить.

Для получения списка строк SNMP, используйте команду snmpwalk (часть программного обеспечения net-snmp, которое вы должны были установить как часть инсталляции Zabbix) или эквивалентную утилиту:

Вы можете пройтись по списку пока не найдете строку которую вы хотите мониторить, например, если вы хотите мониторить входящее количество байт на вашем коммутаторе на 3 порту вы могли бы использовать IF-MIB::ifInOctets.3 из этой строки:

Обратите внимание, что последнее число в строке это номер порта, который вы ищите для мониторинга. Смотрите также: Динамические индексы.

Вывод команды покажет вам что-то наподобие этого:

Опять же, последнее число в OID является номером порта.

3COM кажется использует номера портов сотнями, например 1 порт = 101 порт, 3 порт = 103 порт, но в Cisco используются обычные номера, например, 3 порт = 3.

В последнем примере выше тип значение “Counter32” (32-битный счетчик), что внутренне соответствует типу ASN_COUNTER. Полный список поддерживаемых типов ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR и ASN_OBJECT_ID (с 2.2.8, 2.4.3). Приведенные типы грубо соответствуют “Counter32”, “Counter64”, “UInteger32”, “INTEGER”, “Float”, “Double”, “Timeticks”, “Gauge32”, “IpAddress”, “OCTET STRING”, “OBJECT IDENTIFIER” в выводе snmpget утилиты, но могут также отображаться как “STRING”, “Hex-STRING”, “OID” и другие, в зависимости от наличия полученной подсказки.

Шаг 3

Создайте элемент данных для мониторинга.

Все обязательные поля ввода отмечены красной звёздочкой.

Теперь сохраните элемент данных и перейдите в Мониторинг → Последние данные, чтобы увидеть ваши данные SNMP!

Обратите внимание на специфичные опции доступные только для SNMPv3 элементов данных:

Параметр	Описание
Имя контекста	Введите контекстное имя для определения элемента данных в SNMP подсети. Имя контекста поддерживается для SNMPv3 элементов данных с Zabbix 2.2.

В случае некорректных учётных данных SNMPv3 (имя безопасности, протокол/фраза-пароль аутентификации, протокол безопасности) Zabbix получит ERROR от net-snmp, за исключением ошибочного Фразы-пароль безопасности, в этом случае Zabbix получит ошибку ВРЕМЕНИОЖИДАНИЯ от net-snmp.

При изменениях в Протокол аутентификации, Фраза-пароль аутентификации, Протокол безопасности или Фраза-пароль безопасности, чтобы эти изменения применились, необходимо перезапустить сервер/прокси.

Пример 1

Параметр	Описание
Community	public
OID	1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0)
Ключ	<Уникальная строка, которая используется как ссылка в триггерах> Например, “my_param”.

Обратите внимание, что OID можно задать в числовом или строковом представлении. Тем не менее, в некоторых случаях, строковый OID должен быть сконвертирован в числовое представление. Для этого можно использовать утилиту snmpget:

Мониторинг SNMP параметров возможен, если указан флаг --with-net-snmp при конфигурировании исходных кодов Zabbix.

Пример 2

Мониторинг времени работы:

Параметр	Описание
Community	public
Oid	MIB::sysUpTime.0
Ключ	router.uptime
Тип информации	Числовой (с плавающей точкой)
Единица измерения	uptime
Множитель	0.01

Обработка массовых SNMP запросов

Начиная с 2.2.3 Zabbix сервер и прокси одним опросом запрашивают множество SNMP элементов данных. Такое поведение затрагивает следующие типы SNMP элементов данных:

Все элементы данных SNMP с одного интерфейса запланированы на опрос в одно время. Первые два типа элементов данных собираются поллерами порциями не более чем по 128 элементов данных, в то время как правила низкоуровневого обнаружения обрабатываются индивидуально как и ранее.

На низком уровне, есть два вида операций выполняемых при опросе значений: получение нескольких заданных объектов и прохождение дерева OID-ов.

Для “получения” используется GetRequest-PDU c не более чем 128 привязанных переменных. Для “прохождения”, используется GetNextRequest-PDU для SNMPv1 и GetBulkRequest с полем “max-repetitions” с наибольшим количеством в 128 полученных значений используется для SNMPv2 и SNMPv3.

Таким образом преимущества массовой обработки для каждого типа SNMP элемента данных описаны ниже:

простые SNMP элементы данных получают преимущество от улучшения “получения”; SNMP элементы данных с динамическими индексами получают преимущество и от улучшений “получения” и “прохождения”: “получение” используется для проверки индексов, а “прохождение” для построения кэша значений; правила низкоуровневого SNMP обнаружения получают преимущество от улучшения “прохождения”.

Тем не менее, есть техническая проблема что не все устройства способны вернуть 128 значений за один запрос. Некоторые всегда возвращают корректный ответ, но другие либо отвечают с ошибкой “tooBig(1)”, либо не отвечают вообще, когда потенциальный запрос превышает определенный лимит.

Для вычисления оптимального количества запрашиваемых объектов с устройства, Zabbix использует следующую стратегию. Начинается с осторожного запроса одного значения. Это запрос выполнен успешно, запрашивается 2 значения за один запрос. Если запрос снова выполнен успешно, запрашивается 3 значения за запрос и продолжается аналогично умножением количества запрашиваемых значений на 1.5, в результате получается следующая последовательность размера запросов: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Однако если устройство отказывается от ответа на определенный запрос (к примеру, 42 переменных), Zabbix делает 2 вещи.

Первое, для текущей серии элементов данных Zabbix делит пополам количество элементов данных за один запрос и запрашивает 21 переменных. Если устройство доступно, далее запросы должны работать в большинстве случаев, потому что известно что 28 переменных забиралось, а 21 значительно меньше. Тем не менее если проблема с запросами продолжается, Zabbix уменьшает количество запросов последовательно согласно этому алгоритму. Если и далее проблемы с запросами все еще актуальны, значит устройство определенно не отвечает и количество запросов это не корень проблемы.

Второе дело, которое делает Zabbix для дальнейших порций элементов данных - это, начиная с последнего удачного количества переменных (28 в нашем случае), продолжает увеличивать количество переменных за запрос на 1 до достижения лимита. Например, предположим что максимально возможное количество запросов для данного устройства это 32, последующие запросы будут следующими 29,30,31,32 и 33. Последний запрос будет неудачным и Zabbix никогда более не запросит 33 значения за один запрос. С этого момента, Zabbix всегда будет запрашивать 32 значения для этого устройства.

Если большие запросы неудачно завершаются с определенным количеством переменных, это может означать одно из двух. Точный критерий по которому устройство может ограничивать запросы неизвестен, но мы можем приблизительно рассчитать количество переменных. Первая вероятность - что количество значений примерно равно действительному лимиту размера для данного устройства в общем случае: иногда запросов либо меньше чем лимит, иногда больше. Вторая вероятность, что UDP пакет был потерян. В этом случае, если Zabbix сталкивается с неудачным запросом, он уменьшает максимальное количество запрашиваемых значение за запрос для попытки получения с устройства корректного диапазона, но ( начиная с 2.2.8) только до 2 раз.

В примере выше, если запрос с 32 переменными будет неудачен, Zabbix уменьшит количество до 31. Если неудача случиться снова, Zabbix уменьшит количество до 30. Тем не менее, Zabbix не будет уменьшать количество ниже 30, потому что он предположит, что следующие проблемы по причине потерянных UDP пакетов, чем скорее ограничение устройства.

Если, однако, устройство не может обрабатывать массовые запросы корректно и по другим причинам, начиная с Zabbix 2.4 имеется настройка “Использовать массовые запросы” у каждого интерфейса, которая позволяет отключить массовые запросы у этого устройства.

Россия

размер шрифта уменьшить размер шрифтаувеличить размер шрифта
Печать
Эл. почта
Станьте первым комментатором!

Сегодня мы рассмотрим автоматический опрос ЛВС, с целью добавить найденные устройства в систему мониторинга Zabbix.

Вступление

После импорта проекта в GNS3 обязательным условием нормальной работоспособности тестового стенда является правильная последовательность запуска узлов.

Сначала запускаем все маршрутизаторы Mikrotik CHR, и только после того, как появится приглашение о вводе имени пользователя во всех консолях, запускаем все остальные устройства.

После запуска всех узлов проверьте, чтобы в каждой подсети на VPCS была доступна ваша физическая ЛВС, например, шлюз по умолчанию.

Обратите внимание! При создании виртуальной машины выделите ей больше одного ядра, лучше 4, это позволит избежать проблем, так как процесс обнаружения устройств в ЛВС довольно требователен к CPU!

Так же выделите не менее 4 Гб оперативной памяти!

Маршрутизация до виртуальных сетей

Обязательно нужно прописать маршруты до наших виртуальных подсетей на самом сервере Zabbix.

В консоль на Zabbix сервере прописываем:

Где 192.168.0.100 – внешний, находящийся в вашей ЛВС, адрес виртуального Mikrotik CHR – GWMain

Обратите внимание, эти маршруты будут удалены после перезапуска сервера, чтобы сделать их постоянными обновите сетевые настройки сервера!

Пропишем DNS сервер нашего тестового стенда.

Откроем файл /etc/resolv.conf

Проверим доступность устройств в подсетях.

Все подсети доступны с сервера Zabbix, так что можно продолжать настройку мониторинга наших виртуальных сетей.

Добавляем обнаружение устройств (Discovery)

Zabbix умеет автоматически сканировать ЛВС на наличие новых устройств и добавлять их в базу мониторинга.

Откроем панель управления ( Dashboard ) и выберем Configuration-> Discovery

В этом окне вы найдете список правил обнаружения.

Для начала удалим правило по-умолчанию, для этого поставьте галочку напротив Local network и нажмите Delete, подтвердите удаление!

Добавим новое правило, нажмите на кнопку Create discovery rule

Name: Auto discovery LAN1

Discovery by proxy: No proxy

IP range: 172.16.100.1-13

Update interval: 2m - для теста поставим 2 минуты, в дальнейшем ставьте 1h или выше

Для поля Checks :

Нажмем Add и из списка выберем ICMP ping

Host name: DNS Name

Visible name: Host name

Теперь остается только ждать, пока Zabbix не начнет процесс обнаружения это может занять несколько минут.

Для того, чтобы следить за процессом откроем Monitoring->Discovery

Обратите внимание – Discovery только обнаруживает устройства в сети на основе правил обнаружения!

Чтобы добавить устройство в список хостов (Hosts) нам нужно создать правило действия (Actions), но сначала нужно создать группу хостов (Host groups) для группировки хостов наших подсетей.

Создание групп хостов (Host group)

Откроем Configuration->Hosts group

Выберите Create host group и введите имя группы и нажмите Add

Создадим четыре группы:

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

Добавление группы хостов к шаблону (Templates)

Введите icmp в поле Name и нажмите Enter и нажмите на строку ICMP Ping

Нажмите на Select

Поставьте галочку напротив LAN1, LAN2, LAN3 и ROUTERS и нажмите Select и нажмите Update , чтобы обновить шаблон

Создание правил действий (Actions)

Мы произвели обнаружение устройств и они были добавлены в базу данных, в раздел Discovery, но этого недостаточно, чтобы начать их мониторинг. Нам нужно добавить обнаруженные устройства в список Hosts, т.е. создать объекты типа Host. Для этого нам нужно создать действие (Action), которое будет срабатывать каждый раз, когда происходит обнаружение устройства.

Перейдем в раздел Configuration -> Actions

Нажмем на Trigger actions и выберем Discovery actions .

После этого можно приступать к созданию правила действия.

Нажмите Create action

On auto discovery of LAN1

В новом окне введите

Выберите Operations и нажмите Add

Add to host group

Выберите LAN1 и нажмите Select

Снова нажмите Add , но на этот раз выберите Operation type: Link to template

Нажмите Select и в новом окне Select

В поле Templates введите icmp и выберите ICMP Ping

Выберем Monitoring->Hosts и подождем около 2-4 минут, пока Zabbix не начнет добавлять хосты в группу.

Как видите, хосты были добавлены в базу данных.

Все вышенаписанное произведите для LAN2, LAN3 и ROUTERS.

Так же обнаружение позволяет обновлять данные для хостов, например, если вы в DNS забыли указать имя какого-либо узла, то при добавлении в DNS записи для этого узла, следующий раз, когда произойдет опроc, эти данные будут обновлены и для добавленного хоста!

Добавляем хосты на карту

Мониторинг сам по себе не имеет смысла, если данные не выводятся в виде, который удобен для восприятия.

Для отображения информации в Zabbix используются карты (Maps)

Откроем Monitoring -> Maps и нажмем Create map

Введите имя LAN1 и нажмем Add

В окне со списком карт нажмите на LAN1

Нажмите Edit map

Нажмите Map element: Add

Щелкните на добавленном элементе левой кнопкой мыши:

В поле Type выберите Host group

В Show выберите Host group elements

В поле Label введите

В поле Host group выберите LAN1

В Icons выберите Workstation_(64)

И нажмите Apply

Нажмите Update и Да

Снова щелкните на LAN1

Как видите мы добавили все хосты из группы на карту.

Обратите внимание, все устройства в ЛВС должны иметь записи на локальном сервере DNS, в противном случае, у вас вместо имени хоста будет отображаться два раза его IP адрес!

Прежде чем продолжить аналогично настройте обнаружение и создайте карты для LAN2, LAN3.

Добавьте обнаружение для маршрутизаторов.

В качестве диапазона используйте список: 172.16.101.251, 172.16.101. 252, 172.16.101.253, 192.168.0.100

Где 192.168.0.100 – внешний адрес виртуального Mikrotik CHR – GWMain

Добавьте карту для ROUTERS.

Создание общей карты сети

Когда устройства в ЛВС отображаются в одном месте, это очень удобно, так что давайте сведем их на одной карте.

Создадим еще одну карту и назовем её LAN

Добавьте на карту новый элемент

Выберите тип Map

Введите Label: LAN1

В пункте MAP выберите LAN1

В Icons выберите Cloud_(64)

Добавьте элементы для LAN2 и LAN3

Добавление маршрутизаторов на карту

Добавим элемент для GW1

Добавьте новый элемент

В Type выберите Host

В Label введите:

В Host введите gw1 и выберите хост из выпадающего списка

В Icons->Default выберите Router_symbol_(64)

Добавьте элементы для GW2, GW3 и GWMain

Для красоты добавим элемент типа Image

В Label введем WAN

В качестве картинки выберем Cloud_(64)

Вот что у нас получилось:

Добавление связей между узлами

Чтобы схема была понятней добавим связи между узлами.

Нажмите Ctrl и не отпуская кликните на WAN и GWMain , нажмите на Link: Add:

Будет создана связь между узлами. Вы можете сдвинуть окошко в сторону, если оно мешает выделять узлы!

Повторите со всеми узлами как на рисунке ниже:

Вы можете посмотреть все связи узла просто щелкнув по нему:

Нажмите Update и Yes войдите в карту LAN:

Кликните по LAN3 и откроется выпадающее меню, с помощью которого, вы можете сразу перейти к карте LAN3.

На сегодня всё. Мы создали карту общую карту ЛВС.

Заключение

Сегодня мы рассмотрели создание простейшей карты сети для мониторинга находящихся в её составе устройств.

Были созданы правила обнаружения (Discovery) для всех подсетей нашей виртуальной ЛВС.

Мы создали правила действий (Actions) чтобы добавить обнаруженные хосты в базу данных хостов и привязать их к шаблону ICMP Ping

Так же мы создали карты для каждой из подсетей и общую карту, на которой свели вместе наши подсети и маршрутизаторы.

В следующей части мы рассмотрим мониторинг маршрутизаторов Mikrotik через SNMP.

Читайте также: