Bios redfish support что это

Обновлено: 06.07.2024

DMTF's Redfish ® is a standard API designed to deliver simple and secure management for converged, hybrid IT and the Software Defined Data Center (SDDC). Both human and machine readable, Redfish leverages common Internet and web services standards to expose information directly to the modern tool chain. Supermicro enables Redfish feature sets on Intel-based X10 and AMD-based H11 and later generation platforms.

Together, Redfish and Supermicro create a dominant alliance for managing today's heterogeneous hyperscale data center environments with a new management standard for uniform server management and monitoring as scale increases exponentially. Supermicro Redfish APIs support the DMTF Redfish standard for seamless multi-vendor server management experience.

Redfish features and benefits:

Until Redfish, interoperable management standards were lacking for modern data center environments. As organizations shift to scale-out solutions, legacy standards are insufficient to manage numerous simple and multi-node servers or hybrid infrastructures. Today customers demand a well-defined API that uses the protocols, structures and security models that are common in Internet and web services environments. Redfish is the solution that provides a modern interface that builds on widely-used tools to accelerate development.

Supermicro's Redfish solution enables users to program simple configuration and maintenance tasks, reduces vendor lock-in, adds security, increases productivity and plays a significant role to enable next-generation infrastructures.

End-to-end Redfish functionalities are covered under the SFT-DCMS-SINGLE license.

Supermicro Redfish features:

  • Get System/Chassis inventory info
  • Manage user accounts and privileges
  • BMC configuration (AD, LDAP, SNMP, SMTP, RADIUS, Fan mode, Mouse mode, NTP, Snooping, etc.)
  • BIOS configuration
  • Boot order change
  • Storage Management / RAID Configuration (Broadcom 3108, 3008, 3216, 3616 & Marvel SE9230)
  • Get NIC MAC info (NIC asset info)
  • BMC/BIOS/3108 Firmware updates
  • Get thermal/power/sensor info
  • Get system component health (PSU, FAN, Memory, CPU, component change, etc.)
  • Get hostname
  • Launch iKVM/HTML5
  • Update SSL certificate and key
  • BMC configuration reset/BMC reset
  • Get health event log/advanced system event log
  • Acknowledge warning/critical severity events
  • Virtual Media ISO image mounting
  • System power operations and many more
  • KCS Channel privilege control
  • Redfish Secureboot

Supermicro Management Plug-ins

Supermicro offers plug-ins that integrates with management consoles into a customer's existing cloud infrastructure. Take advantage of Supermicro's OEM features through a UI that you are comfortable with.

Licensing: SFT-DCMS-SINGLE required for each target node.

Nagios

Supermicro Management Plug-in for Nagios provides a command line interface for remote management and monitoring of Supermicro server via Redfish. The plug-in can integrate with Nagios Core to monitor server health of the following components:

  • System health
  • Memory
  • Fan sensors
  • Temperature sensors
  • Voltage sensors
  • Power supply
  • Storage

It also provides the following management features:

  • Updating BIOS and BMC firmware
  • Updating BIOS configurations
  • Hardware and firmware inventory
  • Managing event subscriptions

VMware vCenter

The Supermicro Management Plug-in for VMware vCenter is designed to manage and monitor Supermicro servers through Redfish since V2.0.0. The plug-in is integrated with vSphere Client, offering a consistent user experience.

vSphere screenshot

  • Supports HTML5 based vSphere Client *
  • Supports BIOS and BMC firmware update via Redfish

* Since vCenter Server version 6.7.0

Microsoft SCOM

Supermicro Management Plug-in for Microsoft SCOM allows visibility to all Supermicro host systems through Redfish, monitors and manages in the centralized dashboard of Operations Manager console.

В сентябре 2014 года группой компаний — лидеров в производстве серверного оборудования было объявлено о планах заменить протокол управления аппаратными средствами, известный среди ИТ специалистов как Intelligent Platform Management Interface (IPMI). Новому протоколу дали имя Redfish.

Кроме того, эксперты отметили, что пароли хранятся в открытом виде, отсутствует шифрование отдельных разновидностей IPMI-трафика, а утечка одного-единственного пароля означает полный доступ ко всем серверам группы.

Данные причины являются основными для создания нового протокола, отвечающего современным требованиям как в управлении системами, так и в плане безопасности.

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

Среди других принципов, заложенных при проектировании Redfish:


Основные причины для использования RESTful:

1) даёт возможность лёгкой реализации в случаях, когда важна экономия (меньший объём передаваемых данных, чем у SOAP, меньше слоёв протокола, чем в WS-Man);
2) направлен на то, что бы стать самым распространённым методом доступа в промышленности;
3) прост в освоении, доступность документации;
4) есть ряд готовых инструментов и сред разработки, которые могут быть использованы для REST;
5) потребление RAM и СPU меньше, чем у других интерфейсов;
6) он поддерживает семантику модели данных и простое отображение общих операций CRUD;
7) соответствует принципу разработки: простота в пользовании;
8) он в равной мере может быть применён как во встроенных окружениях, так и в пространстве приложений, что даёт возможность сведения воедино кода компонентов в пределах экосистемы управления;
9) он изначально не привязан к схеме, благодаря чему хорошо адаптируется к любому языку моделирования;
10) благодаря ему Redfish возможно использовать для безопасного запуска механизмов в промышленности.

Разделение протокола от модели данных

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

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


Поддержка синхронных и асинхронных операций
Действия

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

В Redfish эти внешние операции называются действиями. Есть определённые действия, заданные в схеме Redfish, которые описывают каждый ресурс. Для этих стандартных действий схема Redfish снабжена нормативным языком. Расширения ОЕМ также разрешены схемой и отнесены к действиям.

Поддержка устройств (консоль, KVM-IP, командная оболочка, виртуальные носители)

В данной архитектуре поддерживается большое разнообразие устройств и служб. Очень важной составляющей являются механизмы поддержки консоли, (KVM-IP), командной оболочки (например, командная строка Linux) и удалённого виртуального носителя. Их поддержка реализована в этом стандарте и выражена в схеме на уровне представления модели данных, однако сами протоколы выходят за рамки этого стандарта.

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

Безопасность


Реализации должны поддерживать TLS v1.1 или выше и использовать только совместимые соединения TLS для транспортировки конфиденциальных данных.

Реализации должны поддерживать AES-256, основанные на TLS. Redfish должны рассмотреть вопрос о поддержке шифров, которые включают проверку подлинности и идентификации без использования доверенных сертификатов: TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM_SHA384.

AES-GCM является не только эффективным и безопасным, его аппаратные реализации могут достичь высоких скоростей при низкой стоимости и латентности.

Реализации должны поддерживать замену сертификата по умолчанию, если он предусмотрен, сертификатом, имеющим как минимум 4096 битный ключ RSA и RSA-SHA512 подпись.

Возможности Redfish

1) модель привилегий для мониторинга и управления;
2) системные настройки;
3) конфигурация BIOS;
4) система управления питанием;
5) информационные датчики (мощности / тепловые / жизнеспособности);
6) настройки сети;
7) настройки памяти;
8) журналирование;
9) служба конфигурации Redfish;
10) управление учётными записями;
11) версии микропрограмм;
12) аутентификация внутри инфраструктуры;
13) совместимость с CURL;
14) Автоматизация клиентов;
15) встроенные служебные процессы.

По заявлениям разработчиков, Redfish будет обладать возможностю управлять не только одной системой но и целыми стеллажами систем. Также Redfish — это своего рода реинкарнация IPMI, и это означает, что при переходе на новую систему пользователь не потеряет ни одной из функций, за которые так полюбилась IPMI. Управление по дополнительному каналу дает возможность производить обслуживание независимо от работоспособности ОС. Он может быть использован для мониторинга или изменения настроек BIOS / UEFI, а также контролировать статистику на уровне системы: температура, напряжение, вентиляторы и источники питания. По свежайшим заявлениям создателей, стандарт находится в стадии разработки и вскоре будет представлен для анализа организации по промышленным стандартам.

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

Все современные процессоры Intel и AMD поддерживают технологию аппаратной виртулизации.
И так, в моем распоряжении был ноутбук с H77 чипсетом и Intel Core i7-3820QM процессором. Согласно спецификации от производителя, мой процессор поддерживал Intel Virtualization Technology (VT-x) и Intel Virtualization Technology for Directed I/O (VT-d) технологии. Если первая имеется почти на всех новых ноутбуках, то вторая технология встречается только на топовых моделях. Но она дает много преимуществ, как например прямой проброс GDU в виртуальную среду, соответственно клиентская машина получает полную поддержку 3D. Но давайте не будем углубляться в технологии, отличные от тематики данной статьи.

В моем биосе была возможность включения VT-x, но вот управление технологией VT-d не было предусмотрено изначально.

В расстроенных чувствах, я стал бродить по разным ресурсам в интернете и наткнулся на два очень интересных ресурса: mydigitallife и bios-mods.

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

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

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

Взяв себя в руки, я решил сам разобраться как этот биос работает и сделать патч самому. Спустя две недели и с помощью русского сообщества IXBT я написал свой первый патч к биосу моего тестового ноутбука. Скрестив пальцы на руках и с замиранием сердца я прошил свой ноутбук…

Вы помните в лохматые годы мы прошивали свои системные блоки новыми биосами для материнских плат? Тогда на экране красовалась надпись, мол ни в коем случае не выключайте компьютер до окончания прошивания? Были случаи, когда по странному стечению обстоятельств именно в тот момент отключалось электричество… В итоге получали большой не функциональный ящик. Что делалось дальше — история умалчивает.

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

Я пошел другим путем: пропатчил те места, которые ну ни как не могли повлиять на функционал биоса, а точнее заменил логотип. Снова прошил и снова получил кирпич. Размышляя и советуясь с опытными дельцами в этом деле мы пришли к выводу, что современные UEFI биосы имеют вторичную проверку на контрольную сумму образа прошивки. Первая проверка происходит когда вы пытаетесь прошить, а вторая когда биос запускается. Если в первом случае я также пропатчил прошивальщик, чтобы он не проверял контрольную сумму, то вторую проверку мне не преодолеть, так как она зашита в самом железе.

На данный момент имеем следующее: Можно патчить EFI биосы и не можем UEFI. Мой, конечно же, второй случай. Опять долгие поиски в интернете и натыкаюсь на статью Enable VT on InsydeH2O based Sony Vaio laptops, the EFI way.
Суть метода проста: вы загружаетесь в EFI режим с помощью специального загрузчика и получаете доступ к VSS памяти, где настройки вашего биоса и хранятся. Я протестировал что на моем ноутбуке это работает, снова открыл прекрассный дизассемблер IDA, скачал последние спецификации и в полном вооружении начал потрошить свой биос.

Успешным результатом двухнедельной работы стало выпотрошенное меню

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

Ну а теперь о том как это сделать вам.

Подготовка инструментария

1. Необходимо скачать PhoenixTool с этого форума, где постоянно выкладывается текущая версия. Он вам будет нужен, чтобы разложить файл прошивки на его составляющие.
2. Вам нужен perl. Если у вас есть UNIX система, то все просто, если нет, то ActivePerl или Cygwin под Windows.
3. Вам нужен последний биос от вашего производителя.
4. Любой архиватор.

Получение образа прошивки


1. Откройте архиватором exe файл вашей прошивки, найдите там файл с расширением bin или fd и распакуйте в удобное для вас место. Лучше в отдельную папку.
2. Запустите PhoenixTool и попробуйте открыть файл прошивки.
3. Если при попытке открыть вы видите такое окно

то скорее всего ваш образ от производителя зашифрован. Decrypt метод пока не придумали, но это только дело времени. Если это ваш случай, то переходите к следующему шагу, если нет, то пропускаем и переходим к пункту 8.
4. Распакуйте программу прошивания в удобную для вас папку и запустите обновление вашего биос до последней версии.
5. После того как ваш ноутбук перезагрузится, снова зайдите в эту папку и найдите там файл platform.ini
6. Откройте текстовым редактором и сделайте слеующие изменения:
Это позволит вам прошить еще раз ваш биос, но при этом будет создана резервная копия текущего биоса.
7. После перезагрузки откройте полученную резервную копию с помощью PhoenixTool
8. Через пару секунд вы должны будете увидеть окошко похожее на это:

9. Теперь можете закрыть окошко.
10. В папке, где у вас лежал образ появится папка DUMP, а в ней множество файлов. Нас интересует, который начинается на FE3542FE и имеет самый большой размер:

11. Теперь скачиваем исходный код моего
Подготовка загрузочной дискеты

1. Берем флешку, размер не важен.
2. Форматируем ее в FAT32
3. Создаем структуру каталогов EFI\Boot
4. Скачиваем BOOTX64.EFI
5. Кладем в папку Boot
6. Перегружаемся в BIOS, включаем Legacy и отключаем Secure Boot.
7. Сохраняемся и загружаемся через флешку.
8. После загрузки вы должны увидеть желтый текст на черном экране

9. К модификации настройки биоса все готово.

Изменение параметров

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

1. Допустим вам надо изменить режим работы диска с IDE на AHCI. Кому-то это надо для хакинтошей, а кто-то купил себе твердотельный жесткий диск, а ноутбук его не видит. Ищем в лог файле что что касается сабжа и находим следующие строки:

Для того чтобы вам изменить настройку, необходимо сперва дать команду setup_var 0x39 .
Результатом данной команды будет текущее значение данной переменной. Чтобы ее изменить и поставить в AHCI, надо дать команду setup_var 0x39 0x1 . Учтите, что если у вас стоит Windows, то потребуется его переустановка, так как однажды настроенный Windows на IDE не сможет понять, что теперь ему надо работать с AHCI. Как вариант — предварительно загрузившись в безопасный режим подредактировать реестр, тогда переустанавливать ничего не придется.

2. Например вам надо запретить дискретный видеоадаптер. За этот пункт отвечает следующие строки:
Команда setup_var 0x1e6 0x0 отключит дискретный и будет работать только встроенный.

3. Хотим чтобы Numlock не включался
Команда setup_var 0x08 0x0 отключит его при загрузке.

Эпилог

Данное руководство составлено как оно есть и так как я делаю это на практике. Я не несу ответственности за испорченные материнские платы или утерянную информацию. Все что мы можете сделать — вы делаете на свой страх и риск.

Если что-то пошло не так, то первым спасательным кругом может быть извлечение батарейки биоса для стирания VSS памяти. Если не помогает, то вам нужно искать способ recovery для вашего биоса. В случае HP инструкцию можно посмотреть здесь. Для других вендоров там же, но я не искал.

Моя тема, где я нет, нет помогаю страждущим находится здесь. Благодарности от пользователей в доказательство тому, что это все работает.

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

И самое последнее, мой вам совет: прежде чем начинать экспериментировать с оверклокингом и тюнингом биоса, проверьте, что для вашего ноутбука работает способ восстановления биоса в случае его краха. Пока таких случаев не было, но мало ли.

На сегодняшний день большинство крупных производителей серверного оборудования, таких как (DELL, IBM, HP) включают поддержку RedFish в прошивки для своих BMC контроллеров (Baseboard management controller) Разумеется, разрабатывая серверы GAGAR>IN, мы также добавили поддержку Redfish в наш BMC, который построен на базе открытого проекта OpenBMC. В этой статье расскажем, для чего мы используем RedFish и какие преимущества он нам даёт.

Redfish - это, как всем известно, спецификация и открытый индустриальный стандарт, который пришёл на смену устаревшему IPMI. Он используется для управления серверным оборудованием посредством RESTful интерфейса. Redfish разрабатывается некоммерческой ассоциацией производителей DMTF (Distributed Management Task Force) с 2014 года и к настоящему моменту достаточно заматерел. Актуальная спецификация Redfish версии 1.12.0 была опубликована 21 января 2021 года.


Если по простому, то весь функционал Redfish можно разделить на две больше группы: мониторинг и управление. Большая часть схемы Redfish содержит информацию об инвентаризации системы и текущем состоянии отдельных компонент. Но есть также множество идентификаторов OData (Open Data Protocol), которые отвечают за управление, изменение настроек BMC/UEFI и выполнение определённых команд. В этой статье мы коснёмся лишь мониторинга.

Мониторинг

В рамках развития системы мониторинга Zabbix, о которой мы писали в предыдущей статье об OCP Experience Lab, стояла задача получения основных параметров работы наших серверов, таких как температура процессоров, потребляемая мощность, токи нагрузки, частоты вращения вентиляторов и т.д. в периоды простоя и максимальной нагрузки.

Среди опрашиваемых машин были как наши собственные серверы GAGAR>IN, так и модели других OCP производителей Wiwynn и MiTAC, произведенные по такой же спецификации Tioga Pass. При этом на серверах GAGAR>IN были установлены BMC контроллеры с прошивкой на основе OpenBMC, а на Wiwynn и MiTAC использовался MegaRAC SP-X от AMI (American Megatrends Inc.).

И GAGAR>IN BMC и AMI MegaRAC SP-X поддерживают RedFish в качестве RESTful веб API для получения данных о сенсорах. Причем обе реализации схемы Redfish минимально отличаются друг от друга, что позволило нам разработать универсальный шаблон для Zabbix. Но начнем с простого.

Модель работы Redfish

Структура дерева ресурсов Redfish

Запрос к корневому элементу дерева ресурсов Redfish возвращает набор элементов "Collections", которые в свою очередь могут содержать подразделы и отдельные конечные элементы. Для реализации Redfish в OCP серверах определены следующие элементы:

Для примера, вышеуказанный запрос на получение основной информации о системе возвращает нам JSON примерно вот такого вида (для краткости приведён небольшой фрагмент):

Но для задач мониторинга нас больше интересуют градусы Цельсия, амперы и вольты, поэтому следующий запрос мы шлём на URI:

В ответ получаем длиннющую "простыню", содержащую информацию о состоянии каждого датчика, установленного в системе, а их у нас в сервере несколько сотен. Привожу пример по одному датчику:

Очевидно, что ReadingCelsius - это текущее значение температуры сенсора для Core 7 CPU1, UpperThresholdNonCritical - это порог высокой температуры, а UpperThresholdCritical - это значение критического состояния. Вот было бы здорово нарисовать эти значения на графике, да еще и генерировать оповещения при превышении UpperThresholdNonCritical. И так для каждого датчика.

Воодушевленные возможностью получения такого огромного массива оперативной информации мы задумались об инструменте для её автоматической обработки. И тут на сцену выходит LLD (low level discovery) от Zabbix.

Низкоуровневое обнаружение в Zabbix

Низкоуровневое обнаружение (Low Level Discovery) даёт возможность автоматического создания элементов данных, триггеров и графиков в Zabbix для различных объектов мониторинга. В нашем случае мы будем создавать элементы данных для каждого датчика, показания которого мы получили в нашем Redfish ответе.

Но вот незадача, мы же не ставим агента Zabbix на BMC. Вместо этого мы хотим парсить ответ на Redfish запрос. Причем Zabbix ждет от нас данные в формате JSON. Но структура этих данных имеет вполне определенный формат который, конечно же отличается от того, что мы получили в Redfish ответе. Что ж, для решения этих задач придется написать пару скриптов!

Скрипты LLD для GAGAR>IN BMC

Но неужели никто до нас не сталкивался с подобной задачей? Быстрый поиск на Zabbix Share показал, что не только сталкивались, но и успешно решали её. В частности удалось найти замечательный фреймворк для DELL iDRAC. Пришлось внести некоторые изменения в скрипты, потому что DELL-овская реализация Redfish отличается от используемой в OpenBMC. В частности идентификаторы OData выглядят следующим образом для разных BMC:

Dell iDRAC: /redfish/v1/Systems/System.Embedded.1/Processors

AMI MegaRAC: /redfish/v1/Systems/Self/Processors

GAGAR>IN: /redfish/v1/Systems/system/Processors

Мы добавили в свои скрипты дополнительный параметр $TYPE, который позволял указывать тип BMC. В зависимости от этого подставлялись правильные идентификаторы OData.

Кроме этого пришлось повозиться с jq - замечательным обработчиком JSON, работающим в командной строке. Например, для получения заветного значения температурного датчика из приведенного выше JSON, пришлось использовать вот такую конструкцию:

cat $ | jq --arg TYPE "$TYPE" --arg NAME "$NAME" '.[$TYPE] | .[] | select(.Name==$NAME)' | jq ".$" | tr -d "'" | tr -d '"'

где BATCH - это имя файла, TYPE = 'Temperatures', NAME = 'Core 7 CPU1', а ITEM = ReadingCelsius. Если кто-то предложит более оптимальный вариант разбора, мы будем очень признательны.

Первый скрипт на Ruby, делая запросы по верхнему уровню схемы Redfish, обнаруживает все доступные группы элементов данных из всех вышеуказанных "Collections": Processors, Memory, Thermal, Power, Sensors. Настраиваем Zabbix на запуск этого скрипта раз в час - мы же не меняем набивку сервера каждые пять минут.

Второй скрипт на Ruby использует выявленные первым скриптом идентификаторы OData (Open Data Protocol) и выполняет по ним отдельные Redfish запросы, после чего сохраняет эти данные локально для дальнейшей обработки. Есть смысл настроить запуск этого скрипта в Zabbix раз в пять минут или даже чаще, если есть желание получить более дискретные графики.

Но стоит учитывать тот факт, что объем хранимых данных в Zabbix вырастет пропорционально, да и poller может не успеть опросить все серверы, особенно если их десятки или даже сотни в дата-центре.

Последний скрипт на простом bash выполняет простую функцию парсера полученного вторым скриптом файла. Он формирует вывод в JSON формате, который может понимать непосредственно Zabbix. Всю остальную красоту рисует для нас Zabbix.

Красивые графики

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

Вольтаж батарейки UEFI. При снижении значения ниже 2.73 вольт, сработает триггер оповещения. TDP первого процессора в Ваттах. При нагрузке на процессор мощность существенно растёт. Температура 15 ядра первого процессора. При превышении 81С сработает триггер.

Что дальше?

В результате мы получили 745 элементов данных, 118 графиков и 355 триггеров для одного GAGAR>IN BMC. Разумеется, мониторинг это не самоцель, поэтому активные триггеры мы оставили для ключевых элементов данных, таких как перегрев процессоров, общий health-статус компонентов и превышение пороговых значений токов.

Набор скриптов и шаблон Zabbix оформлен в отдельный репозиторий на github, а также выложен на Zabbix Share Стрижка, как говорится, только начата, поэтому мы приглашаем всех пользователей оборудования OCP брать наши наработки за основу и дорабатывать их. Некоторые секции данных, такие как, например, Storage и ManagedBy, в наших скриптах не обрабатываются, и будет здорово, если их поддержка будет кем-то добавлена.

В следующей статье напишем, как мы используем Redfish для управления сервером.

Читайте также: