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;
- Чтобы получить загрузку интерфейса за промежуток времени - нужно из конечного значения счётчика октетов вычесть начальное и разделить на промежуток времени.
Следующая важная вещь:
- Счётчик октетов имеет конечное значение 232 и при переполнении сначала обнуляется, потом начинает заполняться снова. Если это не учесть, то при обнулении значения счётчика будет разово выведена неверная величина загрузки интерфейса. Учтено это или нет в 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.
