Zabbix SNMP — после того, как настройка SNMP на сетевом устройстве CISCO изучена, пора применить этот опыт на практике. Предварительные данные были приведены в записи Настройка SNMP.
По миру шагает уже Zabbix 5.4, а эта статья про версию 3.2 безнадёжно устарела. Переписывать её не буду, это неблагодарный труд, версия ПО всё время растёт и значит всё время нужно вносить правки. Такой возможности нет. Чуть отрихтовал для удобства чтения. Оставляю, возможно кому-то пригодится в том виде как есть.
Предисловие
Производить мониторинг 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
Почему, а как же новая и безопасная версия 3? В теории это одно, на практике другое. Не ошибусь, если скажу, что в 90% компаний нет необходимости такого высокого уровня защиты для пакетов SNMP. Из-за этого, а также из-за простоты настройки на практике преимущественное распространение получила версия 2c. Кому интересна именно версия 3, настройка (безотносительно Zabbix) довольно подробно была рассмотрена в записи Настройка SNMP.
Это настройка без ловушек SNMP, их настройку можно посмотреть в той же статье. А тут вот так кратко.
Основы Zabbix
Для начала рекомендую посмотреть довольно-таки неплохое обзорное видео по Zabbix (если не обращать внимание на вещи вроде "сэсэха агент" и другие ляпы). Рассматривается уже новый Zabbix 3.0, то есть визуально такой же, какой будет использоваться в данной записи. Смотреть можно здесь. Установку лучше пропустить, так как используем готовое решение и смотреть тогда нужно с ~12.30. Основные моменты и понятия рассказаны.
Установка
Подробно рассказана на странице проекта. Быстро обновить:
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.
Пример таблицы параметров с подробным описанием каждого из параметров:
| 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;
- Чтобы получить загрузку интерфейса за промежуток времени, нужно из конечного значения счётчика октетов вычесть начальное и разделить на промежуток времени.
Следующая важная вещь:
- Счётчик октетов имеет конечное значение 232 и при переполнении сначала обнуляется, потом начинает заполняться снова. Если это не учесть, то при обнулении значения счётчика будет разово выведена неверная величина загрузки интерфейса. Учтено это или нет в Zabbix? Не могу сказать, не знаю, но при составлении собственных скриптов для расчёта, данный момент необходимо учитывать.
Настройка WEB
Настройка Веб состоит из нескольких несложных шагов, всё подробно рассказано на странице проекта. Нужно потратить время и хорошо изучить данное описание. Моя адаптация:
- Создать узел сети. Ввести имя, выбрать или создать группу для узла, в пункте Интерфейсы добавить интерфейс SNMP, ввести IP, интерфейс для агента — Remove:
Галка 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 3.2, то много чего нужно настраивать дополнительно. В случае готового решения уже всё настроено, необходимо лишь завести саму запись элемента данных для ловушек. Идём снова на закладку 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.