Сервер 1С завис, ОС перестала отвечать, а обычный мониторинг показывает только пропавший узел. Причина пока неизвестна: отключилось питание, остановился вентилятор или сработала защита от перегрева.
Контроллер BMC работает отдельно от ОС. Поэтому IPMI продолжает отдавать аппаратные метрики, когда сервер выключен, завис или ещё не загрузился. Связка ipmi_exporter → Prometheus → Grafana → Alertmanager помогает узнать причину до поездки в серверную.
IPMI следит за железом, а не за 1С
IPMI получает данные от BMC: температуру, обороты вентиляторов, напряжение, питание и аппаратные события. Работа Linux, PostgreSQL и процессов 1С в этот контур не входит.
Эти уровни дополняют друг друга. IPMI показывает состояние сервера как устройства. Мониторинг ОС и приложений отвечает за память, дисковую нагрузку, сеансы, блокировки и процессы rphost.
| Что произошло | Где искать признак | Метрика |
|---|---|---|
| Prometheus не получил данные от BMC | Доступность сборщика | ipmi_up |
| Сервер выключен | Состояние питания шасси | ipmi_chassis_power_state |
| Вентилятор перешёл в аварийное состояние | Состояние и обороты вентилятора | ipmi_fan_speed_state, ipmi_fan_speed_rpm |
| BMC сообщил о перегреве | Состояние датчика температуры | ipmi_temperature_state |
| Журнал аппаратных событий заполняется | Свободное место в SEL | ipmi_sel_free_space_bytes |
| Нужно увидеть текущее потребление | Данные DCMI | ipmi_dcmi_power_consumption_current_watts |
Вывод: IPMI отвечает за состояние железа. Зависание rphost ищите на уровне служб и рабочих процессов кластера.
Для Linux, PostgreSQL и серверной части 1С нужен отдельный маршрут проверки. Его можно построить по метрикам хоста, СУБД и сеансов 1С.
Один экспортёр опрашивает несколько BMC
Prometheus IPMI Exporter работает по схеме multi-target exporter. Prometheus обращается к пути /ipmi, передаёт цель, а экспортёр опрашивает её BMC по RMCP. Один экземпляр обслуживает несколько серверов.
Prometheus Community указывает порт экспортёра по умолчанию — 9290. Основная реализация опирается на FreeIPMI.
Для удалённого опроса экспортёру нужны утилиты FreeIPMI:
ipmimonitoringилиipmi-sensors;ipmi-dcmi;ipmi-raw;bmc-info;ipmi-sel;ipmi-chassis.
Состав пакетов зависит от дистрибутива. После установки проверьте, что все команды доступны пользователю, от которого запущен экспортёр.
У экспортёра есть обычный путь /metrics. Он показывает данные самого процесса. Аппаратные показатели удалённого сервера приходят через /ipmi.
Сначала подключите один BMC. Так проще проверить доступ, учётную запись, набор коллекторов и реальные названия датчиков.
Экспортёр ставят у сети управления
BMC не нужно открывать для рабочей сети. GSE в схеме мониторинга IPMI и Redfish отделяет сеть управления от производственного контура.
Если Prometheus видит сеть управления, экспортёр можно держать рядом с ним. В другой схеме используют узел мониторинга с двумя интерфейсами: один смотрит к Prometheus, второй — к BMC.
Когда прямого маршрута нет, промежуточный узел опрашивает контроллеры и отдаёт метрики с одного адреса. Рабочие станции при этом не получают доступ к BMC.
| Сетевая ситуация | Где поставить экспортёр | Что проверить |
|---|---|---|
| Prometheus доступен из сети управления | Рядом с Prometheus | Маршрут к каждому BMC и фильтрацию портов |
| Сети мониторинга и управления разделены | На узле с двумя интерфейсами | Запрет транзита из рабочей сети к BMC |
| Прямой маршрут между зонами запрещён | На промежуточном узле у BMC | Доступ Prometheus только к адресу экспортёра |
| Экспортёр работает на самом сервере | На контролируемом узле | Root-доступ и последствия компрометации |
| Экспортёр доступен через общую сеть | В выделенной зоне мониторинга | TLS и базовую аутентификацию |
Вывод: для небольшой инфраструктуры проще удалённо опрашивать BMC с выделенного узла. Локальный сбор IPMI требует root-доступа.
Prometheus IPMI Exporter поддерживает TLS и базовую аутентификацию. Prometheus Community подключает их через параметр --web.config.file. Этот слой защищает вход к экспортёру, но не отменяет разделение сетей.
Учётной записи BMC выдайте права, которых хватает для чтения датчиков. Административный доступ к настройкам питания и сети для мониторинга не нужен.
Сначала проверьте сам сбор
Начните с ipmi_up. По спецификации метрик Prometheus Community значение 1 означает, что коллектор получил данные. Значение 0 указывает на ошибку опроса.
Ноль не доказывает поломку сервера. Причиной может быть недоступный BMC, неверный пароль, сетевой фильтр или ошибка FreeIPMI. Поэтому потерю сбора отделяют от аппаратных аварий.
Следом проверьте ipmi_scrape_duration_seconds. Метрика показывает время получения данных. Рост длительности помогает заметить медленный BMC до полной потери опроса.
Не включайте все коллекторы сразу. Начните с датчиков, состояния шасси, DCMI и SEL. Watchdog и события SEL добавляйте после проверки базового набора.
Такой порядок сокращает число ложных сигналов. Ошибку подключения видно отдельно от странного показания конкретного датчика.
В Grafana нужны состояния, а не склад датчиков
IPMI Exporter отдаёт числовое значение и состояние каждого датчика. Согласно спецификации Prometheus Community, состояния кодируются так:
0— нормальное;1— предупредительное;2— критическое;NaN— состояние недоступно.
Эти значения задаёт BMC. Порог температуры хранится в прошивке контроллера, а не в Grafana.
Не назначайте один предел в градусах для всех серверов. GSE приводит пример: требования к температуре на входе различаются у плотной GPU-стойки и файлового сервера.
| Панель Grafana | Основные метрики | Что считать неисправностью |
|---|---|---|
| Доступность BMC | ipmi_up | Значение 0 после задержки |
| Температура | ipmi_temperature_celsius, ipmi_temperature_state | Состояние 1 или 2 |
| Вентиляторы | ipmi_fan_speed_rpm, ipmi_fan_speed_state | Состояние 2 либо нулевые обороты |
| Напряжение | ipmi_voltage_volts, ipmi_voltage_state | Состояние 1 или 2 |
| Питание шасси | ipmi_chassis_power_state | Значение 0 |
| Текущее потребление | ipmi_dcmi_power_consumption_current_watts | Отклонение от обычного режима конкретного сервера |
| Журнал SEL | ipmi_sel_entries_count, ipmi_sel_free_space_bytes | Снижение свободного места до порога оповещения |
Вывод: сначала стройте панели по состояниям BMC. Числовые графики оставляйте там, где они помогают увидеть изменение до аварии.
Для текущего потребления берите ipmi_dcmi_power_consumption_current_watts. Спецификация IPMI Exporter предупреждает: обычный датчик ipmi_power_watts может не показывать живое потребление.
В каталоге Grafana Labs есть дашборд IPMI for Prometheus, совместимый с ipmi_exporter. Используйте его как заготовку, а не как готовую панель для всех серверов.
Имена датчиков придётся сверить на каждом сервере
Производители и версии прошивок называют одинаковые датчики по-разному. GSE приводит варианты CPU Temp, CPU1_T и Processor 1 для температуры процессора.
Из-за этого общий запрос по имени датчика может пропустить часть серверов. Сначала посмотрите ряды, которые отдаёт конкретный BMC. Затем сопоставьте их с панелями и правилами.
Часть датчиков не несёт пользы. Встречаются отключённые входы, постоянные нули, показатели без единиц и точные дубли.
Удаляйте такие ряды из панелей. Иначе дашборд растёт, а диагностика замедляется: во время сбоя приходится просматривать десятки пустых графиков.
Единицы тоже стоит привести к одному виду. GSE предлагает хранить температуру в градусах Цельсия, напряжение в вольтах, мощность в ваттах, обороты в RPM.
Alertmanager должен различать три типа событий
Аппаратный мониторинг создаёт три разных класса уведомлений:
- Не работает сбор данных.
- Сервер выключен.
- BMC сообщает об аппаратной неисправности.
Смешивать их в одно оповещение нельзя. При ipmi_up == 0 состояние железа неизвестно. При ipmi_chassis_power_state == 0 BMC отвечает и сообщает, что питание выключено.
Набор правил Awesome Prometheus Alerts использует задержку в пять минут для потери коллектора. Она отсекает короткие сетевые разрывы:
- alert: IPMICollectorDown
expr: ipmi_up == 0
for: 5m
labels:
severity: warningОтключение шасси проверяется отдельно:
- alert: IPMIChassisPowerOff
expr: ipmi_chassis_power_state == 0
labels:
severity: criticalКритическое состояние температуры и вентиляторов соответствует значению 2:
- alert: IPMITemperatureSensorCritical
expr: ipmi_temperature_state == 2
labels:
severity: critical
- alert: IPMIFanSpeedSensorCritical
expr: ipmi_fan_speed_state == 2
labels:
severity: criticalДля нулевых оборотов вентилятора Awesome Prometheus Alerts тоже применяет задержку в пять минут:
- alert: IPMIFanSpeedZero
expr: ipmi_fan_speed_rpm == 0
for: 5m
labels:
severity: criticalПредупредительное состояние датчика имеет значение 1. Для температуры, вентиляторов, напряжения, тока и мощности готовые правила выдерживают его пять минут перед отправкой.
Журнал SEL требует отдельного сигнала. В наборе Awesome Prometheus Alerts предупреждение срабатывает, когда ipmi_sel_free_space_bytes остаётся ниже 512 байт пять минут.
Порог 512 байт относится к готовому набору правил, а не к любой модели BMC. Перед включением проверьте размер SEL и поведение контроллера при заполнении.
Обратная логика метрик требует отдельной проверки
Не все аппаратные метрики читаются одинаково. У ipmi_chassis_power_state ноль означает выключенное питание. У состояний датчиков ноль означает норму.
Некоторые метрики шасси используют ещё одну схему. В правилах Awesome Prometheus Alerts значение 0 у ipmi_chassis_drive_fault_state означает ошибку дисковой подсистемы. Такая же логика действует у ipmi_chassis_cooling_fault_state.
| Метрика | Нормальное значение | Аварийное значение | Как использовать |
|---|---|---|---|
ipmi_up | 1 | 0 | Сообщать о потере сбора после задержки |
ipmi_chassis_power_state | 1 | 0 | Сообщать об отключении сервера |
ipmi_temperature_state | 0 | 2 | Разделять предупреждение 1 и аварию 2 |
ipmi_fan_speed_state | 0 | 2 | Проверять вместе с оборотами |
ipmi_chassis_drive_fault_state | 1 | 0 | Не применять логику обычных датчиков |
ipmi_chassis_cooling_fault_state | 1 | 0 | Проверить наличие метрики на своей модели |
Вывод: правило по шаблону metric != 0 для IPMI не работает. Каждую метрику сверяйте со спецификацией экспортёра и фактической выдачей BMC.
Одно событие не должно создавать десятки сообщений
Отказ вентилятора может изменить температуру, питание и несколько связанных состояний. Без группировки Alertmanager отправит отдельное сообщение по каждому ряду.
GSE рекомендует группировать аппаратные уведомления по площадке, стойке и имени правила. Для этого метрикам нужны постоянные метки вроде dc, rack и host.
Не добавляйте изменяющиеся значения в ключ группировки. Температура или имя отдельного датчика раздробят одно событие на несколько уведомлений.
После настройки отключите связь с тестовым BMC. Через пять минут должно прийти одно сгруппированное сообщение о потере сбора. Проверку проводите на согласованном окне работ.
Минимальная схема для первого сервера
Для запуска хватит одного ipmi_exporter рядом с Prometheus и одного BMC как отдельной цели. В Grafana выведите шесть групп данных:
ipmi_up;- питание шасси;
- состояния температуры;
- состояния и обороты вентиляторов;
- текущее потребление DCMI;
- свободное место SEL.
В Alertmanager добавьте потерю сбора на пять минут, выключение шасси и критические состояния датчиков. Нулевые обороты вентилятора держите пять минут перед отправкой.
Перед подключением следующего сервера проверьте три вещи. Метрики должны приходить при недоступной ОС. Grafana должна различать состояния 0, 1 и 2. Потеря связи с BMC должна создавать одно уведомление.
Новый сервер сначала подключайте отдельной целью. Сверьте имена и единицы датчиков, уберите пустые ряды и дубли. Только после этого добавляйте его в общий дашборд.