Как устроен IPMI-мониторинг серверов: сбор метрик и интеграция с Grafana

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

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

В этой статье расскажем, что такое IPMI-мониторинг серверов и рассмотрим принцип его работы. Также посмотрим, как настроить IPMI-мониторинг для выделенных серверов в Selectel.

Что такое IPMI-мониторинг

IPMI-мониторинг — это данные об аппаратном состоянии сервера. Он контролирует:

• температуру процессоров;

• температуру материнской платы;

• температуру воздуха внутри корпуса;

• напряжение различных линий питания;

• состояние блоков питания;

• скорость вращения вентиляторов;

• энергопотребление;

• аппаратные события и ошибки.

IPMI-мониторинг отвечает на вопрос: «Как чувствует себя железо?». При этом он не покажет, сколько оперативной памяти использует сайт, насколько загружен процессор или насколько заняты диски. Такие метрики относятся уже к мониторингу операционной системы, а IPMI не имеет к ОС доступа и работает независимо от нее.

Отмечу, что сейчас активно развивается другой стандарт — Redfish. Его разработали в 2014 году, поскольку серверы становились все разнообразнее, дата-центры — масштабнее, а требования к безопасности — выше. При этом Redfish не отменяет IPMI, а дополняет его и постепенно становится более современным способом взаимодействия с контроллером управления сервером.

Данные о «железе» и BMC

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

Ключевую роль в этом играет BMC (Baseboard Management Controller) — отдельный микроконтроллер на материнской плате, который:

• собирает данные с компонентов сервера (температура, питание и т. д.);

• позволяет включать, выключать и перезагружать сервер;

• ведет журнал аппаратных событий;

• предоставляет информацию внешним системам мониторинга.

По сути, BMC — это отдельный мини-компьютер внутри сервера. У него есть собственный процессор, память и операционная система, поэтому он продолжает работать независимо от основной ОС. Если сервер завис, не загружается или даже выключен, BMC по-прежнему может собирать информацию о состоянии оборудования и выполнять некоторые команды удаленного управления. 

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

Данные в BMC поступают от датчиков, расположенных на материнской плате и других компонентах сервера. Датчики измеряют физические параметры (например, температуру или напряжение) и передают BMC цифровые значения в виде «сырых» байтов. BMC использует информацию из таблицы SDR (Sensor Data Record), чтобы преобразовать эти значения в понятные физические величины. Для каждого датчика в SDR указаны необходимые параметры и коэффициенты пересчета. В этой же таблице SDR для соответствующих датчиков указаны пороговые значения, например:

• Lower Non-Recoverable,

• Lower Critical,

• Lower Non-Critical,

• Upper Non-Critical,

• Upper Critical,

• Upper Non-Recoverable.

Как только текущее значение пересекает один из этих порогов, встроенная логика BMC мгновенно меняет статус датчика (например, с OK на Critical) и записывает текстовую строку об ошибке в энергонезависимую память — SEL (System Event Log).

Получить данные от BMC можно через различные интерфейсы управления сервером. Помимо стандартных протоколов управления IPMI и Redfish, производители серверов предлагают собственные платформы удаленного управления, которые поддерживают эти стандарты и дополняют их фирменными функциями. Например, у Dell это iDRAC, у HPE — iLO, а у Lenovo — XClarity Controller.

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

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

IPMI-мониторинг в дата-центре

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

На этапе сбора данных с BMC используется наше внутреннее приложение mon-exporter. Оно получает данные с выделенных серверов через интерфейсы управления оборудованием и передает их дальше в систему мониторинга.

За координацию сбора и передачу метрик отвечает VMagent. Он получает данные от mon-exporter и передает их в хранилище временных рядов на базе VictoriaMetrics. Внутри этого контура используются компоненты VictoriaMetrics, отвечающие за прием, хранение и выдачу метрик. 

Далее данные поступают в Grafana^®, где преобразуются в наглядные графики. Это позволяет нашим инженерам визуально оценивать состояние серверов. Для оперативного реагирования на инциденты мы настроили систему оповещений Grafana OnCall^®. Эта система мгновенно доставляет критические уведомления ответственным сотрудникам инженерно-технического отдела. 

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

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

Отдельный компонент системы отвечает за предоставление метрик клиентам. Он управляет доступом к данным с помощью IAM и предоставляет необходимые эндпоинты для взаимодействия с системой мониторинга. Через них клиентские инструменты могут получать метрики своих выделенных серверов и использовать их в собственных сценариях мониторинга. Подробнее о возможностях клиентского доступа и подключении собственных инструментов расскажем далее.

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

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

Как посмотреть данные мониторинга в панели управления

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

У каждого сервера на дашборде можно найти следующую информацию:

• доступен ли BMC и отвечает ли он на запросы;

• состояние накопителей. Тут стоит отметить, что в IPMI-мониторинге отображается только информация о наличии или отсутствии аппаратных ошибок и статус подключения накопителей. Степень износа дисков здесь не отображается — за это отвечают метрики SMART;

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

• состояние подсистемы и линии питания: статус блоков питания, а также показатели напряжения на различных линиях питания (основные и резервные линии, питание процессора и его ядер, оперативной памяти и других компонентов, контролируемых платформой);

• аппаратное состояние компонентов: статус RAM, PCI-устройств, сторожевого таймера Watchdog и многих других.

Набор отдаваемых данных может отличаться от платформы к платформе.

Снижаем цены на выделенные серверы в реальном времени

Успейте арендовать со скидкой до 35%, пока лот не ушел другому.

Подробнее →

Ограничения

Данные IPMI-мониторинга доступны не для всех серверов, так как для их сбора необходим отдельный аппаратный контроллер BMC. В серверах линейки Сhipcore Line такой модуль отсутствует, поскольку это максимально упрощенная конфигурация.

На серверах в А-ЦОД дашборд с метриками также не отображается в панели управления, но уже по другой причине: это полностью изолированная инфраструктура, к BMC которой у Selectel нет доступа. Однако это не означает, что данных нет — они просто не поступают в нашу систему мониторинга и панель управления. При желании такие клиенты могут самостоятельно настроить инфраструктуру и забирать метрики с IPMI-коммутатора в собственную систему мониторинга. 

А если больше чем один сервер? Проверять каждый сервер по отдельности неудобно, поэтому мы работаем над единым разделом Метрики и логи в панели управления. В нем можно будет отслеживать показатели сразу по нескольким продуктам, собирать собственные дашборды и настраивать их под свои задачи. Это позволит быстрее оценивать состояние всей инфраструктуры, не переключаясь между страницами отдельных серверов.

Настройка собственной системы мониторинга на примере Grafana

Панель управления показывает основные показатели состояния оборудования, однако выделенные серверы передают гораздо больше метрик (полный список доступен в Справочнике метрик). Как весь набор метрик, так и его отдельные показатели можно интегрировать в собственную систему мониторинга. Это позволит отслеживать состояние серверного оборудования вместе с другими показателями инфраструктуры. Для этого доступны стандартные способы работы с метриками, которые можно подключать к привычным инструментам мониторинга и визуализации — например, Prometheus^®, VictoriaMetrics, Grafana^®, Telegraf и другим совместимым решениям. 

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

Подключаем метрики выделенного сервера

Для начала выполните первые два шага из инструкции по настройке Grafana^®: добавьте сервисного пользователя и запустите Grafana^®. 

В панели управления создаем сервисного пользователя: IAM → Сервисные пользователи → Добавить сервисного пользователя.

После добавления пользователя и запуска Grafana® необходимо настроить источник данных. Здесь есть важный нюанс: для выделенного сервера в base_url (URL для обращения к API сервиса Метрики) необходимо использовать пул облачных серверов, который соответствует пулу, где расположен ваш выделенный сервер. Полный перечень адресов можно найти в разделе Список URL документации.

Наш подопытный сервер находится в Санкт-Петербурге, в локации SPB-4. В списке URL ищем Санкт-Петербург → Метрики. Видим, что SPB-4 относится к ru-1, используем:

https://ru-1.metrics.selcloud.ru/

В Grafana^® переходим в Connections → Data Sources → Add data source и выбираем Prometheus.

Для подключения понадобятся:

• project_id — ID проекта (в нашем примере — 66ed1f92237b4846bddf18563b11609d);

• user id — ID созданного сервисного пользователя;

• password — пароль сервисного пользователя;

• base_url — URL сервиса Метрики с указанием проекта и пространства имен.

Для нашего тестового сервера итоговый base_url выглядит так:

https://ru-1.metrics.selcloud.ru/projects/66ed1f92237b4846bddf18563b11609d/namespaces/dedicated

Заполним форму Data Sources.

Проверяем, что метрики доступны

Перед настройкой дашборда проверим, что Grafana^® действительно получает данные от BMC. Например, проверим, приходит ли метрика состояния питания. Переходим в Explore → Queries, переключаем режим с Builder на Code и выполняем запрос:

ipmi_chassis_power_state

В результате получаем значение метрики. Достаточно проверить только одну метрику: если пришла одна, то и другие тоже приходят.

Таким образом, мы проверили весь путь от сервера до Grafana^®: данные, собранные системой мониторинга с BMC, доступны через сервис метрики и могут использоваться в Grafana^®.

Импортируем готовый дашборд

Создавать все панели вручную не обязательно. Для мониторинга выделенных серверов мы подготовили готовый дашборд Selectel Bare Metal IPMI в Grafana^®.

На странице дашборда в Grafana^® Labs нажимаем Download JSON, затем в своей Grafana^® переходим в Dashboards → Import dashboard и загружаем полученный файл. 

При импорте выбираем созданный источник данных.

После этого Grafana^® отобразит основные аппаратные показатели сервера. Такой дашборд можно использовать как готовую основу или адаптировать под собственные задачи мониторинга.

Настраиваем первое оповещение

Теперь настроим простое оповещение — будем получать уведомление, если сервер выключен.

Сначала создадим точку доставки уведомлений. Для этого переходим в Alerting → Notification configuration → New contact point и настраиваем нужный канал. В нашем примере используем Telegram.

После этого создаем правило: Alerting → Alert rules → New alert rule. Далее заполняем параметры:

Enter alert rule name:

[IPMI] Сервер выключен более 2 минут

Define query and alert condition:

(max_over_time(ipmi_chassis_power_state[2m]) < 1) and on(resource_id) (max_over_time(ipmi_up{collector="ipmi"}[10m]) > 0)

Также необходимо задать условие Alert Condition → IS ABOVE → -1.

Это условие означает, что правило будет считаться сработавшим, когда результат запроса окажется выше -1. Сам запрос при этом возвращает значение только при выполнении заданного условия — когда сервер находится в состоянии Power OFF и при этом метрики IPMI продолжают поступать. 

Затем создаем отдельную папку для правил:

Add folder and labels → New folder → Monitoring

и группу оценки:

Set evaluation behavior → New evaluation group → IPMI

В разделе Configure notifications включаем переопределение группировки:

Override grouping: On

В поле Group by указываем:

grafana_folder, alertname, resource_id

Такая группировка позволяет объединять связанные уведомления по папке, типу события и конкретному серверу. В результате события от разных серверов не смешиваются в одном уведомлении.

После этого в Configure notifications выбираем созданный ранее контакт TG - Notification.

Для уведомления можно указать:

Summary:

Сервер выключен более 2 минут.

Description:

По данным IPMI-мониторинга сервер с UUID {{ $labels.resource_id }} находится в состоянии «выключен» (Power OFF) более 2 минут.

Сохраняем правило.

Проверяем оповещение

Теперь можно проверить, как оно работает на практике. Выключаем подопытный сервер и наблюдаем за метрикой ipmi_chassis_power_state.

После того как условие правила выполнится, Grafana^® сформирует alert и отправит уведомление в настроенный канал.

В нашем примере уведомление выглядит примерно так:

**Firing**

Value: A=0, C=1
Labels:
- alertname = [IPMI] Сервер выключен более 2 минут
- datacenter = Дубровка-1
- grafana_folder = Monitoring
- location_id = SPB-4
- resource_id = 7882da3d-aca5-4cbc-988c-447fad6366c9
Annotations:
- description = По данным IPMI-мониторинга сервер с UUID 7882da3d-aca5-4cbc-988c-447fad6366c9 находится в состоянии «выключен» (Power OFF) более 2 минут.
- summary = Сервер выключен более 2 минут.
Source: http://localhost:3000/alerting/grafana/dfv1x42m5wl4wd/view?orgId=1
Silence: http://localhost:3000/alerting/silence/new?alertmanager=grafana&matcher=__alert_rule_uid__%3Ddfv1x42m5wl4wd&matcher=datacenter%3D%D0%94%D1%83%D0%B1%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-1&matcher=location_id%3DSPB-4&matcher=resource_id%3D7882da3d-aca5-4cbc-988c-447fad6366c9&orgId=1

На графике при этом будет видно изменение состояния сервера: значение ipmi_chassis_power_state изменится с состояния включенного сервера на состояние Power OFF.

Таким образом, мы самостоятельно настроили полный цикл мониторинга выделенного сервера:

BMC → Сервис Метрик → Grafana^® → Дашборд → Алерт → Уведомление.

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

О способах получения метрик и подключении Prometheus^®, VMAgent, Telegraf, Grafana^® рассказываем в документации Selectel. А о настройке Prometheus^® отдельно рассказали в статье.

Заключение

IPMI-мониторинг позволяет заглянуть «под капот» сервера и оценить метрики в обход операционной системы: температуру, питание, состояние системы охлаждения и другие аппаратные параметры. Эти данные помогают вовремя заметить потенциальные проблемы, разобраться в причинах аппаратных сбоев и принять меры до того, как небольшая неисправность приведет к отказу оборудования.

Теперь для выделенных серверов Selectel все эти данные становятся доступными. Метрики можно передавать в собственную систему мониторинга, настраивать под себя дашборды и оповещения.

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