Автор: 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=<span class="m-green">"ipmi"</span>} == 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 и позволяет своевременно реагировать на возникающие инциденты.