Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 13.1. Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Опрос по протоколу SNMP

В данной части цикла заметок об Icinga будет рассмотрен пример настройки мониторинга сетевых устройств с использованием периодических опросов по протоколу SNMP. В качестве опрашиваемых по SNMP сетевых устройств будут использованы контроллеры управления источниками бесперебойного питания (ИБП) фирм EATON и APC. Эти два типа устройств выбраны для того, чтобы продемонстрировать как возможности опроса по протоколу SNMPv1, так и возможности опроса по расширенному протоколу SNMPv3 с использованием дополнительных средств аутентификации. На стороне сервера мониторинга основная настройка будет производиться в веб-интерфейсе Icinga Director 1.3.1.

Подготовка сетевых устройств

Начнём с настройки контроллеров управления ИБП.

В нашем примере используется ИБП EATON Powerware 9125 6kVA c контроллером управления X-Slot ConnectUPS Web/SNMP Card с прошивкой firmware v4.38. Это последняя версия firmware, доступная на данный момент на сайте производителя.

Большинство сетевых устройств с поддержкой протокола SNMP имеют возможность настройки списка контроля доступа, который позволяет ограничить доступ к устройству по протоколу SNMP.

Текущая версия прошивки, имеющегося у нас контроллера EATON, имеет веб-интерфейс, но в нём нет настроек ограничения доступа для опроса по протоколу SNMP. Эти настройки доступны только при подключении к контроллеру через Telnet/SSH.

Подключимся  к контроллеру через Telnet/SSH и выберем в основном меню пункт 1. Web/SNMP Card Settings

В меню нижнего уровня выберем пункт 3. Set Write Access Managers

Откроется таблица доступа, где с помощью команды 1. Modify – Modify a table entry перейдём в режим редактирования записей таблицы. Выберем номер, записи в таблице, например 1, после чего введём данные этой записи, а именно IP-адрес нашего сервера Icinga, с которого планируется выполнять SNMP-опросы, и сроку подключения SNMPv1 (Community String). По умолчанию нам предлагается использовать строку подключения public, но мы изменим эту строку на собственную, например myR0Secret. Тип доступа выберем 1. Read Only, так как этого типа доступа нам вполне достаточно.

После этого вернёмся в главное меню и выберем пункт отключения.

***

Следующим настроим ИБП APC Smart-UPS 5000 RM с контроллером управления UPS Network Management Card AP9617. На устройстве используется последняя актуальная для данного типа контроллера версия firmware - Application Module "sumx" v3.7.2/APC OS "aos" v3.7.3. Эта версия поддерживает протокол SNMPv3, в котором можно использовать дополнительную аутентификацию.

В данном случае все необходимые нам настройки SNMP можно произвести через веб-интерфейс контроллера. В веб-интерфейсе перейдём в Administration > Network > SNMPv3 > access и включим опцию Enable SNMPv3 access. Обратите внимание на то, что включение/выключение протоколов SNMPv1/SNMPv3 в текущей версии firmware требует перезагрузки контроллера, которая выполняется контроллером автоматически после выхода из веб-интерфейса - Log Off (в правом верхнем углу).

После включения поддержки SNMPv3 переходим в user profiles и создаём профиль с учётными данными, от имени которых мы будем подключаться к данному устройству по протоколу SNMPv3. Здесь нужно задать имя пользователя, например icinga, и два пароля – Authentication Passphrase (используется в паре с именем пользователя для аутентификации) и Privacy Passphrase (используется для шифрования передаваемых данных). Обратите внимание на то, что два данных пароля должны содержать от 15 до 32 ASCII символов, о чём написано в APC FAQ – FA156125. Протоколы аутентификации и шифрования для наглядности выберем максимально доступные – MD5 и DES соответственно.

Затем нам остаётся только перейти в меню access control и, выбрав только что созданный профиль подключения, указать IP адрес, с которого будет производиться подключение, то есть IP адрес нашего сервера Icinga.

Сохраняем изменения и выполняем Log Off (в правом верхнем углу), после чего контроллер может стать недоступен на некоторое время (будет перезагружаться), если протокол SNMP не был включён ранее.

Итак, сетевые устройства, которые мы планируем опрашивать по протоколам SNMPv1 и SNMPv3 настроены. Теперь переходим к настройке нашего сервера мониторинга.

 

Подготовка сервера Icinga к работе с протоколом SNMP

Переходим в консоль сервера Icinga и выполняем установку пакета поддержки протокола SNMP:

# apt-get install snmp

При установке данного пакет в системе появятся нужные нам утилиты для опроса по протокол SNMP, например snmpget и snmpwalk. Используя данные утилиты, попробуем опросить два настроенных нами ранее контроллеры управления ИБП по протоколам SNMP v1/v3.

Сначала с помощью утилиты snmpwalk опросим контроллер EATON по протоколу SNMPv1 с использованием ранее заданной строки подключения (Community String) myR0Secret:

$ snmpwalk -v 1 -c myR0Secret KOM-AD01-UP001

iso.3.6.1.2.1.1.1.0 = STRING: "ConnectUPS Web/SNMP Card V4.38"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.534.1
iso.3.6.1.2.1.1.3.0 = Timeticks: (752556289) 87 days, 2:26:02.89
iso.3.6.1.2.1.1.4.0 = STRING: "Artur.Pirozhkov@holding.com"
iso.3.6.1.2.1.1.5.0 = STRING: "KOM-AD01-UP001"
iso.3.6.1.2.1.1.6.0 = STRING: "Komi, Syktyvkar, Carrot Highway 10, Room 840"
iso.3.6.1.2.1.1.7.0 = INTEGER: 72
...

С помощью другой утилиты snmpget попробуем получить отдельное значение по какому-нибудь явно указанному идентификатору Object identifier (OID), например у EATON Powerware текущее входное напряжение в ИБП можно получить по OID 1.3.6.1.4.1.534.1.3.4.1.2.1 (xupsInputVoltage)

$ snmpget -v 1 -c myR0Secret KOM-AD01-UP001 1.3.6.1.4.1.534.1.3.4.1.2.1

iso.3.6.1.4.1.534.1.3.4.1.2.1 = INTEGER: 234

Теперь давайте опросим другой контроллер управления (APC) по протоколу SNMPv3 с использованием аутентификации и шифрования:

$ snmpwalk -v 3 -l authPriv -u icinga -a MD5 -A myAuthenticati0nPassphraZzze -x DES -X myPrivVvacyPas4sphraZze KOM-AD01-UP011

iso.3.6.1.2.1.1.1.0 = STRING: "APC Web/SNMP Management Card (MB:v3.9.2 PF:v3.7.3 PN:apc_hw02_aos_373.bin AF1:v3.7.2 AN1:apc_hw02_sumx_372.bin MN:AP9617 HR:A10 SN: ZA0102003450 MD:02/15/2005) (Embedded PowerNet SNMP Agent SW v2.2 compatible)"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.318.1.3.2.13
iso.3.6.1.2.1.1.3.0 = Timeticks: (1148640) 3:11:26.40
iso.3.6.1.2.1.1.4.0 = STRING: "Artur.Pirozhkov@holding.com"
iso.3.6.1.2.1.1.5.0 = STRING: "KOM-AD01-UP011"
iso.3.6.1.2.1.1.6.0 = STRING: "Komi, Syktyvkar, Beets Plaza 2a, Room 325"
iso.3.6.1.2.1.1.7.0 = INTEGER: 72
...

Здесь можно обратить внимание на разницу в скорости выдачи параметров. В используемом нами примере с SNMPv3 выдача параметров может занять ощутимо больше времени, так как используется шифрование передаваемых данных, а используемый у нас контроллер APC известен тем, что не очень проворно работает с задачами шифрования. Увеличить скорость отдачи параметров можно оставив только аутентификацию SNMPv3 и отказавшись от шифрования, то есть опции -l вместо значения authPriv использовать authNoPriv.

Попробуем по протоколу SNMPv3 получить отдельное значение по какому-нибудь OID, например для APC Smart-UPS текущее входное напряжение в ИБП можно получить по OID 1.3.6.1.4.1.318.1.1.1.3.2.1.0 (upsAdvInputLineVoltage)

$ snmpget -v 3 -l authPriv -u icinga -a MD5 -A myAuthenticati0nPassphraZzze -x DES -X myPrivVvacyPas4sphraZze KOM-AD01-UP011 1.3.6.1.4.1.318.1.1.1.3.2.1.0

iso.3.6.1.4.1.318.1.1.1.3.2.1.0 = Gauge32: 230

Как видим, у инструментов пакета snmp проблем с получением параметров по протоколам SNMPv1/v3 не наблюдается.

***

Теперь давайте проверим то, как будет работать опрос по протоколу SNMP через совместимый с Icinga плагин check_snmp, который мы ранее устанавливали в составе nagios-plugins/monitoring-plugins. Описание плагина можно найти на странице The check_snmp Plugin.

Проверим SNMPv1. При вызове плагина check_snmp вместо коротких одно-символьных опций я буду использовать длинные опции для большей наглядности. Опцией --critical в данном примере обозначается диапазон значений, за рамками которого статус объекта мониторинга Icinga будет меняться на критический. Этот диапазон значений я взял из спецификации по ИБП, и он определяет вольтаж, при котором ИБП работает штатно без переключения на батареи. Опции --units и --label являются чисто косметическими, так как позволяют указать, соответственно, единицы измерения возвращаемого плагином значения и имя, которое будет использоваться вместо OID, например, при сохранении исторических метрик производительности.

$ /usr/lib/nagios/plugins/check_snmp --protocol=1 --community=myR0Secret --hostname=KOM-AD01-UP001 --oid=1.3.6.1.4.1.534.1.3.4.1.2.1 --critical=183:275 --units=volts --label=xupsInputVoltage

SNMP OK - xupsInputVoltage 232 volts | xupsInputVoltage=232

Если мы добавим опцию -v (подробный вывод), то увидим что плагин для запроса использует утилиту snmpget. Именно поэтому мы ранее предварительно проверяли SNMP запросы с помощью этой утилиты.

Проверим SNMPv3. Здесь короткие опции похожи на те, что использует утилита snmpget, однако, опять же для большей наглядности, я использую длинные опции. Кстати, используемый у меня плагин check_snmp версии 2.1 не воспринимает опцию --authpassword (хотя опция есть во встроенной справке плагина), поэтому я использую короткую опцию -A

$ /usr/lib/nagios/plugins/check_snmp --protocol=3 --seclevel=authPriv --secname=icinga --authproto=MD5 -A myAuthenticati0nPassphraZzze --privproto=DES --privpasswd=myPrivVvacyPas4sphraZze --hostname=KOM-AD01-UP011 --oid=1.3.6.1.4.1.318.1.1.1.3.2.1.0 --critical=210:250 --units=volts --label=upsAdvInputLineVoltage

SNMP OK - upsAdvInputLineVoltage 232 volts | upsAdvInputLineVoltage=232

Как видим, плагин check_snmp работает, успешно взаимодействуя с утилитами из пакета snmp, поэтому теперь можно перейти к настройке поддержки протокола SNMP в веб-интерфейсе Icinga Director.

 

Настройка Icinga Director

Ранее упомянутый плагин check_snmp работает с SNMP версиями 1/2с/3. В веб-интерфейсе Icinga Director нам потребуется описать новые переменные, в которых в дальнейшем будет хранится информация, необходимая для подключения по протоколу SNMP в зависимости от выбранной версии протокола. С учётом примера, описанного в документе Data Fields example: SNMP, и некоторого опыта использования объектов в Icinga Director, будем использовать следующую последовательность действий по настройке:

• Создаём Списки Данных (Data List) для использования в Полях Данных;
• Создаём Поля Данных (Data Field) для хранения информации о настройках SNMP для Хостов;
• Настраиваем сокрытие парольной информации в Icinga Web;
• Создаём опорный Шаблон Хоста, общий для всех сетевых устройств;
• Создаём дополнительные Шаблоны Хостов в разрезе типов устройств и производителей;
• Создаём Хосты с привязкой к Шаблону Хоста;
• Создаём Группы Хостов для сетевых устройств в разрезе типов устройств и производителей;
• Создаём Команду check_snmp;
• Создаём Шаблоны Служб на основе ранее созданной Команды check_snmp;
• Назначаем развёртывание Службы на Группы Хостов через Правила Apply-Rule;
• Проверяем результат и расширяем набор Служб

 

Создаём Списки Данных (Data List)

Начнём с создания Списков Данных (Data List), которые в дальнейшем будут использоваться для выбора значений в Полях Данных (Data Field). И Списки и Поля Данных в Icinga Director мы можем создавать для решения любых задач. В контексте темы данной заметки мы создадим Списки и Поля Данных для будущего хранения переменных, касающихся настроек протокола SNMP для Хостов, в качестве которых в нашем случае выступают сетевые контроллеры управления ИБП (хотя это могут быть и любые другие типы сетевых устройств, имеющие поддержку протокола SNMP). Чтобы создать новые Списки Данных, в веб-консоли Icinga Web перейдём в раздел навигации Icinga Director и выберем пункт Provide data lists.

Первый Список Данных, который нам понадобится, будет определять перечень версий протокола SNMP. Назовём его, например, snmp_versions и создадим в нём три значения:

• (1) SNMP v1
• (2c) SNMP v2c
• (3) SNMP v3

Созданный Список Данных будет использоваться для всех сетевых устройств, использующих протокол SNMP.

Следующие три Списка данных, которые мы создадим, будут использоваться для устройств, у которых в качестве версии протокола будет выбран SNMP v3.

Список Данных с именем snmpv3_authentication_types, будет определять перечень алгоритмов хеширования, применяемых в ходе аутентификации при использовании протокола SNMP v3. Создадим в нём значения MD5 и SHA.

Список Данных с именем snmpv3_privacy_types, будет определять перечень типов шифрования, используемых для защиты данных в протоколе SNMP v3. Создадим в нём значения AES и DES.

Список Данных с именем snmpv3_security_levels, будет определять перечень уровней безопасности, определяющих совокупность методов защиты протокола SNMP v3. Значения этого Списка будут тождественны вариантам, которые может принимать значение опции --seclevel ранее упомянутого плагина check_snmp:

• noAuthNoPriv (не использовать аутентификацию и шифрование данных)
• authNoPriv (использовать аутентификацию без шифрования данных)
• authPriv (использовать аутентификацию и шифрование данных)

Нужные Списки Данных созданы, и теперь мы можем перейти к созданию Полей Данных (Data Field).

 

Создаём Поля Данных (Data Field)

Чтобы создать новые Поля Данных, в веб-консоли Icinga Web перейдём в раздел навигации Icinga Director и выберем пункт Define data fields. Подавляющая часть Полей Данных, которые мы будем создавать в рамках нашей задачи, будет иметь строковой тип значения (String), но некоторые Поля Данных в качестве типа значения будут ссылаться на только что созданные Списки данных (Data List). Например, тип значения Поля Данных snmp_version будет ссылаться на ранее созданный нами Список Данных snmp_versions

Приведу в виде таблицы все Поля Данных, которые нам потребуется создать:

Имя Поля Данных (Field name)	Тип значения Поля Данных (Data type)	Описание (Caption)
snmp_version	Datalist  "snmp_versions"	SNMP version
snmp_community	String	SNMP Community
snmp_SNMPv2_MIB_sysObjectID	String	SNMP System OID
snmpv3_seclevel	Datalist  "snmpv3_security_levels"	SNMPv3 Security Level
snmpv3_user	String	SNMPv3 User
snmpv3_authprot	Datalist "snmpv3_authentication_types"	SNMPv3 Authentication Protocol
snmpv3_authpwd	String	SNMPv3 Authentication Password
snmpv3_privprot	Datalist "snmpv3_privacy_types"	SNMPv3 Privacy Protocol
snmpv3_privpwd	String	SNMPv3 Privacy Password

При создании новых Полей Данных (как и при создании Списков данных) мы можем использовать любые удобные и понятные для нас имена, но с некоторыми ограничениями. Например в имени лучше воздержаться от применения каких-либо спецсимволов, отличных от "_". В противном случае, в последствии в процессе применения конфигурации Icinga Director с использованием данных объектов могут возникнуть ошибки и конфигурация не будет применена.

Наверно вы обратили внимание на то, что одна из создаваемых переменных (snmp_SNMPv2_MIB_sysObjectID) выбивается из общего ряда и имеет длинное имя. Попытаюсь пояснить, почему так. В процессе дальнейшей настройки Icinga Director для мониторинга сетевых устройств по протоколу SNMP вероятнее всего нам может потребоваться создавать некоторое количество дополнительных Полей Данных, которые будут применимы к Хостам разных типов (например Модули управления ИБП, Коммутаторы, Медиа-конверторы и т.п.) и разных производителей оборудования (например APC, Eaton, Cisco, Digi и т.п.). Почти все производители, предлагающие реализацию протокола SNMP для своих устройств имеют файлы MIB, в которых описаны идентификаторы OID, которые возвращаются тем или иным устройством при опросе по протоколу SNMP. И чаще всего (хотя и не всегда) цифровой идентификатор OID имеет имя, описанное в MIB. Поэтому для большей понятности того, к чему относится то или иное Поле Данных, связанное с конкретными идентификаторами SNMP OID я использую схему именования snmp_<Имя MIB>_<Имя параметра из MIB>. И разумеется, именование Полей Данных остаётся делом вкуса.

В рассматриваемом нами примере все созданные Поля Данных snmp_* (за исключением snmp_SNMPv2_MIB_sysObjectID) будут использоваться для хранения данных, необходимых для подключения к сетевым устройствам по протоколам SNMP v1/2c/3. А Поле Данных snmp_SNMPv2_MIB_sysObjectID будет использоваться для хранения основного OID, идентифицирующего производителя и тип устройства - 1.3.6.1.2.1.1.2.0. И в зависимости от того, какое значение будет хранится в переменной snmp_SNMPv2_MIB_sysObjectID того или иного Хоста в Icinga Director, будет происходить привязка к этому Хосту тех Служб, которые описывают правила мониторинга соответствующего типа устройств.

 

Настраиваем сокрытие парольной информации в Icinga Web

Так как некоторые из созданных нами Полей Данных (snmp_community, snmpv3_authpwd, snmpv3_privpwd) фактически будут использоваться для хранения парольной информации, нам желательно настроить сокрытие значений, хранимых в этих Полях при отображении в веб-интерфейсе Icinga Web 2. Настроить такое сокрытие данных можно, как методом прямой правки конфигурационного файла /etc/icingaweb2/modules/monitoring/config.ini…

[security]
protected_customvars = "*pw*,*pass*,*community,*pwd"

…так и через веб-интерфейс Icinga Web, выбрав в меню навигации Configuration > Modules > Модуль monitoring > Закладка Security:

После этого в веб-интерфейсе Icinga Web, например на странице свойств Хоста, все переменные, подпадающие под указанную нами маску имени будут отображаться в виде "звёздочек".

 

Создаём опорный Шаблон Хоста "SNMP Host"

В веб-интерфейсе Icinga Web перейдём в раздел навигации Icinga Director > Host и создадим новый Шаблон Хоста с именем, например "SNMP Host". Этот Шаблон будет использоваться в качестве опорного Шаблона для всех сетевых устройств (вне зависимости от типа устройств и производителя), которые должны опрашиваться по протоколу SNMP. В качестве обязательной Команды проверки (Check command), укажем любую Команду, которая умеет проверять сетевую доступность Хоста, например hostalive4.

В свойствах Шаблона на закладке Fields подключаем созданные ранее Поля Данных, которые будут использоваться для хранения идентификационной информации, необходимой для подключения к Хосту по протоколу SNMP:

При этом Поле "SNMP Community" (snmp_community) отображается при условии, что заполнено поле "SNMP version" (snmp_version) и равно "1" или "2c".

Поля "SNMPv3 *" все настроены таким образом, что отображаются лишь при условии, что поле "SNMP version" равно "3".

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

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

template Host "SNMP Host" {
    check_command = "hostalive4"
    icon_image = "img/icons/custom/icingaweb2-network-device01.png"
}

Обратите внимание на то, что в текущей реализации Icinga Director на закладке Preview мы не увидим никакой информации о дополнительных Полях, которые нами описаны на закладке Fields. Это, что называется, "by design", и пусть вас это не смущает.

 

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

Создадим необходимое количество дополнительных Шаблонов Хоста, относящихся к разным типам устройств и разным производителям. Например, по условиям нашей задачи, можно отдельно создать пару дополнительных Шаблонов: первый для контроллеров управления ИБП производителя Eaton - "Eaton UPS Device", и второй для контроллеров управления ИБП APC "APC UPS Device".

В поле Import обоих этих Шаблонов выберем ранее созданный Шаблон "SNMP Device". И за счёт этого два созданных Шаблона будут наследовать в себя Поля Данных, которые мы ранее присоединили к Шаблону "SNMP Device", и при этом, для каждого из этих Шаблонов мы в последующем сможем в любой момент присоединить любое количество дополнительно созданных Полей Данных, характерных только для устройств данного типа и производителя. Например, к Шаблону "Eaton UPS Device" могут быть присоединены несколько дополнительных Полей Данных, характерных только для соответствующего класса устройств:

Однако в рамках данной статьи мы не будем заострять внимания на этих дополнительных Полях Данных, а будем говорить о применении лишь базового набора Полей Данных, создание которых было описано ранее. И данный момент с дополнительными Полями Данных освещён только для того, чтобы было понятно то, чем может быть полезно создание цепочки зависимостей Шаблонов типа "SNMP Device" > "Eaton UPS Device" или "SNMP Device" > "APC UPS Device".

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

template Host "Eaton UPS Device" {
    import "SNMP Host"
}

Соответственно, в свойствах созданного Шаблона Хоста "APC UPS Device" на закладке Preview в нашем случае отображается следующая результирующая конфигурация:

template Host "APC UPS Device" {
    import "SNMP Host"
}

 

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

Настало время создать в Icinga Director записи о Хостах, то есть рассмотренных нами ранее контроллерах управления ИБП с именами KOM-AD01-UP01 и KOM-AD01-UP11. При создании Хостов в поле Import указываем Шаблон, соответствующий данному типу устройств, например "Eaton UPS Device". Как следствие, в расширенных свойствах этих (Custom properties) Хостов появится возможность заполнения ассоциированных с Полей Данных, относящихся к настройкам протокола SNMP.

Заполняем для каждого Хоста версию и параметры аутентификации SNMP.

***

Рассмотрим пример заполнения реквизитов SNMP для ранее рассмотренного контроллера управления ИБП Eaton Powerware с именем KOM-AD01-UP001.

Убедимся в том, что ранее заданные нами условия отображения Полей Данных работают корректно, то есть, при выборе в поле "SNMP version" значений "SNMP v1" или "SNMP v2c" в форме дополнительно появляется поле для определения строки подключения SNMP ("SNMP Community"). Укажем основной идентификатор устройства System OID, который мы ранее получили из OID 1.3.6.1.2.1.1.2.0 с помощью утилит snmpwalk/snmpget. Заполним строку подключения SNMP Community, которую мы ранее задали при настройке контроллера управления.

***

В следующем примере настроим реквизиты SNMP в свойствах другого Хоста для ранее рассмотренного контроллера управления ИБП APC Smart-UPS с именем KOM-AD01-UP011.

Опять же, укажем основной идентификатор устройства System OID, который мы ранее получили из OID 1.3.6.1.2.1.1.2.0 с помощью утилит snmpwalk/snmpget. При выборе же протокола "SNMP v3" в форме должны появляться дополнительные поля связанные с аутентификацией в этой версии протокола. Заполним эти поля в соответствии с ранее заданными параметрами при настройке контроллера управления.

***

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

object Host "kom-ad01-up001.holding.com" {
    import "Eaton UPS Device"
    display_name = "KOM-AD01-UP001"
    address = "10.1.2.6"
    vars.snmp_SNMPv2_MIB_sysObjectID = "1.3.6.1.4.1.534.1"
    vars.snmp_community = "myR0Secret"
    vars.snmp_version = "1"
}

Соответственно, в свойствах созданного Хоста KOM-AD01-UP011 на закладке Preview в нашем случае отображается следующая результирующая конфигурация:

object Host "kom-ad01-up011.holding.com" {
    import "APC UPS Device"
    display_name = "KOM-AD01-UP011"
    address = "10.1.1.6"
    vars.snmp_SNMPv2_MIB_sysObjectID = "1.3.6.1.4.1.318.1.3.2.13"
    vars.snmp_version = "3"
    vars.snmpv3_authprot = "MD5"
    vars.snmpv3_authpwd = "myAuthenticati0nPassphraZzze"
    vars.snmpv3_privprot = "DES"
    vars.snmpv3_privpwd = "myPrivVvacyPas4sphraZze"
    vars.snmpv3_seclevel = "authPriv"
    vars.snmpv3_user = "icinga"
}

На данном этапе можно считать, что в конфигурацию Icinga Director добавлена информация, достаточная для аутентификации Хостов по протоколу SNMP.

 

Создаём Группы Хостов для сетевых устройств в разрезе типов устройств и производителей

После того, как записи о Хостах созданы, мы можем создать Группы Хостов, которые будут объединять однотипные Хосты. Это нужно для того, чтобы Службы с настройками правил мониторинга конкретных типов сетевого оборудования, которые мы будем создавать в дальнейшем, назначать не на каждый Хост по отдельности, а сразу на Группу однотипных Хостов. Правила членства в Группах Хостов сделаем динамическим, то есть правила будут основаны на поиске Хостов с определёнными значениями той или иной переменной в свойствах Хоста.

Например, создадим Группу Хостов с именем "Eaton-Powerware-UPS", членство в которой будут автоматически получать те Хосты, у которых в значении переменной snmp_SNMPv2_MIB_sysObjectID хранятся значения равные "1.3.6.1.4.1.534.1" или "1.3.6.1.4.1.705.1":

В итоге в свойствах созданной Группы Хостов "Eaton-Powerware-UPS" на закладке Preview будет отображена следующая результирующая конфигурация, которая попадёт в конфигурацию Icinga Director при очередном развёртывании:

object HostGroup "Eaton-Powerware-UPS" {
    display_name = "Eaton Powerware UPS"
    assign where host.vars.snmp_SNMPv2_MIB_sysObjectID == "1.3.6.1.4.1.534.1" || host.vars.snmp_SNMPv2_MIB_sysObjectID == "1.3.6.1.4.1.705.1"
}

По аналогии сделаем вторую группу для ИБП APC, которая в нашем примере с именем "APC-Smart-UPS" и имеет следующую результирующую конфигурацию на закладке Preview:

object HostGroup "APC-Smart-UPS" {
    display_name = "APC Smart-UPS"
    assign where host.vars.snmp_SNMPv2_MIB_sysObjectID == "1.3.6.1.4.1.318.1.3.2.13" || host.vars.snmp_SNMPv2_MIB_sysObjectID == "1.3.6.1.4.1.318.1.3.2" || host.vars.snmp_SNMPv2_MIB_sysObjectID == "1.3.6.1.4.1.318.1.3.2.7" || host.vars.snmp_SNMPv2_MIB_sysObjectID == "1.3.6.1.4.1.318.1.3.5.1"
}

Следующее, что нам нужно сделать – настроить Команды и Службы для опроса Хостов по протоколу SNMP.

 

Создаём Команду check_snmp

В имеющейся у вас конфигурации Icinga Director скорее всего уже будет присутствовать Команда с именем snmp, которая могла быть автоматически импортирована ранее из файловой конфигурации Icinga при развёртывании модуля Icinga Director.

Однако тут нужно учесть тот момент, что плагин (в данном случае check_snmp), на который ссылается импортированная ранее Команда, со временем может обновляться и менять состав используемых при его вызове опций и ключей, что в конечном итоге может пойти в разрез с нередактируемой импортированной конфигурацией Команды в Icinga Director. Учитывая это обстоятельство, более логичным будет создание собственной Команды, полностью управляемой и настраиваемой нами в конфигурации Icinga Director. Поэтому в данном примере мы именно так и поступим – создадим собственную Команду, вызывающую плагин check_snmp. Присвоим этой команде любое удобное нам имя, например, пусть это имя бесхитростно будет совпадать с именем вызываемого плагина – "check_snmp".

Как видно, созданная нами Команда имеет ряд свойств (Custom properties), необходимых для передачи нужных параметров при вызове Команды (эти параметры в дальнейшем транслируются в ряд Аргументов, используемых для вызова плагина check_snmp). Данные дополнительные свойства Команды создаются с помощью механизма Полей Данных (Data Field) по аналогии с тем, что мы уже рассматривали выше. После создания соответствующих Полей Данных, они назначаются в свойствах созданной нами Команды "check_snmp" на закладке Fields. В нашем примере созданы и присвоены Команде в качестве дополнительных свойств Поля Данных: snmp_label, snmp_oid, snmp_critical, snmp_warning, snmp_timeout, snmp_units

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

Как видно, в качестве значений интересующих нас Аргументов передаются как данные, полученные из свойств Команды (описаны через дополнительные Поля Данных snmp_label, snmp_oid, snmp_critical, snmp_warning, snmp_timeout, snmp_units), так и из свойств Хоста, для которого будет вызываться Команда (snmp_version, snmp_community, snmpv3_authprot и т.п.).

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

object CheckCommand "check_snmp" {
    import "plugin-check-command"
    command = [ PluginDir + "/check_snmp" ]
    timeout = 1m
    arguments += {
        "--authproto" = "$snmpv3_authprot$"
        "--community" = {
            order = 2
            value = "$snmp_community$"
        }
        "--critical" = "$snmp_critical$"
        "--hostname" = {
            order = 3
            required = true
            value = "$address$"
        }
        "--label" = "$snmp_label$"
        "--oid" = {
            required = true
            value = "$snmp_oid$"
        }
        "--privpasswd" = "$snmpv3_privpwd$"
        "--privproto" = "$snmpv3_privprot$"
        "--protocol" = {
            order = 1
            required = true
            value = "$snmp_version$"
        }
        "--seclevel" = "$snmpv3_seclevel$"
        "--secname" = "$snmpv3_user$"
        "--timeout" = "$snmp_timeout$"
        "--units" = "$snmp_units$"
        "--warning" = "$snmp_warning$"
        "-A" = "$snmpv3_authpwd$"
    }
}

 

Создаём Шаблоны Служб на основе Команды check_snmp

Теперь на основе ранее созданной Команды "check_snmp" мы можем создать такое количество Шаблонов Служб, которое необходимо для опроса всех интересующих нас параметров оборудования по протоколу SNMP. При этом в нашем примере будет использоваться подход по принципу  1 OID = 1 Шаблон Службы. Поэтому здесь нужно начать с того, чтобы определиться с перечнем идентификаторов OID, значения которых мы желаем опрашивать у Хостов по протоколу SNMP.

По мере накопления опыта общения с разными типами оборудования, имеющего реализацию SNMP, я постараюсь выкладывать в Вики информацию по спискам OID, которые могут быть интересны в контексте задачи мониторинга. Приведу ссылки на Вики-страницы где собраны OID для контроллеров управления ИБП по условиям нашей задачи:

• Идентификаторы OID для мониторинга модулей управления ИБП Eaton (Powerware) Network Management Card по протоколу SNMP
• Идентификаторы OID для мониторинга модулей управления ИБП APC Network Management Card по протоколу SNMP

Для примера рассмотрим процедуру создания Шаблонов Служб для мониторинга входного напряжения ИБП Eaton (OID 1.3.6.1.4.1.534.1.3.4.1.2.1) и APC (OID 1.3.6.1.4.1.318.1.1.1.3.2.1.0).

В первую очередь создадим общий для обоих рассматриваемых нами типов оборудования Шаблон Службы, в котором будут заданы основные настройки для вызова Команды "check_snmp". В меню навигации Icinga Director перейдём в раздел Services и на закладке Templates создадим новый Шаблон Службы, например с именем "UPS Input Voltage". При создании Шаблона в поле Check command из выпадающего списка выберем ранее созданную нами Команду "check_snmp".

Так как вызов нашей Команды предполагает передачу параметров, то в свойствах созданного Шаблона Службы на закладке Fields нам потребуется выполнить привязку Полей Данных, которые будут использоваться для передачи параметров. Поле "snmp_oid" в данном случае должно иметь признак обязательного (Mandatory):

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

template Service "UPS Input Voltage" {
    check_command = "check_snmp"
    check_interval = 1m
    enable_perfdata = true
    icon_image = "img/icons/custom/icingaweb2-service-ups-in-voltage01.png"
    vars.snmp_timeout = 30
}

 

Назначаем развёртывание Службы на Группы Хостов через Правила Apply-Rule

Непосредственное развёртывание Служб по созданному Шаблону Службы "UPS Input Voltage" на Хосты мы выполним через Правила Развёртывания (Apply-Rule). Фактически создание Правила Развёртывания и отвечают за создание конечного экземпляра Службы, которая будет наследовать настройки Шаблона "UPS Input Voltage" и будет назначена на конечные Хосты в Icinga Director.

Чтобы создать Правила Развёртывания, в свойствах созданного Шаблона "UPS Input Voltage" на закладке Service используем ссылку Create apply-rule:

Создадим Правило Развёртывания для ИБП Eaton, например с именем "Powerware UPS Input Voltage".

В поле Imports будет подключён Шаблон Службы "UPS Input Voltage".

В блоке Assign where добавим правило, которое гласит о том, что Служба будет автоматически назначаться на Хосты, входящие в группу "Eaton-Powerware-UPS". Именно для этого ранее мы создавали группы Хостов в разрезе типов оборудования и производителей.

В блоке Custom properties мы увидим ряд переменных, которые унаследованы от Шаблона Службы "UPS Input Voltage". И вот уже здесь мы указываем идентификатор OID, имеющий отношение к конкретному типу устройств конкретного производителя. Здесь же указываем границы для определения текущего состояния Службы. В данном примере указано, что для OID 1.3.6.1.4.1.534.1.3.4.1.2.1 значения выходящие за рамки диапазона от 183 VAC до 275 VAC считаются триггером для перевода Службы в статус Critical.
Поле SNMP Label в данном случае используется для того, чтобы определить имя параметра, который будет записан в хранилище Performance data (если не указать, то данные в хранилище будут записаны в виде OID, что не всегда удобно для дальнейшего анализа и построения графиков). Для этих лейблов, как правило, я использую имена, соответствующие идентификаторам OID из MIB-файлов. Если в MIB-файлах интересующий нас OID не имеет имени (такое тоже бывает), то я использую любое другое произвольное имя, которое потом можно будет ассоциировать с данным параметром при построении графиков. То есть, это вопрос исключительно косметического характера и личного удобства.
Поле SNMP Timeout соответственно определяет время ожидания в секундах, после которого, в случае если не получен от плагина ответ, Служба переводится в состояние UNKNOWN.
В общем-то Вы уже наверно догадались, что все перечисленные здесь параметры в конечном итоге транслируются утилите snmpget, которую использует плагин check_snmp.

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

apply Service "Powerware UPS Input Voltage" {
    import "UPS Input Voltage"
    assign where "Eaton-Powerware-UPS" in host.groups
    vars.snmp_critical = "183:275"
    vars.snmp_label = "xupsInputVoltage"
    vars.snmp_oid = "1.3.6.1.4.1.534.1.3.4.1.2.1"
    vars.snmp_timeout = 50
    vars.snmp_units = "VAC"
    import DirectorOverrideTemplate
}

***

Далее по аналогии создаём Правило Развёртывания (Apply-Rule) для ИБП APC, например с именем "APC UPS Input Voltage". Кстати, сделать это можно используя удобную функцию клонирования, имеющуюся в Icinga Director, после чего лишь изменить некоторые параметры. Например, в данном случае Служба будет иметь немножко другое имя, будет назначаться для Хостов, входящих в Группу Хостов "APC-Smart-UPS", а в блоке Custom properties будут описаны параметры относящиеся к OID APC.

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

apply Service "APC UPS Input Voltage" {
    import "UPS Input Voltage"
    assign where "APC-Smart-UPS" in host.groups
    vars.snmp_critical = "210:250"
    vars.snmp_label = "upsAdvInputLineVoltage"
    vars.snmp_oid = "1.3.6.1.4.1.318.1.1.1.3.2.1.0"
    vars.snmp_units = "VAC"
    import DirectorOverrideTemplate
}

 

Проверяем результат и расширяем набор Служб

Итак, после того, как мы настроили правила Apply-Rule и выполнили развёртывание конфигурации Icinga Director, в веб-консоли Icinga Web в разделе Overview > Hosts мы сможем увидеть, то что у наших Хостов (контроллеров управления ИБП) в соответствии с их членством в Группах Хостов на вкладке Services появились и начали работать новые Службы:

А при открытии страницы самой Службы, мы сможем увидеть сведения метрик производительности (Performance data), о которых мы упоминали ранее, когда говорили про то, зачем может быть полезным использование SNMP Label (кстати здесь его видно как в Plugin Output, так и непосредственно на графике). Напомню, что о подключении и построении графиков для хранимых метрик производительности мы ранее говорили в разных вариациях в заметках Настройка интеграции Graphite в Icinga Web 2 и Настройка интеграции Grafana в Icinga Web 2.4.1.

***

Итак, описанная выше последовательность действий дала нам базовую возможность создания любых собственных Служб Icinga, которые будут помогать нам отслеживать состояние тех или иных параметров состояния сетевых устройств по протоколу SNMP. И не смотря на кажущуюся громоздкость проделанных действий, начальная (и бОльшая) часть которых делается всего один раз, последующее добавление Служб будет вполне простой задачей, занимающей минимум времени и дающей при этом нам широкие возможности по расширению нашей системы мониторинга под свои нужны. Например, для тех же контроллеров ИБП, с учётом уже выполненных действий, для добавления новой Службы потребуется выполнить всего два шага из ранее перечисленного плана:

• Создаём Шаблоны Служб на основе ранее созданной Команды
  check_snmp;
• Назначаем развёртывание Службы на Группы Хостов через Правила
  Apply-Rule

 

И после создания необходимого количества Служб, каждая из которых будет отслеживать состояние определённого показателя работы контроллеров управления ИБП, можно получить примерно следующий результат:

***

На что ещё хочется обратить внимание в рамках рассматриваемой темы, так это на то, что в данной  заметке мы не уделили должного внимания двум смежным вопросам:

• Создание Служб, состояние которых вычисляется из значений разных OID;
• Автоматизация инвентаризации расширенного набора хранимых свойств Хостов

Оба эти вопроса я постараюсь осветить в дальнейшем в отдельных заметках на конкретных примерах.

В следующей же заметке об Icinga мы продолжим тему мониторинга сетевых устройств по протоколу SNMP и рассмотрим пошаговый пример настройки ловушки SNMP Trap в конфигурации Icinga Director.