Настройка низкоуровневого обнаружения в Zabbix

В Zabbix 2.0 появилась новая функция – низкоуровневое обнаружение (Low Level Discovery), она поддерживает динамическое изменение количества параметров, и позволяет заметно упростить мониторинг устройств с множеством однотипных параметров различающихся по количеству на разных хостах.

Данная статья является логичным продолжением статьи о “Мониторинге LSI MegaRAID 9260-8i по SNMP”, и речь в ней пойдет о настройке низкоуровневого обнаружения для мониторинга состояния дисков на RAID контроллерах LSI MegaRAID по протоколу SNMP. Принцип описанный в этой статье вполне можно использовать для мониторинга любого SNMP устройства.

В статье используются:

Сервер с контроллером LSI Megaraid и настроенным LSI SNMP агентов, DNS smb02.mydomain.local

Сервер с настроенным Zabbix 2.0, DNS zabbix.mydomain.local

Настройка

Создаем новый шаблон с именем Template LSI RAID SNMP и добавляем его в группу Templates

Открываем наш шаблон и переходим к Discovery Rules, где шелкаем Create Discovery Rule, чтобы создать новое правило низкоуровневого обнаружения.

В основном блоке Discovery Rule описывается некоторая функция которая возвращает набор значений, а впоследствии уже эти значения используются для формирования вложенных в правило значений, триггеров и графиков. Для SNMP эта функция уже встроена в Zabbix и работает она по принципу snmpwalk перебирая все значения от некоторого OID и записывая индекс в переменную переменные SNMPINDEX и значение в SNMPVALUE.

Для случая с RAID контроллером вполне достаточно определить количество дисков, их индексы, а затем контролировать через триггеры параметр отвечающий за состояние каждого диска. Просмотрим доступные по протоколу SNMP параметры LSI SNMP агента:

[root@zabbix ~]# snmptranslate -Tp LSI-MegaRAID-SAS-MIB::physicalDriveInfo | less

+--physicalDriveInfo(1)
   |
   +-- -R-- Gauge     pdNumber(1)
   |
   +--physicalDriveTable(2)
      |
      +--physicalDriveEntry(1)
         |  Index: physDevID
         |
         +-- -R-- INTEGER   pdIndex(1)
         +-- -R-- INTEGER   physDevID(2)
         +-- -R-- INTEGER   oemSupported(3)
         +-- -R-- INTEGER   scsiDevType(4)
         +-- -R-- String    connectedAdapterPort(5)
         |        Textual Convention: DisplayString
         +-- -R-- INTEGER   deviceSpeed(6)
         +-- -R-- INTEGER   mediaErrCount(7)
         +-- -R-- INTEGER   otherErrCount(8)
         +-- -R-- INTEGER   predFailCount(9)
         +-- -R-- INTEGER   pdState(10)
         +-- -R-- INTEGER   disabledForRemoval(11)
         +-- -R-- INTEGER   linkSpeed(12)
         .   .   .   .   .

Индекс для правила автообнаружения у нас есть – это pdIndex, проверяем его через snmpwalk

[root@zabbix ~]# snmpwalk -v1 -c public smb02.mydomain.local LSI-MegaRAID-SAS-MIB::pdIndex
LSI-MegaRAID-SAS-MIB::pdIndex.0 = INTEGER: 0
LSI-MegaRAID-SAS-MIB::pdIndex.1 = INTEGER: 1
LSI-MegaRAID-SAS-MIB::pdIndex.2 = INTEGER: 2

Такой вывод говорит о том что на нашем контроллере установлены три диска с индексами от 0 до 2. Zabbix по умолчанию не умеет работать с MIB-файлами, поэтому переводим LSI-MegaRAID-SAS-MIB::pdIndex в цифровой OID.

[root@zabbix ~]# snmptranslate -On LSI-MegaRAID-SAS-MIB::pdIndex
.1.3.6.1.4.1.3582.4.1.4.2.1.2.1.1

Возвращаемся к странице создания Discovery Rule и вписываем это значение в поле SNMP OID, также задаем Name – LSI MegaRAID Adapter, Type – SNMPv1 agent, Key – pdIndex, SNMP community – public или макро {$SNMP_COMMUNITY}, которое потом можно будет менять уже на уровне хоста.

Переходим к Item prototypes нашего Discovery Rule, и создаем новый прототип нажав Create item prototype. Здесь нужно понимать что элементы будут генерироваться из прототипов на основе индексов из Discovery Rule и у каждого элемента данных должны получиться разные поля Name и Key. Вернемся опять к SNMP, по идее за состояние диска должен отвечает параметр pdState, просмотрим его полное описание.

[root@localhost disk]# snmptranslate -Td  LSI-MegaRAID-SAS-MIB::pdState
LSI-MegaRAID-SAS-MIB::pdState
pdState OBJECT-TYPE
-- FROM       LSI-MegaRAID-SAS-MIB
SYNTAX        INTEGER
MAX-ACCESS    read-only
STATUS        optional
DESCRIPTION   "Firmware's interpretation of drive state.
Values: unconfigured-good(0),unconfigured-bad(1),hot-spare(2),offline(16),failed(17),rebuild(20),online(24),copyback(32),system(64),
UNCONFIGURED-SHIELDED(128),HOTSPARE-SHIELDED(130),CONFIGURED-SHIELDED(144)"
::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) lsi(3582) storageComponents(4) lsiRAIDS erver(1) megaRAID-SAS(4) device(2) physicalDriveInfo(1) physicalDriveTable(2) physicalDriveEntry(1) 10 }

Получается, что параметр pdState принимает разные значения в зависимости от состояния диска, а в случае сбоя принимает значение 17. Переводим его в цифровой OID

[root@localhost disk]# snmptranslate -On LSI-MegaRAID-SAS-MIB::pdState
.1.3.6.1.4.1.3582.4.1.4.2.1.2.1.10

Возвращаемся к созданию Item prototype, и задаем Name – Physical Drive {#SNMPINDEX}, Type – SNMPv1 agent, Key – pdState.[{#SNMPINDEX}], SNMP OID, .1.3.6.1.4.1.3582.4.1.4.2.1.2.1.10.{#SNMPINDEX}.

Сохраняем и переходим к создания прототипа для триггера, который будет оповещать о неисправности диска. Открываем Trigger prototypes и щелкаем Create trigger prototype, в поле Name забиваем Physical drive failure {#SNMPINDEX}, Expression – {Template LSI RAID SNMP:pdState.[{#SNMPINDEX}].last(0)}=17, и выбираем важность сообщения Severity – High.

Готово, теперь осталось прикрепить этот шабон нужному хосту и наслаждаться результатом.