Автоматизація BMC у 2026: ipmitool, Redfish API, Prometheus і Grafana для hardware-моніторингу

ipmitool та Redfish API: CLI управління BMC та інтеграція в моніторинг

Веб-інтерфейс BMC це зручно для разових задач: зайшов, подивився температуру, перезавантажив сервер, вийшов. Але щойно у вас з'являється більше десяти серверів, або треба інтегрувати BMC-дані у моніторинг, або автоматизувати оновлення прошивок, веб-інтерфейс перестає працювати. Ніхто не буде клікати по десяти окремих сторінках, щоб перезавантажити сотню серверів після вікна планового обслуговування. І ніхто не буде вручну знімати температуру CPU з кожного iDRAC, щоб побудувати графік у Grafana.

Для таких сценаріїв існують два основні інструменти. ipmitool це класичний CLI-клієнт для IPMI-протоколу, який працює з практично будь-яким BMC, випущеним за останні двадцять років. Redfish API це сучасний REST/JSON-стандарт від DMTF, який поступово замінює IPMI у нових інтеграціях. На практиці у 2026 році варто вміти обидва: ipmitool для legacy-заліза і швидких one-liner-ів, Redfish для нових автоматизацій і моніторингу.

1. Чому CLI, а не веб-інтерфейс

Веб-інтерфейс і CLI не конкурують один з одним, це інструменти для різних задач.

Веб зручний для ручного втручання: коли треба один раз щось зробити на одному сервері, коли потрібна візуальна інформація (графіки, топологія), або коли ви не знаєте точно, що вам потрібно, і хочете поклікати по меню. Веб добре працює для новачків, для разових аварійних сценаріїв, для перегляду стану заліза перед прийняттям рішення.

CLI і API потрібні там, де веб перестає масштабуватися. Класичні сценарії:

• Масові операції. Треба перезавантажити 40 серверів після оновлення прошивки комутатора? Через веб це 40 логінів, 40 кліків, 40 підтверджень. Через CLI це одна команда у циклі.
• Збір метрик у моніторинг. Prometheus не вміє клікати веб-інтерфейси. Йому потрібен endpoint, з якого він забиратиме метрики температури, обертів вентиляторів, стану PSU кожні 1-5 хвилин (частіше для BMC зазвичай зайве, бо сам контролер відповідає повільно).
• CI/CD і provisioning. Terraform, Ansible, GitLab CI піднімають новий сервер: PXE-boot, встановлення ОС, налаштування RAID. Все це вимагає програмного доступу до BMC.
• Аудит і compliance. Раз на місяць треба перевірити, що на всіх серверах увімкнено secure boot, встановлені останні прошивки, дефолтні паролі змінені. Через веб це працює у теорії, через API це реальність.
• Аварійна діагностика при повній ізоляції. Веб-інтерфейс BMC іноді сам підвисає (особливо на старших Supermicro), а CLI через SSH або IPMI-over-LAN продовжує працювати.

2. ipmitool: класичний спосіб

2.1 Що це і як воно працює

ipmitool це open-source CLI-клієнт для IPMI-протоколу, який існує приблизно з 2003 року. Написаний на C, працює на Linux, BSD і macOS, підтримує IPMI 1.5 і 2.0. Первинно розроблений Duncan Laurie у Sun Microsystems, згодом переданий спільноті і зараз підтримується на GitHub. Його головна перевага — універсальність: працює майже з будь-яким сервером з BMC, незалежно від вендора.

Є два способи комунікації. З локального Linux-хоста, який стоїть на самому сервері, ipmitool спілкується з BMC через KCS-інтерфейс (Keyboard Controller Style) — це шина всередині заліза, доступ до якої не потребує мережі і пароля. З віддаленого хоста ipmitool робить IPMI-over-LAN на UDP-порт 623 з автентифікацією.

2.2 Встановлення

На Debian/Ubuntu:

sudo apt update
sudo apt install ipmitool

На Rocky Linux / AlmaLinux / RHEL:

sudo dnf install ipmitool

Для локального режиму також потрібен драйвер ядра. У сучасних дистрибутивах (Rocky Linux 9, Ubuntu 24.04 з ядрами 5.x/6.x) достатньо завантажити один модуль:

sudo modprobe ipmi_devintf

Основний драйвер ipmi_si у сучасних ядрах вже вбудований (built-in) і автоматично ініціалізується через ACPI/SMBIOS при завантаженні системи. Якщо ви працюєте на старому дистрибутиві (RHEL 6, старий Debian) або /dev/ipmi0 не з'явився після завантаження ipmi_devintf, спробуйте додатково:

sudo modprobe ipmi_si

Після цього з'являться пристрої /dev/ipmi0 або /dev/ipmidev/0. Щоб драйвер підвантажувався автоматично при завантаженні, додайте ipmi_devintf у /etc/modules-load.d/ipmi.conf.

2.3 Підключення

Локальний режим (з самого сервера, який моніториться):

sudo ipmitool sensor list

Тут ipmitool розмовляє з BMC напряму через KCS, автентифікація не потрібна.

Віддалений режим (з іншої машини по мережі):

ipmitool -I lanplus -H 192.0.2.10 -U admin -P password sensor list

Розбір ключів: -I lanplus означає IPMI 2.0 через LAN з підтримкою шифрування payload через RMCP+ (використовуйте це, а не -I lan, який відповідає IPMI 1.5 — там є MD5-автентифікація, але немає шифрування самих даних, тобто паролі і команди йдуть по мережі у відкритому вигляді), -H це адреса BMC, -U і -P це логін і пароль.

2.4 Основні команди

Сенсори

Повний список усіх сенсорів BMC з поточними значеннями і порогами:

ipmitool sdr list

Фільтр по типу — тільки температури:

ipmitool sdr type Temperature

Аналогічно можна фільтрувати Fan, Voltage, Power Supply, Current. Виведення показує назву сенсора, поточне значення, статус: ok (нормально), nc (non-critical, попередження), cr (critical, критичний перехід порога), nr (non-recoverable, стан за межами відновлення), ns (non-specified, стан не визначений).

Журнал апаратних подій (SEL)

ipmitool sel list

Виводить хронологію подій: старт/зупинку, спрацювання порогів температури, стан PSU, ECC-помилки пам'яті. Якщо журнал заповнився і треба звільнити місце:

ipmitool sel clear

Перед clear варто зберегти вміст у файл (SEL це часто цінне джерело даних для post-mortem-аналізу).

Керування живленням

# Дізнатися поточний стан
ipmitool power status

# Увімкнути (аналог короткого натискання кнопки живлення)
ipmitool power on

# Graceful shutdown через ACPI (аналог короткого натискання)
ipmitool power soft

# Жорстке вимкнення (аналог утримання кнопки живлення 4+ сек)
ipmitool power off

# Warm reset (аналог фізичної кнопки reset)
ipmitool power reset

# Power cycle: жорстко вимкнути, зачекати, увімкнути знову
ipmitool power cycle

Стан шасі

ipmitool chassis status

Показує підсумок: чи увімкнено живлення, чи натиснута кнопка front panel, чи є intrusion-detect (спрацював датчик відкриття корпуса), що спричинило останнє перезавантаження.

Керування самим модулем BMC

Команди mc (Management Controller — власне BMC) керують не сервером, а самим контролером:

# Інформація про BMC: версія прошивки, вендор
ipmitool mc info

# Перезавантажити сам BMC (не сервер, а тільки контролер)
ipmitool mc reset cold

Команда mc reset cold це рятівне коло у сценарії, коли веб-інтерфейс BMC зависає, а сам сервер працює. BMC перезавантажується за 1-3 хвилини, після чого веб-інтерфейс знову доступний. При цьому основна ОС на сервері не помічає нічого.

2.5 Обмеження ipmitool

ipmitool робить свою роботу добре, але у нього є структурні недоліки, які з роками стають дедалі помітнішими:

• Бінарний протокол. IPMI це не текстовий формат, а бінарні структури, які треба інтерпретувати. Помилки у прошивці вендора призводять до незрозумілих повідомлень.
• Нестандартизовані розширення. Кожен вендор додав власні OEM-команди. Один і той самий сенсор на Dell і Supermicro може називатися по-різному, мати різні одиниці виміру, різні пороги.
• Слабка автентифікація. IPMI 2.0 RAKP-протокол має відомі вразливості (CVE-2013-4786), які лишаються актуальними, бо це проблема самої специфікації. Cipher suite 0 взагалі дозволяє з'єднатися без пароля, якщо вендор його не вимкнув.
• Складний парсинг вихідних даних. Виведення ipmitool це текст, стилізований для людини, не для скриптів. Щоб отримати одне число, доводиться писати регулярки або awk-парсери.

Саме тому у 2015 році DMTF запустив Redfish як сучасну заміну.

3. Redfish API: сучасний спосіб

3.1 Що це

Redfish це REST/JSON-стандарт для управління серверною інфраструктурою, розроблений DMTF-консорціумом. Замість бінарних IPMI-пакетів на UDP-порту 623 у Redfish звичайні HTTPS-запити на TCP-порт 443 з JSON-відповідями. Усе, що вміє IPMI (стан сенсорів, керування живленням, virtual media, налаштування BMC), у Redfish доступне через звичайні GET/POST/PATCH-запити.

Головна перевага: уніфікованість. Специфікація описує ієрархію ресурсів (/redfish/v1/Systems, /redfish/v1/Chassis, /redfish/v1/Managers) однаково для всіх вендорів. Один і той самий скрипт з мінімальними правками працює і на iDRAC, і на iLO, і на Supermicro BMC.

3.2 Підтримка на різних поколіннях

Redfish не з'явився миттєво на всьому залізі, це поетапне впровадження:

• Dell iDRAC 7/8: з прошивки 2.40.40.40 (середина 2015), базова підтримка Redfish 1.0
• Dell iDRAC 9: з прошивки 3.00.00.00 (2017), повноцінна підтримка
• Dell iDRAC 10: Redfish це основний API (2024+)
• HPE iLO 4: з прошивки 2.30 (2015), базові endpoint-и
• HPE iLO 5, 6, 7: повноцінна підтримка з першого дня
• Supermicro: X10 з прошивки BMC 3.0, X11+ з першого дня
• ASUS ASMB9, ASMB10-iKVM: повноцінна підтримка
• Lenovo XClarity Controller (XCC): Redfish підтримується з першого релізу на серверах ThinkSystem SR/SD/SN (з 2017 року)

Проста перевірка з командного рядка, чи підтримується Redfish на конкретному BMC:

curl -k https://192.0.2.10/redfish/v1/

Якщо у відповідь приходить JSON з описом сервісу, Redfish працює. Якщо 404, треба перевірити у веб-інтерфейсі, чи ввімкнено сам сервіс.

3.3 Базові запити

Стан системи

curl -k -u admin:password \
  https://192.0.2.10/redfish/v1/Systems/1 | jq

У відповіді: назва моделі, серійний номер, стан живлення (On/Off), кількість CPU, обсяг RAM, стан здоров'я (OK/Warning/Critical). Ключ -k ігнорує самопідписаний сертифікат BMC; у продакшні краще налаштувати довіру до сертифіката BMC у клієнті, а не вимикати перевірку.

Температури і сенсори

curl -k -u admin:password \
  https://192.0.2.10/redfish/v1/Chassis/1/Thermal | jq

Повертає масив об'єктів для кожного температурного сенсора (CPU, чіпсет, ambient, диски) з поточним значенням, критичним і warning-порогом, статусом. Аналогічно /Chassis/1/Power для блоків живлення і споживання.

Керування живленням

Це вже POST-запит з тілом:

curl -k -u admin:password -X POST \
  -H "Content-Type: application/json" \
  -d '{"ResetType": "ForceRestart"}' \
  https://192.0.2.10/redfish/v1/Systems/1/Actions/ComputerSystem.Reset

Значення для ResetType згідно зі специфікацією DMTF: On (увімкнути), ForceOff (жорстке вимкнення), GracefulShutdown (коректне вимкнення через ACPI), GracefulRestart (коректний перезапуск), ForceRestart (жорсткий перезапуск), PowerCycle (вимкнути і увімкнути), Nmi (non-maskable interrupt для дампу стану ядра). Не всі підтримуються на всіх BMC — які саме доступні, можна дізнатися через GET на /Systems/1, там є поле Actions зі списком.

Сесійна автентифікація

Для скриптів, які роблять багато запитів поспіль, замість Basic Auth краще використовувати сесійні токени: один POST для отримання токена, далі всі запити з заголовком X-Auth-Token. Це швидше (BMC не витрачає CPU на перевірку пароля щоразу) і безпечніше (пароль по мережі йде лише один раз при логіні).

# Логін
curl -k -X POST -H "Content-Type: application/json" \
  -d '{"UserName":"admin","Password":"password"}' \
  https://192.0.2.10/redfish/v1/SessionService/Sessions \
  -D headers.txt

# Токен буде у заголовку X-Auth-Token у файлі headers.txt
# Далі всі запити:
curl -k -H "X-Auth-Token: $TOKEN" \
  https://192.0.2.10/redfish/v1/Systems/1

3.4 Порівняння ipmitool vs Redfish

Практичний висновок: ipmitool залишається робочим інструментом для швидких аварійних сценаріїв і для legacy-заліза. Redfish це вибір для нових інтеграцій, для CI/CD і для моніторингу. Для нового коду у 2026 році стартова точка це Redfish, ipmitool як запасний варіант там, де Redfish не підтримується.

4. Інтеграція в моніторинг-стек

Ручні виклики ipmitool і curl добре працюють для діагностики, але для постійного моніторингу треба інша архітектура: exporter збирає дані з BMC, Prometheus їх скрейпить, Grafana візуалізує, Alertmanager шле алерти при переході порогів.

4.1 Prometheus

ipmi_exporter

Офіційний exporter від Prometheus community (prometheus-community/ipmi_exporter). Написаний на Go, всередині використовує FreeIPMI замість ipmitool, хоча принцип роботи такий самий. Основні метрики: температури, обороти вентиляторів, стан PSU, напруги, споживання. Підходить для будь-якого BMC з IPMI 2.0.

Конфіг ipmi_exporter.yml для віддаленого моніторингу кількох BMC:

modules:
  default:
    collectors:
      - bmc
      - ipmi
      - chassis
      - sel
    user: "monitoring"
    pass: "password"  # у продакшні брати з ENV або vault
    driver: "LAN_2_0"
    timeout: 20000

Значення timeout у мілісекундах. 20000ms (20 секунд) це розумний мінімум для сучасних BMC; для повільніших контролерів або старого заліза варто ставити 30000ms. Занадто мале значення призводить до частих таймаутів у scrape-циклі і фейкових алертів про недоступність.

Секція у prometheus.yml з relabel-конфігом:

scrape_configs:
  - job_name: 'ipmi'
    scrape_interval: 60s
    static_configs:
      - targets:
        - 192.0.2.10
        - 192.0.2.11
        - 192.0.2.12
    metrics_path: /ipmi
    params:
      module: [default]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: bmc_host
      - target_label: __address__
        replacement: ipmi-exporter:9290

Ключові метрики (точні назви з офіційної документації prometheus-community/ipmi_exporter): ipmi_temperature_celsius, ipmi_fan_speed_rpm, ipmi_dcmi_power_consumption_current_watts, ipmi_voltage_volts, ipmi_sensor_state (0=nominal, 1=warning, 2=critical, NaN=N/A), ipmi_chassis_power_state (1=on, 0=off), ipmi_up{collector="<NAME>"} (доступність конкретного колектора).

redfish_exporter

Сучасна альтернатива для BMC з підтримкою Redfish. Найпопулярніший форк — jenningsloy318/redfish_exporter, який слухає на порту 9610 (це вибір саме цього форку; офіційний Prometheus port allocation резервує 9618 для іншої реалізації, тож при використанні альтернатив звіряйте документацію). Плюси порівняно з ipmi_exporter: працює через HTTPS, підтримує сесійні токени, не залежить від FreeIPMI, коректно обробляє OEM-розширення для більшості вендорів.

# redfish_exporter.yml
# Примітка: у продакшні паролі підставляти з ENV або vault, а не тримати відкритим текстом
hosts:
  192.0.2.10:
    username: monitoring
    password: password
  192.0.2.11:
    username: monitoring
    password: password
  default:
    username: monitoring
    password: password

Секція у prometheus.yml аналогічна ipmi_exporter, тільки metrics_path: /redfish і replacement: redfish-exporter:9610.

4.2 Zabbix

Zabbix підтримує IPMI-моніторинг з коробки. У панелі керування треба увімкнути IPMI-інтерфейс для хоста, вказати IP BMC, порт 623, credentials. Далі Zabbix використовує вбудовані шаблони (Template Module IPMI) з метриками сенсорів. Це просто, але Zabbix підтримує тільки IPMI 1.5/2.0, не Redfish.

Для Redfish у Zabbix треба використовувати HTTP agent item з ручним налаштуванням URL-запитів і JSON-preprocessing-у. Це не так елегантно, як через exporter, але працює. У Zabbix 6.4+ з'явилися готові шаблони спільноти для Dell iDRAC і HPE iLO через Redfish, які роблять цю частину простішою.

4.3 Grafana дашборди

Готові дашборди зі стандартною візуалізацією можна взяти з Grafana.com. Пошук по «IPMI», «Redfish», «BMC», «Hardware Sensors» дає кілька популярних варіантів з тисячами завантажень. Стандартний набір панелей: температури CPU/чіпсету у вигляді time-series, обороти вентиляторів як барчарт, heatmap серверів у стійці, таблиця критичних SEL-подій за останні 24 години.

4.4 Ключові метрики для моніторингу

Мінімальний корисний набір метрик з BMC для продакшн-моніторингу:

• Температура CPU і материнської плати. Це найраніший індикатор проблем з охолодженням (забитий пилом радіатор, вимкнений вентилятор, помилки сенсорів)
• Обороти всіх вентиляторів. Різке падіння до нуля означає механічну відмову, поступове зростання при стабільному навантаженні — знос підшипників або перегрів у зоні сенсора
• Стан блоків живлення. Redundant-конфігурація з двома PSU має сенс тільки якщо ви бачите, коли один з них відключений (наприклад, від власного UPS). Опитувати можна рідко — раз на кілька годин або двічі на добу, бо стан PSU змінюється не часто
• Загальне споживання у ватах. Корисно і для capacity planning (скільки живлення закладати у стійку), і для виявлення аномалій (раптове зростання може означати поступову деградацію обладнання)
• ECC-помилки пам'яті. Одна помилка, що піддається виправленню (corrected error), на місяць — це нормально; десять на день сигналізує про DIMM, який треба замінити до того, як він перейде у стан невиправних помилок (uncorrected)
• SEL-події з рівнем warning і critical. Це готовий алерт: якщо у SEL з'явився запис про critical, туди варто дивитися негайно
• Доступність самого BMC. Метрика ipmi_up{collector="ipmi"} (або аналогічна для redfish): якщо BMC не відповідає, це або мережева проблема, або сам BMC треба ресетити

5. Підсумок: повна схема автоматизації

ipmitool і Redfish це не питання «або-або», а два інструменти для різних задач у 2026 році:

• ipmitool це швидкий старт: одна команда, широка сумісність з будь-яким BMC за останні 20+ років, універсальний інструмент для аварійних сценаріїв і legacy-заліза. Якщо на новому сервері треба за хвилину подивитися температуру CPU або перезавантажити машину — ipmitool робить це найкоротше.
• Redfish це майбутнє out-of-band автоматизації: єдиний API незалежно від вендора, звичний JSON-формат, HTTPS з TLS 1.2/1.3 замість застарілого RMCP+, готова інтеграція з сучасними інструментами (Ansible має нативні redfish-модулі, Terraform підтримує через провайдерів, Prometheus має exporter). Все нове варто робити на Redfish.

Повна робоча схема моніторингу заліза виглядає так:

• Джерело даних: BMC серверів (iDRAC / iLO / Supermicro BMC / ASUS ASMB) у виділеній management-мережі
• Exporter: redfish_exporter для сучасного заліза, ipmi_exporter як fallback для старих BMC. Обидва запускаються поруч з Prometheus у моніторинговій мережі
• Збір метрик: Prometheus скрейпить exporter-и раз на 1-5 хвилин для типових метрик (температура, вентилятори, споживання); частота залежить від того, як швидко ви хочете дізнаватися про зміни і скільки навантаження готові дати BMC
• Візуалізація: Grafana з готовими дашбордами для hardware sensors, окремі панелі для критичних метрик кожної стійки
• Алерти: Alertmanager реагує на переходи порогів (температура CPU > 85°C протягом 5 хвилин, ECC-помилки > 10 за годину, PSU redundancy loss, ipmi_up{collector="ipmi"} == 0), відправляє у Telegram/Slack і/або PagerDuty для нічних чергових
• Автоматичні дії: для сценаріїв, які можна автоматизувати (наприклад, перезавантаження зависаючого BMC через ipmitool mc reset cold), окремі скрипти або Ansible-playbook-и, які запускаються через webhook, який шле Alertmanager

Результат: замість «я дізнаюся про перегрів CPU з нарікань клієнтів», у вас є алерт за 20 хвилин до того, як CPU почне тротлити. Замість «я не знаю, скільки серверів у стійці треба перевірити після відключення живлення», у вас є список тих, у кого ipmi_up{collector="ipmi"} == 0. Це і є те, заради чого варто інвестувати час у налаштування CLI-автоматизації навіть тоді, коли веб-інтерфейс BMC формально дозволяє те саме.

Часті питання