Icinga плагин snmp_vars_discovery для инвентаризации расширенного набора свойств Хостов по данным, полученным по SNMP (для использования с Icinga Director)

После базовой настройки мониторинга сетевых устройств (Хостов) по протоколу SNMP в Icinga Director, может возникнуть желание как-то расширить объём информации, хранящейся в Icinga об этих самых Хостах. Например, у тех же модулей управления ИБП в интерфейсе Icinga Web 2 хочется видеть серийные номера устройств, версии прошивок firmware и т.п.. Учитывая то, что в нашем случае в Icinga уже есть базовая информация, необходимая для того, чтобы подключаться к Хостам по протоколу SNMP, возникла идея как-то автоматизировать процесс сбора дополнительных данных о Хосте, используя этот самый протокол SNMP.

После некоторых экспериментов в этой области получился Icinga плагин snmp_vars_discovery, который, используя возможности управления конфигурацией сервера Icinga с помощью команды "icingacli director" (доступна при развёрнутом Icinga Director), заполняет в Icinga все заведомо определённые дополнительные свойства Хостов, предварительно получив их по протоколу SNMP.

***

Общий порядок внедрения данного плагина в Icinga Director предполагается такой:

  • Создаём дополнительные Поля Данных (Data Field) для хранения интересующей нас дополнительной информации о Хостах для разных типов оборудования.
  • Создаём Шаблоны Хостов для разных типов оборудования и привязываем к ним созданные ранее Поля Данных.
  • Создаём на основе плагина snmp_vars_discovery Команду с типом Plugin Check Command.
  • На основе Команды создаём Шаблон Службы и назначаем его на Хосты, имеющие заполненные свойства для мониторинга SNMP.

В конечном итоге, назначенная Служба будет на периодической основе опрашивать Хост по протоколу SNMP и заполнять дополнительные расширенные свойства Хоста в Icinga.

Далее по порядку мы рассмотрим все этапы внедрения.


Устанавливаем плагин

Скачать текущую версию плагина можно с GitHub.

С точки зрения параметров вызова, плагин snmp_vars_discovery работает по аналогии с ранее рассмотренным плагином check_snmp, но, наряду с утилитой snmpget, использует для своей работы утилиту icingacli. Информацию о допустимых параметрах вызова плагина можно получить во встроенной справке:

$ /usr/lib/nagios/plugins/snmp_vars_discovery.sh --help

Icinga Plugin Check Command for pull Icinga Host variables (from SNMP data), version 2017.05.24

Usage: ./snmp_vars_discovery.sh [OPTIONS]

Option  GNU long option   Meaning
------  ---------------   -------
 -H     --hostname        Host name (Icinga object Host.name)
 -h     --hostaddr        Host address (Icinga object Host.address)
 -P     --protocol        SNMP protocol version. Possible values: 1|2c|3
 -C     --community       SNMPv1/2c community string for SNMP communication (for example,public)
 -L     --seclevel        SNMPv3 securityLevel. Possible values: noAuthNoPriv|authNoPriv|authPriv
 -a     --authproto       SNMPv3 auth proto. Possible values: MD5|SHA
 -x     --privproto       SNMPv3 priv proto. Possible values: DES|AES
 -U     --secname         SNMPv3 username
 -A     --authpassword    SNMPv3 authentication password
 -X     --privpasswd      SNMPv3 privacy password
 -q     --help            Show this message
 -v     --version         Print version information and exit

Usage examples.
For SNMPv1:
./snmp_vars_discovery.sh -H netdev10.holding.com -h 10.10.10.10 -P 1 -C public
For SNMPv3:
./snmp_vars_discovery.sh -H netdev10.holding.com -h 10.10.10.10 -P 3 -L authPriv -U icinga -a MD5 -A myAuthPwD -x DES -X myPrivPwd

Копируем скрипт snmp_vars_discovery.sh в каталог с плагинами Icinga (в Debian это /usr/lib/nagios/plugins/) и делаем его исполняемым:

# chmod +x /usr/lib/nagios/plugins/snmp_vars_discovery.sh

Чтобы избежать проблемы, описанной в icingaweb2-module-director issue 952, необходимо удостовериться в том, что пользователь, от имени которого работает процесс icinga2 (в конфигурации по умолчанию в Debian это пользователь с именем nagios) имеет доступ к каталогу /etc/icingaweb2. А на данный каталог в конфигурации по умолчанию в Debian установлены права доступа для группы icingaweb2. Посмотрим в какие группы входит пользователь nagios:

# id nagios

uid=109(nagios) gid=114(nagios) groups=114(nagios)

Как видим, членства в группе icingaweb2 нет. Добавим его:

# usermod -a -G icingaweb2 nagios
# id nagios

uid=109(nagios) gid=114(nagios) groups=114(nagios),117(icingaweb2)

Для вступления изменений в силу перезагрузим службу icinga2

# systemctl restart icinga2.service

После этого переходим к интеграции плагина в Icinga Director.


Создаём дополнительные Поля Данных (Data Field)

В Icinga Director нам потребуется создать столько дополнительных Полей Данных (Data Field), сколько нужно для хранения дополнительный свойств Хостов. Имена Полей Данных должны соответствовать тем, что используются в качестве переменных в скрипте snmp_vars_discovery.sh. Я предпочитаю присваивать имена Полей Данных по принципу snmp_<Имя MIB>_<Имя параметра из MIB>, о чём писал ранее. Например, общие для всех SNMP-агентов Поля Данных будут начинаться с префикса snmp_SNMPv2_MIB

А, например, конкретно для устройств APC Поля Данных будут иметь префикс snmp_PowerNet_MIB

Все Поля Данных, которые поддерживаются плагином на данный момент можно посмотреть в самом теле скрипта snmp_vars_discovery.sh.

После того, как все Поля Данных описаны, нам нужно привязать эти Поля к конечным Хостам. Проще всего сделать это посредствам создания Шаблонов Хостов для разных типов оборудования с последующей привязкой соответствующих Полей к этим Шаблонам Хостов.


Создаём Шаблоны Хостов для разных типов оборудования

Воспользуемся созданными в ранее рассматриваемом примере Шаблонами Хостов - "SNMP Host" (предполагается использовать для всех сетевых устройств) и "APC UPS Device" (предполагается использовать для контроллеров управления ИБП определённого вендора).

В свойствах Шаблона Хостов "SNMP Host" на закладке Fields выполним привязку созданных на прошлом этапе Полей Данных (Data Field), которые можно отнести к любым Хостам, которые опрашиваются по протоколу SNMP (например Поля, начинающиеся с префикса snmp_SNMPv2_MIB)

А, например, в свойствах Шаблона Хостов "APC UPS Device" закладке Fields выполним привязку созданных на прошлом этапе Полей Данных, которые имеют отношение только к соответствующему конкретному вендору и типу оборудования – ИБП фирмы APC. В нашем примере это Поля Данных, начинающиеся с префикса snmp_PowerNet_MIB.

Аналогичным образом мы выполняем привязку всех необходимых нам дополнительных Полей Данных к Шаблонам Хостов. Предполагается, что Шаблоны Хостов в свою очередь уже назначены каким-либо образом на наши Хосты в конфигурации Icinga.


Создаём Команду "snmp-vars-discovery"

Создадим в Icinga Director новую Команду, которая будет использовать ранее добавленный на наш сервер icinga плагин snmp_vars_discovery. Присвоим этой команде любое удобное нам имя, например, "snmp-vars-discovery".

После создания Команды, нам необходимо описать список Аргументов, которые должны передаваться вызываемому из Команды плагину snmp_vars_discovery. То есть фактически список Аргументов является ни чем иным, как набором опций, которые умеет принимать конечный плагин snmp_vars_discovery. В качестве значений аргументов используются переменные, которые были созданы в прошлом примере. То есть, при вызове этой Команды передаются данные, полученные из свойств Хоста, для которого будет вызываться Команда (snmp_version, snmp_community, snmpv3_authprot и т.п.):

В конечном итоге, в свойствах созданной Команды "snmp-vars-discovery" на закладке Preview в нашем случае отображается следующая результирующая конфигурация, которая попадёт в конфигурацию Icinga Director при очередном развёртывании:

object CheckCommand "snmp-vars-discovery" {
    import "plugin-check-command"
    command = [ PluginDir + "/snmp_vars_discovery.sh" ]
    arguments += {
        "--authpassword" = "$snmpv3_authpwd$"
        "--authproto" = "$snmpv3_authprot$"
        "--community" = "$snmp_community$"
        "--hostaddr" = "$address$"
        "--hostname" = {
            required = true
            value = "$host.name$"
        }
        "--privpasswd" = "$snmpv3_privpwd$"
        "--privproto" = "$snmpv3_privprot$"
        "--protocol" = {
            required = true
            value = "$snmp_version$"
        }
        "--seclevel" = "$snmpv3_seclevel$"
        "--secname" = "$snmpv3_user$"
    }
}

Создаём Шаблон Службы "SNMP Discovery"

Теперь на основе созданной нами на предыдущем этапе Команды "snmp-vars-discovery" в меню Services на закладке Templates создаём Шаблон Службы, например с именем "SNMP Discovery". Определяем параметры Шаблона Службы таким образом, что данная Служба будет по сути выполнять активные проверки (active check) на стороне сервера Icinga с каким-то, приемлемым для нас интервалом времени (Check interval). Учитывая то, что в большинстве случаев данные о конфигурации сетевых устройств, получаемые нами по SNMP, изменяются редко, резонно будет настроить большой интервал между проверками, например раз в 7 дней (604800 секунд).

В конечном итоге, в свойствах созданного Шаблона "SNMP Discovery" на закладке Preview в нашем случае отображается следующая результирующая конфигурация, которая попадёт в конфигурацию Icinga Director при очередном развёртывании:

template Service "SNMP Discovery" {
    check_command = "snmp-vars-discovery"
    max_check_attempts = "1"
    check_period = "Always"
    check_interval = 7d
    enable_notifications = false
    enable_active_checks = true
    enable_passive_checks = false
    enable_event_handler = false
    enable_perfdata = false
    volatile = false
}

Назначаем Шаблон Службы "SNMP Discovery" на Хосты

Созданный Шаблон Службы "SNMP Discovery" нужно привязать в Icinga к интересующим нас Хостам (сетевым устройствам, добавленным в Icinga в качестве объектов мониторинга). Сделать это можно разными способами.

Например, с привязкой к созданному Шаблону Службы "SNMP Discovery" можно создать правило Apply-Rule, которое породит создание Службы "SNMP Discovery" для Хостов по заданным нами условиям, - например, по по членству в Группах Хостов, которые мы создавали в прошлом примере:

Другой вариант назначения Шаблона Службы "SNMP Discovery" на конечные Хосты – привязать Службу в явном виде к любому из уже используемых Шаблонов Хостов, например к ранее созданному Шаблону "SNMP Host", по аналогии с тем, как мы уже привязывали ранее к нему Шаблон Службы "SNMP Trap".

А уже Шаблон Хостов "SNMP Host" подразумевается привязать к самим Хостам.

В не зависимости от способа привязки созданного нами Шаблона Службы "SNMP Discovery" к конечным Хостам результат должен быть одинаковым. А именно, в перечне Служб интересующих нас Хостов должна появиться новая Служба с именем "SNMP Discovery".


Проверяем результат

Первичную инициализацию Службы "SNMP Discovery" для любого из Хостов мы можем выполнить в свойствах этой Службы, щелкнув по ссылке Check now

Служба перейдёт в состояние ОК и в случае, если ранее для этого Хоста данная Служба ни разу не выполнялась, в разделе Plugin Output мы увидим информацию о том, что развёрнута новая конфигурация Icinga Director. То есть в данный момент плагин snmp_vars_discovery опросил наш Хост и записал в его свойства, данные полученные с сетевого устройства по протоколу SNMP, после чего произошло автоматическое развёртывание обновлённой конфигурации Icinga Director.

В результате, на странице свойств Хоста в разделе Custom Variables мы увидим информацию о его конфигурации, полученную по протоколу SNMP:

Следующая активная проверка Службы "SNMP Discovery" для данного Хоста будет произведена автоматически через 7 дней (согласно наших настроек в свойствах Шаблона Службы) и в случае, если с сетевого устройства будут получены новые данные, также в автоматическом режиме они будут записаны в конфигурацию Icinga Director с последующим её развёртыванием. В случае же если изменений не будет найдено, то конфигурация Icinga Director останется без изменений, а вывод работы плагина будет соответствующий:

Преимуществом в такой модели автоматического получения по SNMP данных с последующим обновлением конфигурации Icinga Director является то, что фактически любой оператор веб-консоли Icinga Web 2, имеющий право вызывать активную проверку по ссылке Check now, может самостоятельно через веб-интерфейс заставить Icinga освежить данные о сетевом устройстве в любой нужный для оператора момент времени, не дожидаясь очередного срабатывания активной проверки по расписанию, которое установлено в Шаблоне Службы "SNMP Discovery".


На данный момент плагин snmp_vars_discovery имеет поддержку тех сетевых устройств, с которыми я успел поработать в Icinga (контроллеры управления ИБП APC, Eaton, HP и коммутаторы Digi), и я буду его расширять в дальнейшем информацией о SNMP OID других производителей и типов сетевого оборудования по мере моих скромных возможностей.

Всего комментариев: 4 Комментировать

  1. Роман Кулакович /

    Какова вероятность появления устройств Mikrotik, Kyocera?

  2. Алексей Максимов / Автор записи

    Роман, в моём "колхозе" такая вероятность крайне мала. Если испытываете нужду, могу добавить желаемые данные в скрипт. От Вас потребуется только информация по связке данных в виде таблички с колонками:
    Идентификатор OID, Имя MIB-файла, Имя переменной в MIB-файле.

    1. Роман Кулакович /

      Я наверное сам под себя поправлю, просто интересовался. Вдруг оно само как нибудь :)

  3. Алексей Максимов / Автор записи

    Выложена переработанная версия скрипта: snmp_vars_discovery

    * Несколько оптимизирован код, исправлены выявленные ошибки
    * Добавлена поддержка инвентаризации некоторых моделей коммутаторов Cisco

    Тестировалось на Debian GNU/Linux 9.11 (stretch) с Icinga r2.11.1-1 / Director 1.7.1 / NET-SNMP 5.7.3

Добавить комментарий