Мониторинг IPMI и Redfish в Prometheus: алерты и дашборды

Зачем нужен мониторинг железа и что считаем успехом

Большинство аварий начинается не с приложений, а с железа. В сервере растет температура из-за забитых фильтров, вентилятор теряет обороты, один блок питания уходит в отказ, а второй работает на пределе. На уровне ОС это часто видно поздно или не видно вовсе - пока сервер не уйдет в перезагрузку или не начнет троттлить.

IPMI и Redfish полезны тем, что дают телеметрию напрямую с BMC без платных агентов и лицензий. Это важно, когда серверов много, парк однотипный, есть требования к импортозамещению или нельзя ставить софт на хосты. Экспортеры читают датчики, а Prometheus и Alertmanager превращают это в метрики, правила и уведомления.

Успех здесь измеряется не количеством графиков, а тем, насколько быстро и спокойно команда реагирует. Минимальный рабочий результат такой:

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

Роли обычно делят так: админ отвечает за Prometheus, экспортеры и права доступа; инженер ЦОД - за стойки, охлаждение и питание; ИБ утверждает, как безопасно обращаться к BMC; дежурная смена получает алерты и делает первичные проверки.

Простой сценарий: у сервера в стойке один БП выпал, нагрузка на второй выросла, температура внутри поднялась на 8-10 градусов. Если алерт приходит сразу, блок питания можно заменить до остановки сервиса. Это одинаково актуально и для типовых стоечных серверов, и для локально произведенных платформ вроде GSE S200, где удобно быстро подтверждать причину по датчикам, а не гадать по симптомам.

Какие данные дают IPMI и Redfish в реальной жизни

IPMI и Redfish обычно читают данные не с ОС, а с BMC (контроллера управления сервером). Это удобно: метрики доступны даже когда сервер завис, выключен или еще не загрузился. Поэтому мониторинг BMC часто становится базовым слоем для контроля железа.

IPMI дает самый приземленный набор сенсоров, который есть почти везде: температуры по зонам (CPU, входной воздух, корпус), обороты вентиляторов, напряжения и статусы блоков питания, иногда ток и потребление. Еще встречаются простые состояния - открыта ли крышка, есть ли перегрев, сработали ли аппаратные события.

Redfish - современный API, где данные обычно структурированы понятнее: отдельные сущности для шасси, блоков питания, вентиляторов, дисков, сетевых адаптеров, инвентарные поля (серийные номера, модели), события и журналы. Он удобнее, когда нужен не только датчик, но и контекст: какой именно БП отвалился, в каком слоте, и к какому шасси это относится. На новых платформах Redfish часто покрывает больше, чем IPMI.

На практике сырые данные почти всегда сводят к нескольким группам метрик: температуры, вентиляторы, питание (присутствие БП, входное напряжение, статус OK/Fail), общие health-статусы по железу и компоненты, а также счетчики событий или признаки новых аппаратных ошибок.

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

Архитектура без лицензий: как собрать схему целиком

Схема обычно простая: Prometheus забирает метрики у IPMI exporter и/или Redfish exporter, Alertmanager превращает правила в уведомления, Grafana показывает картину в одном месте.

Минимальный набор компонентов:

• IPMI exporter (опрос BMC через IPMI)
• Redfish exporter (опрос BMC по Redfish/HTTPS)
• Prometheus (сбор и хранение)
• Alertmanager (маршрутизация алертов)
• Grafana (дашборды)

Где запускать экспортеры, зависит от сети. Если BMC доступны из зоны мониторинга, экспортеры удобно держать рядом с Prometheus: проще обновлять и отлаживать. Если BMC живут в отдельной management-сети и доступ к ней строго ограничен, экспортеры логичнее ставить ближе к этой сети (например, на узел внутри management VLAN), чтобы не пробивать лишние проходы.

Сети лучше разделять жестко: production (сервисы) не должны ходить в management (BMC). Для мониторинга обычно оставляют ровно один разрешенный маршрут к BMC по нужным портам. Частый вариант - отдельный monitoring-узел с двумя интерфейсами: один в зоне Prometheus/Grafana, второй в management, и только он опрашивает BMC.

Если BMC недоступны напрямую из зоны мониторинга, используйте промежуточную точку: jump-хост или небольшой прокси-узел, который опрашивает BMC и отдает метрики наружу по одному адресу. Например, в стойке с серверами (в том числе rack-серий уровня GSE S200) ставят один прокси в management-сети, а Prometheus скрейпит уже его. Так сохраняется изоляция, но вы не теряете контроль температуры, вентиляторов и питания.

Пошаговый старт: от нуля до первых метрик

Начните с выбора источника. IPMI удобно, когда нужно быстро снять температуры, вентиляторы и питание почти с любого сервера. Redfish чаще дает более ровные и понятные данные на новом железе и лучше подходит, если IPMI ограничен или вы хотите унифицировать сбор с современными платформами. В реальности часто делают гибрид: Redfish как основной, IPMI как запасной.

Перед установкой экспортеров соберите короткую инвентаризацию BMC: адрес, модель сервера, учетку для чтения, сетевой сегмент. Если в стойке стоят, например, GSE S200 Series, полезно сразу фиксировать rack и роль (storage, compute, mgmt), чтобы потом не угадывать в дашбордах.

Дальше идите небольшими шагами:

• запустите IPMI exporter и/или Redfish exporter рядом с Prometheus, чтобы быстро отладить доступы;
• проверьте на 2-3 серверах, что видите базовые метрики: температуры, скорость вентиляторов, состояние БП;
• добавьте scrape job в Prometheus и сразу задайте labels: site, rack, role;
• поставьте разумный интервал (например, 30-60 секунд) и убедитесь, что опрос не грузит BMC;
• после успешной проверки расширяйте список целей на весь парк.

Если метрики не приходят, чаще всего проблема не в Prometheus, а в сети управления, учетке BMC или в том, что на части серверов отключен нужный интерфейс. Сначала добейтесь стабильных данных на нескольких узлах, и только потом масштабируйте.

Нормализация метрик: чтобы алерты не были шумными

Главная проблема "железных" метрик в том, что один и тот же смысл приходит под разными именами и в разных единицах. Если не навести порядок в названиях, лейблах и фильтрации, вы быстро получите поток ложных срабатываний.

Начните с единиц измерения. Температуру держите в градусах C, напряжение - в V, мощность - в W, скорость вентиляторов - в RPM. Если экспортер отдает значения в десятых долях или в милливаттах, поправьте это через recording rules, чтобы алерты и дашборды работали одинаково на разных моделях.

Дальше решите вопрос с именами сенсоров. В IPMI часто встречаются варианты вроде "CPU Temp", "CPU1_T", "Processor 1". В Redfish - "CPU1" или "CPU.Socket.1". Практичный подход: завести словарь соответствий и нормализовать до простых категорий (cpu, inlet, exhaust, vrm, psu) и порядкового номера.

Лейблы нужны, чтобы быстро сузить проблему до стойки и сервиса. Минимальный набор обычно такой: dc (площадка), rack, host, role (db/app/vdi), service (команда или бизнес-сервис).

Отдельно отрежьте мусорные сенсоры: неподключенные (state: unavailable), постоянные нули, датчики без единиц, дубли с одинаковыми показаниями. Хорошее правило: в алерты идут только те сенсоры, которые были валидными хотя бы N минут за последние сутки.

Пороги лучше задавать по роли. Для стойки с плотными GPU-узлами пороги по inlet будут одни, для файлового сервера - другие. Если уверенности нет, начните со статических порогов, а затем добавьте базовый "сам для себя" ориентир: сравнение с собственным baseline (например, p95 за 7 дней плюс запас).

С питанием полезно нормализовать три вещи: статус БП (ok/fail), входную мощность и резервирование. Если redundancy lost, алерт должен быть отдельным и более приоритетным, чем рост потребления. А "AC fail" лучше трактовать как отдельный класс инцидента, чтобы не смешивать его с отказом конкретного PSU.

Минимальные алерты по температуре, вентиляторам и питанию

Минимальный набор алертов должен ловить реальные поломки и не будить из-за секундных всплесков. Удобно держать два уровня: warning (проверить) и critical (действовать сейчас).

Температура: warning vs critical и защита от всплесков

Температура часто скачет при разгоне вентиляторов или короткой нагрузке. Поэтому используйте задержку срабатывания (for) и два порога: предупредительный и аварийный.

- alert: HostTempHighWarning
  expr: (max_over_time(node_hwmon_temp_celsius[5m]) > 75)
  for: 10m
  labels: {severity: "warning"}
  annotations:
    summary: "Высокая температура (warning)"

- alert: HostTempHighCritical
  expr: (max_over_time(node_hwmon_temp_celsius[2m]) > 85)
  for: 3m
  labels: {severity: "critical"}
  annotations:
    summary: "Высокая температура (critical)"

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

- alert: HostTempRising
  expr: (predict_linear(node_hwmon_temp_celsius[30m], 30*60) - node_hwmon_temp_celsius) > 8
  for: 20m
  labels: {severity: "warning"}
  annotations:
    summary: "Температура растет быстрее обычного"

Вентиляторы и питание: отличаем "нет датчика" от аварии

Для вентиляторов важно различать три ситуации: датчик пропал (часто после перезагрузки BMC), вентилятор остановился, обороты устойчиво ниже нормы. Для питания базовые события обычно такие: один БП вышел из строя, потерялась резервируемость, пропало входное питание на линии.

По уведомлениям помогает простая маршрутизация по важности:

• warning: дежурный инженер (проверка в рабочее время)
• critical: дежурный + on-call (немедленно)
• "датчик недоступен": отдельный канал, чтобы не маскировать реальные аварии

Если у вас стойка с серверами GSE, такие алерты обычно быстро показывают типовую картину: один БП отключился, резервирование потеряно, температура начала расти еще до жалоб пользователей.

Настройка Alertmanager: меньше шума, больше пользы

Когда метрики уже попали в Prometheus, самая частая проблема - шквал уведомлений. Цель Alertmanager - один понятный инцидент вместо десятков однотипных сообщений.

Сначала договоритесь о группировке. Если в стойке или сегменте сети массово выросла температура (например, после сбоя кондиционера), полезнее получить одно уведомление на "стойка A2", чем 40 алертов по каждому серверу. Обычно для этого хватает group_by по rack, dc и alertname.

Дедупликация строится на том, что Prometheus присылает одинаковые алерты, а Alertmanager склеивает их в один поток. Практически это значит: ставьте разумные group_wait и group_interval, а repeat_interval делайте длиннее (например, раз в несколько часов), чтобы дежурный не видел одно и то же каждые 5 минут.

Окна обслуживания удобнее всего делать через Silences. Плановая замена блока питания или обновление прошивки BMC на сервере (например, в стойке с GSE S200) не должна поднимать людей ночью. На silences обычно фильтруют по instance, rack или service.

Текст уведомления решает половину задачи. В аннотациях алерта добавьте короткий "автокомментарий": сервер и его расположение (rack/row), сенсор и текущее значение, порог и уровень, подсказку (например, "проверь вентиляторы/БП/впускную температуру").

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

Минимальный набор дашбордов Grafana (5 штук)

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

1. Обзор парка (health). Плитки с количеством серверов в статусах OK, warning, critical по простым правилам: температура, вентиляторы, питание, сенсоры в ошибке. Рядом - таблица топ проблемных хостов.

2. Тепловая карта по стойкам. Матрица, где по каждой стойке показывается максимум температуры на сервер (CPU, inlet, system). Полезно добавить тренд по самому горячему серверу, чтобы заметить деградацию охлаждения заранее.

3. Питание и резервирование. Статус PSU, потеря N+1, а также входная мощность/потребление, если датчики это отдают.

4. Вентиляторы и воздушный поток. Список вентиляторов со статусом non-OK плюс графики RPM по времени для ключевых узлов. Часто видно, как один вентилятор "плавает" задолго до полного отказа.

5. Доступность BMC и экспортеров. Панели по up/скрейпам, длительности опроса и количеству ошибок. Это помогает отличать реальную поломку (сенсор bad) от недоступности BMC по сети или зависшего экспортера.

Чтобы дашборды были удобными, заложите одинаковые переменные и единый подход к группировке: site, rack, host, model; единые пороги warning/critical; отдельные признаки "нет данных" и "сенсор в ошибке" (это разные проблемы); аннотации по алертам; явная подпись источника (IPMI или Redfish).

Безопасность и доступы: как не превратить BMC в уязвимость

BMC (IPMI/Redfish) живет отдельно от ОС, поэтому его легко забыть обновить, закрыть от лишних сетей и ограничить по доступам. Для мониторинга это удобно, но с точки зрения безопасности это один из самых опасных интерфейсов в сервере.

Учетные данные: кто знает пароль и как его менять

Правило простое: доступ к BMC должен быть у минимального круга людей и через сервисные аккаунты, а не личные логины.

Практичный минимум:

• храните пароли в секрет-хранилище, а не в конфиге Prometheus и не в открытых переменных окружения;
• используйте отдельного пользователя только для чтения сенсоров (если поддерживается);
• ротируйте пароли по расписанию и после кадровых изменений;
• отключите или переименуйте дефолтные учетные записи;
• ведите список: какой BMC-аккаунт к какому пулу серверов относится.

Сеть и протоколы: закрываем BMC от всего лишнего

Идеальная схема: BMC находятся в отдельной управляющей сети, а доступ к ним имеет только узел мониторинга (и при необходимости jump-хост администраторов). На межсетевом экране или ACL разрешите соединения только от IP мониторинга к портам IPMI/Redfish. Все остальное запретите.

Если используете Redfish, включайте TLS там, где это возможно. Если часть моделей не умеет нормальный TLS или ломается на старых прошивках, не пытайтесь собрать один универсальный профиль на всех. Разделите конфигурации по типам железа (например, разные job в Prometheus или отдельные настройки экспортера) и зафиксируйте исключения как временную меру с датой пересмотра.

Логи для разбора инцидентов

Логируйте не только алерты, но и качество опроса: таймауты, ошибки аутентификации, скачки задержек, рост числа недоступных BMC. Пример: если в стойке с серверами уровня GSE S200 внезапно пошли таймауты по Redfish сразу на нескольких узлах, это часто не "все сломалось", а перегруженный управляющий коммутатор или неверное правило ACL. По логам экспортера и метрикам опроса это видно быстро.

Частые ошибки и ловушки при внедрении

Самая частая проблема - слишком частый опрос BMC. Кажется логичным собирать метрики каждую минуту, но многие контроллеры начинают отвечать медленнее, дают таймауты или временно блокируют запросы. В итоге графики рваные, а алерты срабатывают из-за сбора, а не из-за железа.

Вторая ловушка - одинаковые пороги для всех серверов. Температуры зависят от модели, прошивки, расположения в стойке и нагрузки. Сервер в верхней части стойки или в горячем коридоре может стабильно быть на 5-10 градусов горячее, и это не авария. Начните с базовых порогов, но оставьте место для исключений по роли или стойке (например, для плотных S200 в одной зоне).

Алерты без задержки и без группировки быстро превращаются в ночной будильник. Вентилятор может кратко прыгнуть в оборотах, датчик питания - дать единичный глитч, сеть управления - на секунду потеряться. Если дергать людей на каждый такой случай, доверие к мониторингу пропадает.

Перед запуском проверьте минимум:

• интервал опроса BMC разумный (часто 2-5 минут хватает);
• есть задержка на алерт (например, держится 5-10 минут);
• алерты сгруппированы по хосту/стойке, а не по каждому сенсору;
• мониторится сам контур: Prometheus, экспортер и сеть управления;
• разделена ответственность: железо отдельно, приложения отдельно.

Еще один типичный провал - смешать железные алерты и алерты приложений в один поток без понятного владельца. Тогда на проблему с блоком питания смотрят разработчики, а на падение сервиса - дежурный по железу. Разведите каналы или хотя бы подпишите маршруты в Alertmanager по командам.

Быстрые проверки перед запуском в прод

Перед продом важнее не просто собрать метрики, а убедиться, что система будет полезной в 3 часа ночи. Эти проверки занимают 30-60 минут, но часто экономят дни разборов после первого инцидента.

Чек-лист готовности

Проверьте пять вещей, которые чаще всего ломаются на старте:

• инвентарь BMC актуален: единый список хостов, логины, сети доступа и процесс добавления нового сервера в день установки;
• три базовых сценария алертов проходят тест: перегрев, отказ блока питания, недоступность BMC (важно не только появление алерта, но и понятный текст и быстрая находка в Grafana);
• есть владелец алертов: кто принимает ночью, кто подтверждает утром, что считается нормой (например, краткий всплеск при перезагрузке);
• дашборды открываются быстро и фильтруются по site, rack, role;
• есть короткий документ с порогами и исключениями по моделям.

Как быстро прогнать тесты

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

Недоступность BMC проверяют временным блоком доступа из сети мониторинга (или выключением интерфейса управления), затем возвратом обратно. Температуру лучше тестировать безопасно: временно снизить порог алерта на 10-15 минут, убедиться в срабатывании и вернуть назад.

Если серверы стоят на нескольких площадках (например, в разных городах Казахстана), заранее проверьте, что теги site и rack заполнены одинаково везде. Иначе фильтры и маршрутизация алертов будут путать дежурных.

Пример из практики: отказ БП и рост температуры в стойке

Стойка на 10 серверов. У каждого по два блока питания (A/B) и BMC с IPMI или Redfish. В обычный день один БП у сервера N7 уходит в отказ, но сервер не падает: питание держит второй канал. Дальше начинается неприятная часть. Через 40-60 минут в стойке растет температура, потому что один из PDU-каналов и кабельная обвязка получают лишнюю нагрузку, а часть вентиляторов начинает крутиться быстрее.

Первый сигнал обычно не про температуру, а про питание: алерт на потерю резервирования. Вместо "PSU redundancy: OK" становится "Degraded" или пропадает один из power_supply_status.

Позже приходит второй алерт: температура в warning. Часто это "Inlet temperature выше порога" или "CPU temp warning" на нескольких серверах сразу. Это важная подсказка: проблема может быть в стойке, а не в одном конкретном хосте.

Дежурный действует по короткому сценарию: открывает дашборд питания и смотрит, где пропала линия A/B; проверяет тепловую карту стойки и понимает, греется один сервер или сразу несколько; сравнивает inlet и внутренние датчики; смотрит скорость вентиляторов (резкий рост на группе серверов обычно означает, что воздух стал горячее).

Если краснеет один хост, чаще всего виноват конкретный БП, вентилятор или радиатор. Если одновременно растут inlet и fan speed у нескольких устройств, ищите причину в распределении питания, airflow (закрытые заглушки, перекрытый забор воздуха), температуре в помещении или перегруженном PDU.

Дальше фиксируются действия: замена БП (возврат "redundancy: OK"), проверка укладки кабелей и воздушных потоков, контроль, что температура вернулась в норму и алерты закрылись сами, а не были просто заглушены.

Следующие шаги: как довести до стабильной эксплуатации

Когда первые алерты уже работают, цель меняется: сделать так, чтобы мониторинг помогал каждый день и не отвлекал. Обычно это про покрытие, понятные пороги и понятный порядок действий.

Дальше имеет смысл расширить источники проблем, которые часто происходят тихо: диски (SMART), состояние RAID-контроллеров и события SEL (журнал BMC). SEL особенно полезен, когда сервер сам перезагрузился или пропадало питание, а в ОС следов почти нет.

Следующий уровень - смотреть не только отдельные серверы, но и стойки и зоны. Массовое ухудшение (например, у 6-10 серверов одновременно растет температура или падает напряжение) должно быть отдельным инцидентом, а не десятью одинаковыми сообщениями. Так быстрее находится причина: охлаждение, PDU, общий контур питания, вентиляция в зале.

Пороги и реакции лучше зафиксировать вместе с теми, кто реально будет реагировать: эксплуатация ЦОД и ИБ. Один и тот же порог может быть нормой для разных моделей, а некоторые действия (например, доступ к BMC) должны быть строго регламентированы.

Практичный минимум для регламента:

• кто принимает алерт и в какие сроки;
• что делать при перегреве, отказе вентилятора, проблеме БП;
• когда переводить в аварийный режим (снижение нагрузки, выключение);
• какие данные прикладывать к заявке (график, SEL-события, модель сервера).

Если вы строите или обновляете серверный парк, мониторинг BMC проще заложить сразу: выделенная сеть управления, учетные записи по ролям, единый шаблон экспорта IPMI/Redfish и тест алертов перед вводом в эксплуатацию.

Для проектов в Казахстане это часто удобнее сделать на этапе поставки и интеграции. Например, при внедрении серверов GSE.kz S200 Series можно заранее согласовать схему BMC-доступов и включить настройку мониторинга в общий план работ, чтобы в проде не возвращаться к этому "задним числом".