В этой статье речь пойдет про мониторинг оборудования Eltex по протоколу SNMPv3 в Zabbix. Ранее мы рассматривали устройство протокола SNMPv3, теперь же сосредоточимся на прикладной задаче по мониторингу коммутаторов и маршрутизаторов.

Особенность оборудования Eltex состоит в том, что разные его серии имеют различные наборы команд для настройки SNMPv3, поэтому приходится держать под рукой несколько шаблонов конфигураций. Благо, документация проиндексирована и легко находится - и для маршрутизаторов, и для коммутаторов.

Например, для маршрутизаторов серии ESR, конфигурация выглядит следующим образом:

snmp-server

snmp-server user snmpv3vianame

access ro

authentication algorithm sha1

authentication access priv

authentication key ascii-text authv3sha

privacy algorithm aes128

privacy key ascii-text privv3aes

enable

exit

А для коммутаторов серии MES 23XX немного иначе:

snmp-server server

snmp-server engineID local default

snmp-server group snmpv3group v3 auth

snmp-server group snmpv3group v3 priv

snmp-server user snmpv3user snmpv3group v3 auth sha authv3sha priv-protocol aes-128-cfb priv privv3aes

После настройки проверим работоспособность протокола в консоли сервера мониторинга (пакеты snmp и snmp-mibs-downloader должны быть установлены):

snmpwalk -v 3 -u snmpv3user -l authPriv -A authv3sha -a sha -x aes -X privv3aes 192.168.1.1 1.3.6

Интерфейс Zabbix 5.0 предполагает настройку параметров SNMPv3 в момент создания узла сети. Для масштабируемости задействуем пользовательские макросы:

Пора наполнять шаблоны. Для обнаружения и фильтрации сетевых интерфейсов я применяю устоявшийся метод, подходящий большинству сетевых устройств разных производителей, более-менее одинаково реализующих ветку IF-MIB в дереве OID-объектов. Моё выражение для LLD (Low Level Discovery – низкоуровневого обнаружения) выглядит следующим образом (в дистрибутивы GNU/Linux файл IF-MIB встроен изначально, поэтому можно обращаться к OID интерфейсов по их именам без импорта MIB-файлов):

discovery[{#IFDESCR},IF-MIB::ifDescr,{#IFALIAS},IF-MIB::ifAlias,{#IFADMINSTATUS},IF-MIB::ifAdminStatus]

Такое выражение позволяет гибко фильтровать нежелательные интерфейсы:

При обнаружении будут отфильтрованы следующие интерфейсы:

* выключенные с помощью команды shutdown (adminstatus<>1) – по фильтру #IFADMINSTATUS;

* не имеющие текстового описания – по #IFALIAS;

* имеющие в текстовом описании символ * – по #IFALIAS;

* являющиеся служебными или техническими – по #IFDESCR.

Такой подход к фильтрации освобождает систему мониторинга от сбора ненужных данных и избавляет её администраторов от анализа статистики интерфейсов, не представляющих интереса.

Наполнение LLD стандартно:

Устройства обычно учитывают объемы сетевого трафика в байтах. Чтобы получать значения в битах, необходимо использовать предобработку «Пользовательский множитель» для умножения получаемых значений на 8. Предобработка «Изменение в секунду» позволяет высчитывать дельту трафика за единицу времени, чтобы в итоге получить кривую трафика за условную единицу времени, равную частоте опроса:

Мой вариант LLD содержит 5 прототипов элементов данных:

Скорость и статус необходимы для корректного формирования прототипов триггеров:

Ну и, конечно же, визуализация трафика для каждого обнаруженного интерфейса:

С наполнением шаблонов не возникает проблем благодаря наличию документации на маршрутизаторы ESR и коммутаторы MES23xx. Для простоты и независимости от MIB-файлов я использую цифровые OID.

Для маршрутизатора подобраны базовые метрики, всё остальное можно добавить по своему усмотрению:

Для коммутатора всё аналогично:

Есть тонкость с отображением времени работы (Timeticks должен иметь предобработку «Пользовательский множитель» 0.01, потому что сетевое оборудование измеряет свой uptime в сотых долях секунд). Кроме того, поскольку у рассматриваемых устройств нет OID, содержащего точное название модели устройства, приходится извлекать нужное значение из описательного OID 1.3.6.1.2.1.1.0 с помощью предобработки «Регулярное выражение». Это ведет к тому, что для каждой модели серии MES23XX придется создавать свой шаблон и настраивать элемент данных Model. Этот вариант мне кажется более гибким, чем если бы пришлось задействовать текстовые поля в конфигурации SNMP каждого обслуживаемого устройства:

В триггерах, помимо простых реакций, стоит заложить оповещение об отсутствии отклика по SNMP при наличии отклика по ICMP. Это частая ситуация, например, при задвоении IP-адресов, отсутствии корректных настроек SNMP на устройстве, блокировке трафика межсетевыми экранами и т. д.:

Последнее, на что нужно обратить внимание, - сбор инвентарных данных. Zabbix не самый подходящий продукт для учета оборудования, однако если включать сбор инвентарных данных в узлах сети, он и в этом окажется полезным:

Готовые шаблоны для ESR-21 и MES23XX, созданные в Zabbix 5.2, можно легко адаптировать под свои устройства и специфику задач.

P.S.: Шаблоны размещу на share.zabbix.com, как только смогу войти в аккаунт на этой площадке.

Мониторинг оборудования Eltex по протоколу SNMPv3