Продолжая тему мониторинга сетевых устройств по протоколу SNMP в Icinga на примере модулей управления источников бесперебойного питания (ИБП), можно в очередной раз отметить тот факт, что рассмотренная ранее схема с использованием плагина check_snmp дает нам лишь базовые возможности обработки получаемых по SNMP данных. Когда описанным базовым методом мы начали мониторить входное напряжение ИБП разных производителей и разных моделей, со временем пришли к выводу, что использование статически заданных границ (верхней и нижней) для входного напряжения – не очень приемлемый вариант. Проблема заключалась в том, что даже в рамках одной марки ИБП в нашем окружении присутствует множество разных моделей, каждая из которых имеет свои допустимые рабочие диапазоны входного напряжения. При этом на некоторых моделях ИБП эти диапазоны могут регулироваться администратором, как в сторону сужения, так и в сторону расширения.
-
Icinga плагин check_snmp_value_from_range для отслеживания вхождения значения в допустимый диапазон значений, извлекаемых по протоколу SNMP (на примере мониторинга входного напряжения ИБП)
-
Icinga плагин check_snmp_apc_ups_state для расширенного отслеживания аварийных состояний ИБП APC по данным, полученным по протоколу SNMP из параметра upsBasicStateOutputState
Ранее мы рассматривали пример настройки мониторинга контроллеров управления источников бесперебойного питания (ИБП) марки APC в Icinga с использованием протокола SNMP. При этом мы использовали плагин check_snmp, который использовался для создания каждой отдельной службы Icinga, использующей простую логику сравнения полученного по SNMP показателя с неким допустимым значением. Однако такой подход позволяет отслеживать не все состояния ИБП, которые можно отнести к нештатным и требующим внимания администратора. -
Icinga плагин snmp_vars_discovery для инвентаризации расширенного набора свойств Хостов по данным, полученным по SNMP (для использования с Icinga Director)
После базовой настройки мониторинга сетевых устройств (Хостов) по протоколу SNMP в Icinga Director, может возникнуть желание как-то расширить объём информации, хранящейся в Icinga об этих самых Хостах. Например, у тех же модулей управления ИБП в интерфейсе Icinga Web 2 хочется видеть серийные номера устройств, версии прошивок firmware и т.п.. Учитывая то, что в нашем случае в Icinga уже есть базовая информация, необходимая для того, чтобы подключаться к Хостам по протоколу SNMP, возникла идея как-то автоматизировать процесс сбора дополнительных данных о Хосте, используя этот самый протокол SNMP. -
Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 13.2. Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Получение SNMP Trap
В данной части цикла заметок об Icinga мы продолжим тему мониторинга сетевых устройств по протоколу SNMP и рассмотрим пошаговый пример настройки ловушки SNMP Trap в конфигурации Icinga Director. Сразу хочу отметить тот факт, что в Icinga нет встроенных механизмов получения и обработки SNMP Trap. Поэтому, для того, чтобы реализовать нужный нам функционал, нам потребуется настроить стек состоящий из ряда элементов:- snmptrapd – Служба SNMP Trap Daemon из состава Net-SNMP. Данная служба отвечает за прослушивание на сервере мониторинга UDP-порта и получение от внешних сетевых устройств сообщений SNMP Trap
- snmptt – Служба SNMP Trap Translator (SNMPTT). Данный элемент отвечает за разбор и интерпретацию сообщений SNMP Trap, полученных от службы snmptrapd. В частности он преобразует числовые идентификаторы OID в читаемый формат, используя подключаемые MIB-файлы.
- submit_snmp_trap – Скрипт, который принимает от службы snmptt нормализованное Trap-сообщение и, преобразовав данные этого сообщения в понятный для Icinga формат, отправляет их в командный pipe-файл Icinga.
- "SNMP Trap" - специальная пассивная Служба Icinga, в которую будут "прилетать" данные из pipe-файла Icinga. Данная Служба будет служить нам для визуализации конечного результата в веб-интерфейсе Icinga Web 2, а также организации оповещений администратора о проблеме.
