Мониторинг и алертинг серверов Supermicro (sensor metrics) через Prometheus

от автора

Автор: DevOps Team Leader компании Hostkey Никита Зубарев

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

У нас возникла необходимость внедрения централизованного механизма опроса IPMI/iDRAC/TP-IPMI для обнаружения перегрева, проблем с системой охлаждения и т. д. и повышения качества предоставляемого оборудования в целом. Проще говоря, мы планируем внедрить систему опроса датчиков с портов управления материнских плат, чтобы оперативно обнаруживать перегрев, неработающие или частично работающие вентиляторы и другие проблемы с охлаждением (например, проверять обороты кулеров или физическое наличие вентилятора в разъеме).

В одной из прошлых статей мы рассмотрели варианты установки федерации Prometheus, Alertmanager и Node Exporter, blackbox_exporter, с использованием Promethus решим и сегодняшнюю задачу.

Напомним, что Prometheus — это система мониторинга и оповещения с открытым исходным кодом, широко применяемая для сбора, хранения и визуализации метрик системы. Она предоставляет мощные возможности для мониторинга разнообразных систем и приложений, в том числе серверов Supermicro с IPMI (Intelligent Platform Management Interface).

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

Клиенты могут использовать для управления арендованным оборудованием сервисную панель управления — invapi.hostkey.com. В ней в разделе управления питанием есть кнопка Sensors, предназначенная для вызова утилиты ipmitool и получения данных датчиков. В связи с этим для сбора метрик с серверов по SNMP можно использовать exporter Prometheus, который будет получать данные через BMC.

Поскольку клиенты самостоятельно администрируют свои серверы и у компании Hostkey нет прямого доступа к ним, данные можно получить только через BMC (Baseboard Management Controller).

Для решения этой задачи мы можем использовать Node Exporter с дополнительным модулем для сбора метрик через IPMI из BMC. Это позволит Prometheus запрашивать и агрегировать данные датчиков (температура, напряжение и т. д.) непосредственно с контроллеров управления серверами.

Основные API-методы управления питанием арендованных серверов описаны в нашей документации.

IPMItool — это утилита для управления и настройки устройств, поддерживающих стандарт IPMI. IPMI — открытый стандарт для мониторинга, регистрации, восстановления, инвентаризации и управления оборудованием, который реализован независимо от основного центрального процессора, BIOS и ОС.

Программа IPMItool предоставляет простой интерфейс командной строки для BMC. Она имеет возможность читать репозиторий данных датчиков (SDR) и печатать показания датчиков, отображать содержимое журнала системных событий (SEL), отображать системную информацию (FRU), управлять LAN и выполнить удаленное управление питанием сервера.

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

ipmitool -I lanplus -H 10.77.0.1 -U ADMIN -P passwd sdr 3VSB             | 3.30 Volts        | ok 5VSB             | 5.10 Volts        | ok VCPU             | 0.97 Volts        | ok VSOC             | 1.02 Volts        | ok VCCM             | 1.21 Volts        | ok APU_VDDP         | 0.92 Volts        | ok PM_VDD_CLDO      | 1.20 Volts        | ok PM_VDDCR_S5      | 1.02 Volts        | ok PM_VDDCR         | 1 Volts           | ok BAT              | 3.20 Volts        | ok 3V               | 3.36 Volts        | ok 5V               | 5.04 Volts        | ok 12V              | 12.10 Volts       | ok MB Temp          | 34 degrees C      | ok Card Side Temp   | 30 degrees C      | ok X570 Temp        | 46 degrees C      | ok DDR4_A1_Temp     | 30 degrees C      | ok DDR4_A2_Temp     | 28 degrees C      | ok DDR4_B1_Temp     | 30 degrees C      | ok DDR4_B2_Temp     | 30 degrees C      | ok Onboard LAN Temp | 32 degrees C      | ok TR1              | no reading        | ns FAN1             | no reading        | ns FAN2             | no reading        | ns FAN3             | 1400 RPM          | ok FAN4_1           | no reading        | ns FAN4_2           | no reading        | ns FAN5_1           | no reading        | ns FAN5_2           | no reading        | ns FAN6_1           | no reading        | ns FAN6_2           | no reading        | ns PSU1 AC lost     | Not Readable      | ns PSU2 AC lost     | Not Readable      | ns PSU1 VIN         | no reading        | ns PSU2 VIN         | no reading        | ns PSU1 IOUT        | no reading        | ns PSU2 IOUT        | no reading        | ns PSU1 PIN         | no reading        | ns PSU2 PIN         | no reading        | ns PSU1 POUT        | no reading        | ns PSU2 POUT        | no reading        | ns PSU1 Status      | 0x00              | ok PSU2 Status      | 0x00              | ok PSU1 Temp        | no reading        | ns PSU2 Temp        | no reading        | ns PSU1 Fan         | no reading        | ns PSU2 Fan         | no reading        | ns PSU1 Fan Status  | Not Readable      | ns PSU2 Fan Status  | Not Readable      | ns CPU_PROCHOT      | 0x00              | ok CPU_THERMTRIP    | 0x00              | ok ChassisIntr      | 0x00              | ok CPU Temp         | 35 degrees C      | ok

Доступны следующие сборщики, которые можно включить или отключить в конфигурации:

  • sensor: собирает данные датчиков IPMI;

  • fwum: собирает данные прошивки;

  • fru: собирает данные BMC.

Мы взяли за основу готовый exporter и доработали его, так как внутреннюю разработку ведем на языке golang.

Он поддерживает как обычную /metrics — конечную точку, предоставляющую метрики с хоста, на котором работает экспортер, так и конечную /ipmi — точку, которая поддерживает IPMI через RMCP — один экспортер, работающий на одном хосте, может использоваться для мониторинга большого количества интерфейсов IPMI путем передачи target параметра.

Для сбора удаленных метрик через IPMI-конфигурация должна содержать учетные данные для доступа к серверам — имена пользователей и пароли. Иными словами, нужно указать логины и пароли (login/passd) для IPMI-интерфейса каждого сервера.

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

Приложение будем запускать в докере, вот его dockerfile:

FROM golang:1.16 ADD . / /build/ WORKDIR /build RUN CGO_ENABLED=0 GOOS=linux go build -a -o ipmi_exporter .  FROM alpine:latest RUN apk --no-cache add ipmitool WORKDIR /root/ COPY --from=0 /build/ipmi_exporter ./ COPY ipmi_remote.yml ./ CMD ["./ipmi_exporter", "--config.file", "ipmi_remote.yml", "--web.listen-address=:9104"]

Развертывание оформили на Ansible:

Конфигурации prometheus:

 - job_name: ipmi     metrics_path: /ipmi     scrape_interval: 30m     scrape_timeout: 2m     static_configs:     file_sd_configs:     - files:       - 'targets_ipmi.json'     relabel_configs:       - source_labels: [__address__]         target_label: __param_target       - source_labels: [__param_target]         target_label: instance       - target_label: __address__         replacement: host:9104

Обратим внимание на files:

  

  — ‘targets_ipmi.json’

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

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

 Метрика по хосту, ниже рассмотрим наиболее интересные параметры.

Наиболее интересные метрики:

# HELP ipmi_fan_speed_state Reported state of a fan speed sensor (0=ok, 1=critical, 2=non-recoverable, 3=non-critical, 4=not-specified). # TYPE ipmi_fan_speed_state gauge ipmi_fan_speed_state{name="FAN1"} 0 ipmi_fan_speed_state{name="FAN2"} 0 ipmi_fan_speed_state{name="FAN3"} 0 ipmi_fan_speed_state{name="FAN4"} 0  # HELP ipmi_power_state Reported Chassis Power State (0=off, 1=on). # TYPE ipmi_power_state gauge ipmi_power_state{name="PowerState"} 1  ipmi_sensor_value{name="CPU1Temp",type="degreesC"} 53 ipmi_sensor_value{name="CPU2Temp",type="degreesC"} 59  # TYPE ipmi_up gauge ipmi_up{collector="fwum"} 1 ipmi_up{collector="sensor"} 1 # HELP ipmi_voltage_state Reported state of a voltage sensor (0=ok, 1=critical, 2=non-recoverable, 3=non-critical, 4=not-specified). # TYPE ipmi_voltage_state gauge ipmi_voltage_state{name="1.05VPCH"} 0  # TYPE ipmi_fwum_info gauge ipmi_fwum_info{firmware_revision="3.910000",manufacturer_id="10876.000000"} 1

Кроме мониторинга железа и оповещений о критических ситуациях система на базе Prometheus позволяет отслеживать актуальность прошивок и появление обновлений. Можно настроить дополнительные оповещения о выходе новых версий встроенного ПО для компонентов серверов Supermicro.

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

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

Осталось повесить алертинг на alermanager, для этого описываем правила и подключаем на prometheus:

  ipmi_exporter.yml  groups: - name: ipmi   rules:   - alert: InstanceDown     expr: up{job="ipmi"} == 0     for: 5m     labels:       severity: page     annotations:       summary: "Instance {{ .instance }} down"       description: "{{ .instance }} of job {{ .job }} has been down for more than 5 minutes."    - alert: CPUTemp ipmi_sensor_value     expr: ipmi_sensor_value{name="CPUTemp",type="degreesC",job="ipmi"} > 60     for: 1m     labels:       severity: page     annotations:       summary: "High CPUTemp usage more 30 degreesC"       description: "High CPUTemp usage more 30 degreesC"   - alert: ipmi_power_state     expr: ipmi_power_state{job="ipmi"} == 0     for: 1m     labels:       severity: page     annotations:        summary: "Chassis Power State OFF"   - alert: ipmi_up     expr: ipmi_up{job="ipmi"} == 0     for: 1m     labels:       severity: page     annotations:       summary: "IPMI device not collect sensor"

Заключение

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

Настройка правил и алертов в Prometheus позволяет получать оповещения о критических ситуациях, таких как перегрев компонентов или отказ вентиляторов. А визуализация метрик в Grafana дает наглядное представление о текущем состоянии и нагрузке на серверы.

Таким образом, использование Prometheus для мониторинга и алертинга Supermicro серверов дает ряд преимуществ: высокую доступность инфраструктуры, быстрое оповещение о проблемах, удобство визуализации данных. Это повышает надежность работы серверов Supermicro и позволяет своевременно реагировать на возникающие инциденты.


ссылка на оригинал статьи https://habr.com/ru/companies/hostkey/articles/750684/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *