Мониторинг Dell PowerEdge в Zabbix через iDRAC

В одной стойке работают PowerEdge T320 с iDRAC7 и T440 с iDRAC9. Оба показывают 30 °C, но риск разный: iDRAC рассчитывает тепловые границы с учётом процессоров, накопителей и профиля шасси. Общий порог для всего парка либо поднимет лишнюю тревогу, либо пропустит отклонение.

Задача мониторинга — предупредить Вас до отказа и не будить дежурного из-за штатного состояния. Для этого Zabbix должен получать через iDRAC состояние железа, сравнивать температуру с порогами конкретного сервера и отдельно замечать, когда прекратился сам опрос.

Сначала контролируйте состояние компонентов #

Начните с официального шаблона Zabbix Dell iDRAC by SNMP. Он лежит в репозитории Zabbix в каталоге templates/server/dell_idrac_snmp и содержит готовый YAML-шаблон.

Резервирование ещё держит охлаждение

iDRAC работает независимо от операционной системы и гипервизора. Это подтверждает руководство Dell по Redfish API для iDRAC7 и iDRAC8. Поэтому Zabbix продолжит видеть аппаратные датчики, даже если Windows Server завис, VMware ESXi перезагружается или загрузочный диск вышел из строя.

В обязательный набор мониторинга входят:

общий аппаратный статус сервера;
состояние физических дисков и RAID;
блоки питания;
вентиляторы и резервирование охлаждения;
память;
температурные датчики.

Статусы компонентов полезнее голых чисел. iDRAC уже сопоставил показания датчиков со своей конфигурацией и сообщает, исправен ли узел. Температура требует дополнительной работы: Zabbix должен получить её границы с того же сервера.

По накопителям одного общего статуса мало. Износ SSD лучше оценивать по нескольким замерам и заранее включать замену в бюджет — отдельная методика есть в материале о том, как спрогнозировать замену SSD по iDRAC. Для сбора диагностических данных и разбора аппаратного сбоя пригодится Dell SupportAssist.

Берите температурные пороги из iDRAC #

Штатный шаблон Zabbix сравнивает температуру воздуха с общим значением макроса. Для одинаковых серверов в одном помещении этого иногда хватает. Для смешанного парка — нет.

Шаблон Dell iDRAC by SNMP LiveThreshold, который подготовил Джош Хирн на основе официального шаблона Zabbix, получает границы из таблицы temperatureProbeTable:

верхний критический порог;
верхний предупредительный;
нижний предупредительный;
нижний критический.

Порог опрашивается у каждого хоста. PowerEdge T320 и T440 больше не делят одну условную норму: триггер срабатывает по значению, которое настроено в их iDRAC.

На восстановление шаблон использует гистерезис 3 °C. Если предупреждение открылось при 30 °C, оно не закроется при первом же колебании до 29 °C. Температура должна отойти от границы на три градуса. Иначе Zabbix будет переключать событие при каждом коротком скачке датчика.

Живые пороги различаются и между поколениями iDRAC. По результатам испытаний автора LiveThreshold, iDRAC7 на PowerEdge T320 отдаёт для процессора критические и предупредительные границы. iDRAC9 на PowerEdge T440 отдаёт критические границы CPU, но не возвращает предупредительный порог. В таком случае предупреждение строится по статусу nonCriticalUpper, который назначает сам iDRAC.

Это не мелкое различие. Если потребовать от iDRAC9 отсутствующее значение, мониторинг останется без предупреждения или начнёт подставлять неподходящую цифру.

Статические значения нужны только как запасной вариант #

LiveThreshold содержит резервные макросы на случай, если iDRAC не вернул живой порог:

Датчик	Предупреждение	Критическая граница	Нижняя критическая граница
Ambient	30 °C	35 °C	5 °C
CPU	по статусу iDRAC	90 °C	5 °C

Это значения шаблона, а не единая тепловая норма Dell PowerEdge. Не переносите их в технический регламент как допустимые температуры для любого шасси.

Порядок должен быть таким: живой порог конкретного iDRAC, затем резервный макрос. Если Zabbix использует подстановку, это тоже нужно видеть отдельным событием. Иначе после обновления прошивки или сбоя SNMP мониторинг незаметно перейдёт на общие цифры.

Опрос датчиков и порогов решает разные задачи #

LiveThreshold получает температуру каждые 3 минуты. Обнаружение датчиков и чтение порогов выполняются раз в час.

Такой ритм не создаёт лишнюю SNMP-нагрузку, но у него есть следствие: после смены теплового профиля новое значение появится в Zabbix через 0–60 минут. Диапазон следует из часового интервала — изменение может произойти сразу перед опросом или сразу после него.

После замены процессора, перехода с HDD на SSD или изменения теплового профиля запустите обновление порогов принудительно. Ждать час незачем: до следующего опроса триггер может сравнивать температуру с прежней границей.

Отдельный триггер должен следить за отсутствием данных через nodata(). Единого интервала здесь нет. Возьмите не меньше двух периодов конкретного элемента:

для температуры с опросом раз в 3 минуты — не меньше 6 минут;
для порога с опросом раз в час — не меньше 2 часов.

Это расчёт из расписания, а не значение Dell или Zabbix. Два периода позволяют пережить один пропущенный запрос и не превращают краткий сетевой сбой в аппаратную аварию. Если Вы измените частоту опроса, пересчитайте и nodata().

Не смешивайте отказ охлаждения с потерей резервирования #

LiveThreshold добавляет контроль группы вентиляторов. Здесь нужны два уровня важности.

High назначайте критическому или невосстановимому состоянию охлаждения. Такой сервер может потерять безопасный тепловой режим, поэтому событие уходит дежурному.

Warning подходит для деградации или потери резервирования вентиляторов. Сервер ещё охлаждается, но следующий отказ уже нечем перекрыть. Работу ставят в ближайшее окно обслуживания, а запасную часть — в очередь закупки.

Состояния unknown и notRedundant не повышайте до аварии автоматически. notRedundant может описывать штатную конфигурацию без резервной группы. Сначала проверьте состав вентиляторов и возможности конкретного шасси.

Такая градация понятна и ИТ-службе, и тому, кто согласует расходы:

компонент неисправен, резервирование сохранено — плановая закупка;
резервирование потеряно — ближайшее окно обслуживания;
охлаждение в критическом состоянии — дежурный и немедленная диагностика.

Указывать типовую сумму в рублях здесь нельзя. Цена зависит от модели вентилятора или блока питания, поколения сервера, канала поставки и стоимости простоя. Без этих исходных расчёт выглядел бы точным, но не помог бы согласовать бюджет.

LiveThreshold требует отдельной проверки #

Шаблон Dell iDRAC by SNMP LiveThreshold требует Zabbix 7.0 или новее, интерфейс SNMPv2 и макрос {$SNMP_COMMUNITY}. Его автор проверил базовое дерево OID на PowerEdge T320 с iDRAC7 и T440 с iDRAC9.

Это не означает, что любой PowerEdge вернёт одинаковый набор таблиц. В испытаниях T320 не отдавал таблицу группы охлаждения, а T440 отдавал. Поэтому сначала привяжите шаблон к одному серверу каждого поколения и сравните обнаруженные элементы.

Приёмка по зелёному дашборду ничего не доказывает. Проверьте четыре ситуации:

Выключите операционную систему и убедитесь, что Zabbix продолжает получать аппаратные данные из iDRAC.
Откройте последние значения и проверьте, что у каждого хоста видны собственные температурные границы.
Временно закройте SNMP-доступ и дождитесь отдельного события nodata().
Смоделируйте потерю резервирования охлаждения и убедитесь, что она создаёт Warning, а не High.

Redfish оставьте для второго этапа #

Redfish подходит для автоматизации и событийной интеграции. По документации Dell, API работает через REST, передаёт данные в JSON по модели OData и требует аутентификации и авторизации для чтения телеметрии.

Подписки на события создаются через /redfish/v1/EventService/Subscriptions. Это позволяет получать события без постоянного опроса, но такой канал лучше добавлять после того, как SNMP-мониторинг уже принят и его тревоги понятны дежурным.

Не смешивайте SNMP и Redfish в первой версии. Иначе при расхождении статусов придётся одновременно разбирать датчик, две схемы авторизации и два правила обработки событий.

Рабочий профиль для первого развёртывания выглядит так: официальный SNMP-шаблон на всём парке, LiveThreshold после проверки на каждом поколении, температура раз в 3 минуты, пороги и обнаружение датчиков раз в час, гистерезис 3 °C. Потеря резервирования получает Warning, критический статус охлаждения — High, а прекращение SNMP-опроса создаёт отдельное событие.