Zabbix SNMP — после того, как настройка SNMP на сетевом устройстве CISCO изучена, пора применить этот опыт на практике. Предварительные данные были приведены в записи Настройка SNMP.

Предисловие

Производить мониторинг SNMP нужно в какой-то специализированной сетевой среде. На текущий момент без сомнения самой популярной системой для мониторинга является Zabbix.

Есть и другие, например OpenView от HP, NOC Project так далее, почему именно Zabbix? Причин много - простота установки и настройки, хорошая документация на русском и английском языках, свободно распространяемое ПО, назначение - в первую очередь это именно система мониторинга, а не хелп-деск или какое-то другое многофункциональное ПО со встроенной системой мониторинга "в нагрузку" или же в виде отдельного модуля. Мониторинг сетевых устройств - основной профиль для Zabbix.

Для мониторинга будем использовать маршрутизатор CISCO c3725 в среде GNS3, связанный через Облако GNS3 с виртуальной машиной (VM) Hyper-V, на которой запущен Zabbix:

• IP маршрутизатора F0/0 192.168.137.2/24;
• IP VM 192.168.137.40/24.

Настройка маршрутизатора

Для простоты будем настраивать SNMP версии 2c:

R1(config)#interface F0/0
R1(config-if)#ip address 192.168.137.2 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#ip access-list standard SNMP_ACL
R1(config-std-nacl)#permit 192.168.137.40
R1(config-std-nacl)#exit
R1(config)#snmp-server community TEST rw SNMP_ACL
R1(config)#snmp-server host 192.168.137.40 version 2c TEST

Почему, а как же новая и безопасная версия 3? В теории - это одно, на практике - другое. Не ошибусь, если скажу, что в 90% компаний нет необходимости такого высокого уровня защиты для пакетов SNMP. Из-за этого, а также из-за простоты настройки на практике преимущественное распространение получила версия 2c. Кому интересна именно версия 3 - настройка (безотносительно Zabbix) довольно подробно была рассмотрена в  в записи Настройка SNMP.

Основы Zabbix

Для начала рекомендую посмотреть довольно-таки неплохое обзорное видео по Zabbix (если не обращать внимание на вещи вроде "сэсэха агент" и другие ляпы). Рассматривается уже новый Zabbix 3.0, то есть визуально такой же, какой будет использоваться в данной записи. Смотреть можно здесь. Установку лучше пропустить, так как используем готовое решение и смотреть тогда нужно с ~12.30. Основные моменты и понятия рассказаны.

Установка

Берём Готовое решение Zabbix:

Версия готового решения Zabbix	Версия Ubuntu
3.2.0	14.04.3

Всё преднастроено, а установка в VM занимает 15 минут. Несмотря на то, что это решение построено на Ubuntu 14.04, поддержки виртуальных машин 2 поколения для Hyper-V нет. Не так страшно.

Если что-то не нравится, данную установку всегда можно быстро донастроить на свой вкус. Быстро обновить:

sudo apt-get --only-upgrade install zabbix*

В общем и целом - удобно использовать именно это решение.

Настройка CLI

Прежде чем производить настройку в Веб-интерфейсе нужно потратить какое-то время и найти нужные OIDs для мониторинга.

Подключаемся через SSH к VM, реквизиты входа (напоминаю, что действия от root, если такое действие нужно - выполняем через sudo):

Login - appliance password - zabbix

Первый вариант -  можно использовать те OIDs, которые указаны в документации Zibbix.

Тут нужно также научиться пользоваться очень полезной командой snmpwalk. Команда непосредственно позволяет выбирать OIDs из наблюдаемого сетевого устройства:

appliance@zabbix:~$ snmpwalk -v 2c -c TEST 192.168.137.2 1.3.6.1.2.1.2.2.1.2
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "FastEthernet0/0"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "Serial0/0"
iso.3.6.1.2.1.2.2.1.2.3 = STRING: "FastEthernet0/1"
iso.3.6.1.2.1.2.2.1.2.4 = STRING: "Serial0/1"
iso.3.6.1.2.1.2.2.1.2.6 = STRING: "Null0"

Видно, что последняя цифра OID - это номер интерфейса (понадобится дальше).

Второй вариант - используем snmpwalk, а также значения, по которым можно делать отбор:

Третий вариант - можно скопировать весь вывод команды snmpwalk:

appliance@zabbix:~$ snmpwalk -v 2c -c TEST 192.168.137.2 > snmpOIDs

То есть копируем все OIDs со своими последними значениями в файл, забираем его через WinSCP и потом изучаем, допустим, в Notepad++.

Четвёртый вариант - использовать специальное ПО для чтения OIDs с устройства, например OiDViEW (есть бесплатная версия: //www.oidview.com/oidview.html ).

Наверняка есть ещё варианты, рассказал о том, что знаю и использую сам.

Изучение MIBs

Таким образом можно посмотреть какие MIBs применяются в устройстве, затем поискать информацию что это за MIBs. Если, допустим, хотим работать с интерфейсами, то сначала прям в файле бросается в глаза - IF-MIB, а IF тут понятно - Interfaces. Далее ищем данный MIB через CISCO IOS MIB Locator или же информацию по этому MIB в интернете:
//www.cisco.com/c/en/us/td/docs/switches/wan/mgx/mgx_8850/software/mgx_r2-0-10/pxm/reference/guide/pxm/ifmib.pdf

Внутри pdf-файла есть таблица параметров с подробным описанием каждого из параметров, например:

ifOperStatus

Integer {up (1), ready to pass packets; down (2)..

Indicates the current operational state of the interface..

Внизу описания параметра 2 важных значения:

• Уровень доступа;
• Статус.

Уровень доступа показывает как можно обращаться к данному параметру/разделу, например, для ifTable уровень доступа not-accessible показывает, что обращаться нельзя никак - это только контейнер, для ifOperStatus - можно считывать значение, записывать нельзя, ifAdminStatus - можно и считывать, и записывать.

Статус в большинстве случаев - текущий, то есть именно на момент запроса.

Обратиться из консоли к конкретному параметру можно, к примеру, как IF-MIB::ifOperStatus - текущий статус интерфейса. Ранее было видно, что F0/0 имеет порядковый номер 1 среди интерфейсов, поэтому:

IF-MIB::ifOperStatus.1 - состояние F0/0
IF-MIB::ifDescr.1 - описание F0/0
................
и так далее

Чтобы попутно проверять получаемую информацию по параметрам MIB и получать OIDs в цифровом выражении, есть вторая полезная команда:

•  snmpget - позволяет давать запросы к сетевому устройству, как это делает диспетчер SNMP, тоже прямо из консоли.

Пример.

appliance@zabbix:~$ snmpget -v 2c -c TEST -On 192.168.137.2 IF-MIB::ifOperStatus.1
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: up(1)

appliance@zabbix:~$ snmpget -v 2c -c TEST -On 192.168.137.2 IF-MIB::ifInOctets.1
.1.3.6.1.2.1.2.2.1.10.1 = Counter32: 95352

appliance@zabbix:~$ snmpget -v 2c -c TEST -On 192.168.137.2 IF-MIB::ifOutOctets.1
.1.3.6.1.2.1.2.2.1.16.1 = Counter32: 96170

Ещё раз - на этом этапе и до настройки Веб необходимо получить больше сведений об OIDs, которые будут мониториться - числовое представление для OID, формат вывода значения параметра - числа, текст, целые, дробные и так далее. При настройке Веб все эти данные понадобятся.

Небольшое отступление

Последние 2 параметра ifInOctets и ifOutOctets описываются как: общее число октетов полученных на интерфейсе, включая служебные. Это точное описание. Октет в информатике — восемь двоичных разрядов, то есть байт. Такое же определение дано в документации Zabbix для ifInOctets/ifOutOctets: Полное число полученных байтов, включая символы заголовков:

• Чтобы перевести октеты в биты - их нужно умножить на 8;
• Чтобы получить загрузку интерфейса за промежуток времени - нужно из конечного значения счётчика октетов вычесть начальное и разделить на промежуток времени.

Следующая важная вещь:

• Счётчик октетов имеет конечное значение 2³² и при переполнении сначала обнуляется, потом начинает заполняться снова. Если это не учесть, то при обнулении значения счётчика будет разово выведена неверная величина загрузки интерфейса. Учтено это или нет в Zabbix? Не могу сказать, не знаю, но при составлении собственных скриптов для расчёта, данный момент необходимо учитывать.

Настройка WEB

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

• Создать узел сети. Ввести имя, выбрать или создать группу для узла, в пункте Интерфейсы добавить интерфейс SNMP, ввести IP, интерфейс для агента - удалить:

Галка Use bulk request позволяет запрашивать у устройства несколько SNMP параметров за 1 запрос, для версии 2c это нормальный режим работы, поэтому галку на чекбоксе оставляем.

Зайти в созданный узел и далее на закладку Items и тут нужно будет создать элементы данных - как минимум 1  элемент для SNMP агента и как минимум 1 для ловушек SNMP. На самом деле элементов будет больше.

Элемент данных - это тот параметр, который будем мониторить.

Элементы данных для агента SNMP

Сначала создадим элементы данных для входящей и исходящей загрузки интерфейса F0/0 и сформируем график.

Для элемента входящей загрузки используем следующие параметры:

Name - INT F0/0 In
Type - SNMPv2 agent
Key - ifInOctets.1
Host interface - R1
SNMP OID - 1.3.6.1.2.1.2.2.1.10.1
SNMP community - TEST
Type of information - Numeric (unsigned)
Data type - Decimal
Units - bps
Update interval (in sec) - 30
Use custom multiplier - 8
Store value - Delta (speed per second)

Два последних значения гарантируют формирование правильного графика загрузки интерфейса F0/0 в битах в секунду. Множитель 8 переводит байты в биты, а Delta speed per second (изменение в пересчёте на секунду) -  разница между начальным и конечным значением, делённая на интервал. Проверить очень просто, можно менять как угодно значение Update interval (in sec) при этом показания на графике остаются неизменными.

Другой вариант выбрать следующие параметры:

Update interval (in sec) - 30 
Use custom multiplier - 0,2666.. (=8/30)
Store value - Delta (simple change)

В чём разница? Delta simple change (простое изменение) - конечное значение минус начальное, поэтому "разделить на интервал" нужно заложить в множитель. Множитель вышел 2 целых 6 в периоде - специально взял эти значения чтобы показать, что не всегда этот вариант удобен. А так принципиальной разницы нет. Для определённости используем 1 метод.

Теперь аналогично создадим элемент данных для исходящей загрузки F0/0.

Затем на закладке Graphs для R1 добавляется график с обоими параметрами. График есть, можно смотреть насколько загружен интерфейс.

Теперь создадим запись элемента данных для мониторинга статуса порта S0/0 - это ещё 1 порт на маршрутизаторе, к нему ничего не подключено, его номер равен 2 и OID для статуса это F-MIB::ifOperStatus.2 или .1.3.6.1.2.1.2.2.1.8.2 в числовом выражении:

Name - INT F0/0 Status 
Type - SNMPv2 agent 
Key - ifOperStatus.2
Host interface - R1 
SNMP OID - 1.3.6.1.2.1.2.2.1.8.2 
SNMP community - TEST 
Port - 161
Type of information - Numeric (unsigned) 
Data type - Decimal

Ещё полезные OIDs:

• .1.3.6.1.4.1.9.2.1.56.0 - средняя загрузка CPU за 5 секунд;
• .1.3.6.1.4.1.9.2.1.57.0 - средняя загрузка CPU за 60 секунд;
• .1.3.6.1.4.1.9.2.1.58.0 - средняя загрузка CPU за 5 минут;
• .1.3.6.1.4.1.9.2.1.8.0 - объём свободной памяти.

Триггер

На основе созданной записи для S0/0 на закладке Triggers для узла R1 теперь можно создать триггер, который будет обрабатывать изменения в состоянии интерфейса S0/0. Можно задать множество условий и даже комбинаций из условий, возьму одно из самых простых выражений:

Name - INT F0/0 Failed
Severity - High
Expression - {R1:ifOperStatus.2.avg(30)}<>1

Тут 1 - (как было показано выше) цифровое выражение статуса Up для интерфейса и триггер мониторит среднее значение для статуса интерфейса за 30 секунд, если оно не 1, тогда условие срабатывает.

Полностью триггер:

Проходит 30 секунд, проверяем что триггер сработал.

Теперь добавляем в GNS3 ещё 1 маршрутизатор, соединяем его интерфейс S0/0 c интерфейсом S0/0 R1, включаем эти интерфейсы на обоих маршрутизаторах и ждём 30 секунд.

Элемент данных для ловушек SNMP

Если не брать готовое решение Zabbix, то много чего нужно настраивать дополнительно. В случае готового решения уже всё настроено, необходимо лишь завести саму запись элемента данных для ловушек. Идём снова на закладку Items для R1:

Name - SNMP:Trap
Type - SNMP trap
Key - snmptrap.fallback
Host interface - 192.168.137.2:161
Type of information - Log

Теперь на R1 поднимаем интерфейс S0/1, к нему ничего не подключено и смотрим события в Monitoring - Latest Data, сделав отбор по нашему устройству или по группе:

Тут собственно видно, что графики в общем-то формируются автоматически - для статуса F0/0 график не создавался - и доступны из этого меню, но для удобства и более точной настройки лучше создавать графики вручную.

Нажимаем кнопку History для более детального просмотра пришедших ловушек:

На что тут надо обратить внимание:

• Неверное задание 1 из параметров нарушает работу всего создаваемого объекта;
• Отдельно про параметр Ключ (Key) - где-то ключ задаётся произвольно и его функция только в дополнительном описании создаваемого объекта, а где-то верное задание ключа - необходимо для правильной работы.

Работа с большим числом узлов

Все элементы данных (Items) и график (Graphs) создавались непосредственно в узле R1. А что делать, когда узлов десятки? Тогда нужно в начале создать вначале шаблон/шаблоны, далее внутри шаблона создать элементы данных и графики, а затем уже шаблон применять к узлам. Это избавит от рутинной работы по добавлению одних и тех же настроек в узлы.

Чтобы не добавлять узлы вручную, можно воспользоваться закладкой Configuration - Discovery, создав там элементы для автоматического поиска узлов по заданным критериям.

На этом с SNMP в Zabbix всё - простая, базовая настройка рассмотрена.

Дополнение от 16.03.2018

Zabbix 3.4 уже довольно давно вышел и на момент хорошо отлажен. В нём есть готовые, очень хорошие шаблоны для сетевого оборудования (CISCO, Qtech, прочее). Соответственно про версию 3.2 и тем более ниже - нужно забыть и использовать только 3.4.