Мониторинг Dell PowerEdge через iDRAC и SNMP: опрос, traps и Zabbix

В Zabbix все узлы зелёные, но один блок питания PowerEdge уже отказал. iDRAC отправил SNMP trap по UDP 162, пакет потерялся, а повторной доставки нет: получатель не подтверждает traps.

Чтобы дежурный видел состояние дисков, RAID, блоков питания, вентиляторов и температур, опрашивайте iDRAC по SNMP. Traps подключите вторым каналом — для быстрой реакции между опросами. Такая схема работает даже при зависшей ОС сервера.

Откуда забирать данные: iDRAC или OMSA #

Для внеполосного мониторинга PowerEdge с iDRAC7 и новее используйте iDRAC-SMIv2.mib. Руководство Dell SNMP Reference Guide указывает поддержку этой MIB начиная с iDRAC7. На те же поколения рассчитан официальный шаблон Zabbix Dell iDRAC by SNMP.

iDRAC работает независимо от Windows Server, Linux и установленного гипервизора. Если ОС зависла или сетевой интерфейс сервера перестал отвечать, отдельный порт управления продолжает отдавать состояние железа.

MIB-файлы 10892.mib и dcstorag.mib относятся к другому контуру. По руководству Dell, первый описывает системы под наблюдением Server Administrator, второй — накопители и RAID, которые контролирует Server Administrator. Они нужны, когда Вы собираете данные через Dell OpenManage Server Administrator, а не напрямую из iDRAC.

Не стройте новую настройку на DELL-RAC-MIB.txt. Dell называет её устаревшей MIB iDRAC и предупреждает: контроллер поддерживает не все описанные там объекты и traps. Такая база оставляет неприятную неопределённость — часть проверок работает, часть молчит, хотя конфигурация выглядит правильной.

Практическая развилка простая:

• нужен контроль железа независимо от ОС — опрашивайте iDRAC;
• нужны данные и операции Server Administrator внутри ОС — подключайте OMSA отдельным контуром;
• нужны оба набора — не смешивайте MIB и узлы мониторинга, иначе дежурный получит две тревоги на один отказ и не поймёт, какая из них первична.

Что собирать с iDRAC #

Начните со сводного состояния системы. В официальном шаблоне Zabbix элемент Overall system health status показывает общий результат проверки компонентов через IDRAC-MIB-SMIv2.

Одного сводного статуса мало. Он сообщает, что серверу плохо, но не показывает, какой компонент поднял тревогу. Поэтому следующим слоем включите низкоуровневое обнаружение — LLD. Zabbix сам найдёт установленные блоки питания, вентиляторы и диски, а затем создаст для них элементы данных.

Штатный шаблон использует следующие таблицы:

Что контролируем	Таблица MIB
Температура процессоров	temperatureProbeTable
Блоки питания	powerSupplyTable
Вентиляторы	coolingDeviceTable
Физические диски	physicalDiskTable
Виртуальные диски RAID	virtualDiskTable

Для физических дисков отдельно собирайте признак predictive failure. Диск ещё может входить в массив и обслуживать запросы, пока его SMART уже сообщает о приближающемся отказе. Это время нужно потратить на проверку резервной копии и подготовку совместимого накопителя, а не ждать перехода RAID в degraded.

По вентиляторам полезны два показателя: состояние и скорость вращения. По контроллеру управления — версия прошивки. Service Tag поможет связать тревогу с конкретной машиной, заявкой и гарантией, особенно если в стойке несколько одинаковых R640 или R740.

Числовые коды состояний здесь намеренно не расшифрованы. Описание шаблона Zabbix перечисляет значения, но первичной таблицы Dell именно для этих статусов среди материалов нет. Для рабочего мониторинга безопаснее оставить преобразования из штатного шаблона, чем собирать собственную карту кодов по пересказам.

Почему опрос и traps нужны вместе #

Опрос отвечает на вопрос: «В каком состоянии сервер сейчас?» Zabbix регулярно обращается к iDRAC, читает датчики и замечает не только аппаратную неисправность, но и пропажу самого SNMP.

Trap отвечает на другой вопрос: «Что только что произошло?» iDRAC отправляет событие сразу, не дожидаясь следующего цикла опроса. Но SNMP traps идут по UDP и не получают подтверждения от принимающей стороны — это прямо указано в Dell SNMP Reference Guide. Потерянный пакет никто не доставит повторно.

Поэтому traps не заменяют polling. Если оставить только события, отказ блока питания может пройти мимо мониторинга из-за одного потерянного пакета. Если оставить только опрос с интервалом пять минут, тревога придёт с задержкой до пяти минут. Вместе каналы закрывают слабые места друг друга.

Для traps откройте в iDRAC раздел Configuration → System Settings → Alerts. Event Filters определяют, какие события и каким способом отправляет контроллер. Укажите адрес получателя, включите SNMP для нужных классов событий и разрешите UDP 162 по пути от сети управления до системы мониторинга.

Выбирайте SNMPv3 через учётную запись iDRAC. Dell также поддерживает SNMPv1 и v2 с community string, но такая строка хуже подходит для управляемой инфраструктуры: её приходится хранить и менять как общий секрет сразу на нескольких устройствах.

После настройки отправьте Test Event из раздела Configuration → System Settings. Затем найдите соответствующее событие в Lifecycle Log и на стороне приёмника. Dell связывает тестовые события с Event Messages в журнале Lifecycle Controller, поэтому эта проверка подтверждает весь путь: от правила в iDRAC до обработки системой мониторинга.

Проверка открытого UDP-порта этого не доказывает. Порт может быть доступен, а Event Filter — выключен; пакет может дойти до хоста, но не попасть под нужное правило.

Как подключить штатный шаблон Zabbix #

Для Zabbix 7.0 используйте официальный шаблон Dell iDRAC by SNMP. По документации Zabbix он работает через SNMP agent без внешних скриптов и использует IDRAC-MIB-SMIv2, SNMPv2-MIB и HOST-RESOURCES-MIB.

Привяжите шаблон к узлу, адресом которого служит интерфейс iDRAC, а не интерфейс ОС. Задайте параметры SNMPv3 и дождитесь первого цикла обнаружения.

После подключения проверьте три уровня.

Первый — Zabbix получает сводное состояние и не показывает ошибку чтения SNMP. Одновременно должны появиться версия прошивки iDRAC и Service Tag.

Второй — LLD обнаружил реальные компоненты именно этой машины. У двухблочного R740 должны появиться оба блока питания, установленные вентиляторы, физические диски и виртуальные диски RAID. Если сводный статус читается, а компоненты не создаются, шаблон нельзя считать настроенным.

Третий — тестовое событие из iDRAC пришло в систему. Сверьте время и тип события с Lifecycle Log. Так Вы отделите сбой доставки от ошибки фильтра или правила обработки.

Отдельно создайте тревогу на пропажу данных от iDRAC. Иначе отказ контроллера управления, ошибка учётной записи или сетевой ACL превратят узел в серую зону: свежих показаний нет, но аппаратной тревоги тоже нет. Настройку порогов и контроль исчезновения SNMP-данных подробнее разбирает руководство по мониторингу PowerEdge в Zabbix через iDRAC.

Пороговые датчики загрузки iDRAC9 — отдельная задача. По инструкции Dell для них нужно включить IPMI в настройках iDRAC и учётной записи. Верхний порог задают командой racadm sensorsettings set [FQDD] -level Max [value]. Эти датчики показывают загрузку, но не нужны для базового контроля отказов дисков, питания и охлаждения.

Когда мониторинг можно принимать #

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

Критерии приёмки:

• узел опрашивается напрямую через iDRAC;
• используется iDRAC-SMIv2, а не устаревшая DELL-RAC-MIB.txt;
• SNMPv3 настроен отдельной учётной записью iDRAC;
• LLD обнаружил фактические блоки питания, вентиляторы, физические и виртуальные диски;
• Zabbix получает сводное состояние, Service Tag и версию прошивки;
• Test Event дошёл до приёмника и совпал с записью Lifecycle Log;
• остановка опроса вызывает отдельную тревогу о пропаже данных.

Для ИТ-специалиста это проверяемый результат, а не отметка «SNMP включён». Для руководителя — понятная граница оплаченной работы: мониторинг обнаруживает отказ компонента, замечает потерю связи с iDRAC и подтверждён тестовым событием.