В этой статье речь пойдет про мониторинг оборудования 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, как только смогу войти в аккаунт на этой площадке.
