Когда в серверной пропадает питание, у ИБП есть считанные минуты, чтобы серверы, виртуальные машины и СХД успели корректно выключиться. Ночью или в выходные сделать это может только автоматика, а ей нужно знать, что ИБП перешёл на батарею и сколько осталось заряда. Этим и занимается мониторинг ИБП.
Стандартный способ получать эти данные по сети — SNMP: по нему уже опрашивают коммутаторы и серверы, так что ИБП встраивается в тот же Zabbix. Для этого в ИБП ставят карту управления, и тут начинаются вопросы.
3 слоя контура
Три слоя контура мониторинга ИБП
Мониторинг ИБП строится как контур из трёх слоёв. Аппаратный слой отвечает за то, откуда берутся данные: карта управления ИБП в слоте или кабель USB. Транспортный — за то, как они доходят: SNMP-опрос, trap-уведомление или протокол Network UPS Tools. Прикладной — за то, кто их интерпретирует и что делает: система мониторинга строит графики и шлёт оповещения, а агенты корректного завершения работы выключают серверы.
Контур ломается по самому слабому слою, и чаще всего этим слоем оказывается сценарий выключения, который никто не проверял. Мониторинг без работающего выключения превращается в подробный журнал аварии.
Аппаратный слой: карта в слоте или USB
Карта управления ИБП встаёт во внутренний слот, получает сетевой адрес и превращает ИБП в сетевое устройство. Опрашивать его может любое число потребителей: система мониторинга, агенты на серверах, консоль виртуализации. USB или serial связывает ИБП ровно с одним хостом. Именно это ограничение — главная причина покупать карту, когда от ИБП питается больше одного сервера.
Транспортный слой: опрос, trap или NUT
SNMP-опрос — это периодический запрос к агенту на карте. Он даёт историю и графики, но реагирует с задержкой до одного интервала опроса. Trap-уведомление карта отправляет сама в момент события, поэтому реакция мгновенная. Зато у trap нет истории, а сам пакет идёт по UDP и может потеряться. Поэтому trap дополняет опрос, а не заменяет его.
Третий вариант — протокол Network UPS Tools (NUT): ИБП подключён к одному хосту, а тот раздаёт состояние остальным. С 2022 года протокол описан в информационном документе RFC 9271.
Прикладной слой: мониторинг и агенты
Здесь важно развести две функции. Система мониторинга собирает значения, хранит историю, считает триггеры и шлёт оповещения. Агент корректного завершения работы по сигналу о разряде гасит сервисы, виртуальные машины, гипервизоры и хранилища. Мониторинг сам ничего не выключает, а агент не хранит историю, поэтому в зрелой инсталляции нужны обе роли.
Выбор карты управления ИБП: что проверить до заказа
SNMP-карта подбирается не к бренду, а к конкретной серии ИБП и к вашему сценарию. Списков совместимых моделей здесь не будет: они быстро устаревают. Лучше покажем, как проверить совместимость самому.
Критерий
Что проверять
Где смотреть
Чем грозит ошибка
Слот и форм-фактор
Тип слота в ИБП и в перечне совместимости карты
Документация на ИБП и на карту
Карта не встаёт или не опознаётся
Версии SNMP
Поддержка SNMPv3 с аутентификацией и шифрованием
Спецификация карты и прошивки
Управление по открытому паролю
Trap
Отправка trap и их настройка
Руководство пользователя карты
Контур только опросный
Веб-интерфейс и журнал
Локальный журнал событий, доступ без мониторинга
Руководство пользователя карты
Нет данных, когда сервер мониторинга недоступен
Датчики среды
Порт и поддерживаемые датчики
Спецификация карты
Нет контроля температуры в стойке
Сеть и доступ
Ограничение адресов, отключение лишних протоколов
Руководство по безопасности карты
Карта открыта всей сети
Прошивка
Актуальная версия и порядок обновления
Сайт производителя
Шаблоны и функции работают частично
Слот и совместимость
Слоты различаются по размеру, разъёму и интерфейсу даже внутри линеек одного производителя. Порядок проверки такой: определить серию ИБП, найти в его документации тип слота, затем сверить перечень заявленных ИБП в документации на карту. Установка SNMP-карты в слот ещё не гарантирует полной функциональности: набор параметров зависит от того, что отдаёт сам ИБП.
Версии SNMP и безопасность управляющего доступа
В SNMP v1 и v2c вся аутентификация сводится к community string — строке, которая идёт по сети открытым текстом. Для чтения этого хватает, а если на карте включена запись, то и для управления, в том числе для команды на отключение нагрузки. Документация NUT прямо предупреждает, что для изменения настроек ИБП и отправки команд, например на отключение питания, нужна community с правом записи. Это ровно тот доступ, который не должен утечь.
SNMPv3 добавляет пользователей, аутентификацию и шифрование по модели USM из RFC 3414. Поэтому для управляющего доступа это выбор по умолчанию. Но SNMPv3 поддерживают не все карты и прошивки, и это нужно проверить по спецификации до покупки.
Обвязка вокруг карты важна не меньше протокола:
-
Карту управления ИБП выносят в выделенный сегмент управления (management VLAN), а не оставляют в общей офисной сети.
-
Учётные данные по умолчанию меняют сразу после установки, до подключения к мониторингу.
-
Неиспользуемые протоколы и запись по SNMP отключают, если они не нужны сценарию выключения.
-
Список адресов, с которых разрешён доступ, ограничивают серверами мониторинга и хостами, где работают агенты корректного завершения работы.
Типовая ошибка: опрос настроили, а заводской пароль веб-интерфейса и community string по умолчанию оставили.
Веб-интерфейс, trap, журнал и датчики
Локальный журнал событий на SNMP-карте переживает недоступность сервера мониторинга, и по нему потом восстанавливают картину аварии. Порт для датчика температуры и влажности пригодится в серверной без отдельной системы контроля среды.
Альтернатива карте: USB и его ограничение
Карта управления ИБП не нужна, если ИБП один, сервер один и централизованного сбора данных нет. Есть и программный обход: хост с физическим подключением к ИБП поднимает Network UPS Tools и раздаёт состояние остальным по сети. У этой схемы есть граница: такой хост становится единой точкой отказа контура и должен выключаться последним.
Интеграция с Zabbix: что должно быть в шаблоне
В официальном репозитории Zabbix есть, например, шаблон для ИБП APC с сетевой картой, и для него Zabbix советует ставить последнюю прошивку карты, иначе шаблон может работать некорректно. Рядом лежат шаблоны сообщества, но Zabbix прямо указывает, что интеграции вендоров и сообщества им не проверяются.
Любой шаблон Zabbix для ИБП привязан к вендору карты, прошивке и версии системы мониторинга. Поэтому полезнее понимать состав шаблона: так проще проверить чужой или собрать свой.
Имена и номера OID, состав MIB, синтаксис выражений и формат макросов различаются между вендорами карт и версиями Zabbix. Всё, что вы берёте из примеров, сверяйте с документацией своего вендора и своей версии Zabbix.
Элементы данных: какие параметры снимать
Параметр
Что показывает эксплуатации
Где используется
Режим работы (сеть, батарея, байпас)
Главный признак события
Событие перехода на батарею
Заряд батареи
Запас энергии
Порог низкого заряда
Остаточное время автономии
Сколько осталось до отключения
Решение о старте выключения
Состояние батареи
Требуется ли замена
Плановая заявка
Нагрузка
Доля от номинала
Событие перегрузки
Входное и выходное напряжение
Качество сети
Анализ частых переходов на батарею
Температура
Условия работы батарей
Контроль старения
OID для каждого элемента данных берётся из MIB-файла производителя карты. Существует и стандартный UPS MIB из RFC 1628, который поддерживают многие карты. Он удобен как общий знаменатель для разнородного парка, но вендорский MIB-файл обычно отдаёт больше параметров. Идентификаторы в вендорских MIB-файлах различаются между производителями и даже между прошивками одной карты.
Триггеры: от перехода на батарею до отказа аккумулятора
Базовый набор событий, на которые стоит реагировать:
-
Переход на батарею. Авария на вводе и начало отсчёта времени.
-
Низкий заряд или малое остаточное время. Сигнал, что пора выключаться.
-
Перегрузка по выходу. Риск, что ИБП отключит нагрузку раньше расчётного времени.
-
Неисправность батареи. Основание для плановой заявки на замену.
-
Недоступность карты. Отдельное событие, о нём ниже.
Срабатывание по низкому заряду в Zabbix не дублирует агент корректного завершения работы. Мониторинг сообщает людям, а агент выключает машины. Если выключение завязать на оповещение из мониторинга, сценарий будет зависеть от того, жив ли сервер мониторинга в момент аварии.
Макросы порогов и правила обнаружения
Пороги выносят в макросы, потому что один шаблон применяется к ИБП с разной нагрузкой и разной реальной автономией. Макрос порога переопределяется на уровне узла, и шаблон Zabbix остаётся общим для всего парка.
Универсальных процентов и минут для порога низкого заряда мы сознательно не приводим. Порог выводится из арифметики конкретной инсталляции: измеренная длительность выключения плюс запас сравниваются с фактическим временем автономной работы. Как это посчитать, разберём в разделе про выключение.
Правила обнаружения нужны там, где ручное перечисление не работает. Это модульные и многоблочные ИБП, трёхфазные конфигурации, несколько батарейных групп и управляемые выходные группы. Правило низкоуровневого обнаружения запрашивает у карты список сущностей и само создаёт для каждой свой набор элементов данных и триггеров.
Доступность карты и обработка trap
Если карта управления ИБП замолчала, это тоже событие. Без отдельной проверки система мониторинга не отличит «всё хорошо» от «ИБП на батарее, а связи с картой нет». Поэтому в шаблон Zabbix добавляют контроль доступности узла и отдельное событие на потерю связи.
Zabbix принимает trap не напрямую. По документации Zabbix 8.0 схема такая: trap принимает snmptrapd, затем Bash- или Perl-скрипт либо SNMPTT записывает его в файл, а процесс SNMP trapper на сервере или прокси Zabbix читает этот файл. Эту подсистему нужно отдельно проверить тестовым trap-уведомлением.
Network UPS Tools: архитектура и когда он уместнее SNMP-опроса
В обзорах NUT обычно упоминают одной строкой в списке «чем ещё можно мониторить ИБП». Но Network UPS Tools решает другую задачу. Zabbix наблюдает и оповещает, а NUT согласованно выключает группу хостов, питающихся от одного ИБП.
Архитектура master/slave, она же primary/secondary
Классическое описание NUT — архитектура master/slave. С версии 2.8.0 роли переименованы в primary и secondary, а старые ключевые слова оставлены для совместимости, но больше не документируются. В старых статьях и конфигах вы встретите оба варианта, суть одна.
По руководству NUT, primary-хост связан с ИБП напрямую: по USB, serial или по сети с картой. На нём работают драйвер ИБП, демон upsd, который раздаёт данные по сети, и upsmon в режиме primary. На остальных хостах работает только upsmon в режиме secondary. По сути это агент корректного завершения работы: он подключается к upsd на primary и получает состояние оттуда.
Отсюда главное следствие архитектуры master/slave: primary выключается последним. Он ждёт, пока secondary-хосты отключатся, и только потом завершает работу сам. Ожидание ограничено таймером HOSTSYNC, чтобы один зависший secondary не держал весь сценарий. Работает и обратная защита: если после критического состояния ИБП secondary не дождался сигнала от primary, он считает primary или канал связи с ним неисправным и выключается сам.
Критическим NUT считает состояние «на батарее и низкий заряд» или флаг FSD — принудительное выключение, которое выставляет primary.
Архитектура Primary и SecondaryКогда NUT уместнее SNMP-опроса, а когда наоборот
NUT уместнее, когда:
-
ИБП подключён по USB или serial, карты нет;
-
карта есть, но нужной версии протокола или функции в ней нет;
-
парк серверов на Linux, и главная задача — согласованно остановить хосты.
SNMP-опрос из системы мониторинга уместнее, когда ИБП несколько и они разнородны, а нужны история, корреляция с другими событиями и единые оповещения. В зрелой инсталляции работают оба инструмента.
С сетевыми картами NUT работает через драйвер snmp-ups. Он поддерживает стандартный UPS MIB из RFC 1628 и ряд вендорских MIB, а начиная с NUT 2.6.2 сам определяет нужный MIB по идентификатору устройства sysObjectID.
Разграничение задач: NUT и SNMPКонфигурация и обязательное тестирование
Конфигурация NUT складывается из четырёх блоков:
-
Описание ИБП и выбор драйвера под модель и способ подключения. Имя драйвера берут из документации NUT и списка совместимости.
-
Параметры демона upsd: на каких адресах и портах он принимает подключения.
-
Учётные записи и права: отдельные пользователи для наблюдения и для команды на выключение.
-
Поведение upsmon на каждом хосте: роль primary или secondary и команда выключения ОС.
Для примера — как роли выглядят в upsmon.conf. Строки взяты из документации NUT 2.8.1 (пакет nut-client в Ubuntu 24.04), формат такой: имя ИБП и хост, число блоков питания этого хоста, запитанных от ИБП, пользователь, пароль и роль.
# на primary-хосте
MONITOR myups@bigserver 1 upswired blah primary
# на остальных хостах
MONITOR myups@bigserver 1 observer abcd secondary
Пользователи и пароли здесь демонстрационные, их задают в upsd.users на primary-хосте.
Проверяют всё это по уровням: primary видит ИБП, secondary видят primary, команда выключения отрабатывает в тестовом режиме на некритичном хосте, затем полный прогон. Типичный провал: состояние ИБП видно везде, а команда на выключение не проходит из-за прав учётной записи.
Документация драйвера snmp-ups предупреждает о важной детали. Последний шаг сценария — команда самому ИБП отключить нагрузку. К этому моменту сетевой стек хоста может быть уже остановлен, и команда до карты не дойдёт. Поэтому последовательность нужно проверить заранее.
Корректное выключение серверов, СХД и гипервизоров
В большинстве материалов сценарий сводится к фразе «агент гасит сервер». На практике инфраструктура — это стек зависимостей, и выключать её нужно по одному правилу: потребитель выключается раньше того, что он потребляет.
Ниже — общий каркас. Детали останова гипервизора, кластера и СХД берите из документации их производителей.
Шаг
Что останавливаем
От чего зависит
Что остаётся работать
1
Сервисы и приложения
От баз данных и хранилищ
Всё ниже
2
Базы данных и очереди
От ВМ и хранилища
ВМ, хосты, хранилище, сеть
3
Виртуальные машины
От хостов виртуализации и хранилища
Хосты, хранилище, сеть
4
Гипервизоры и кластерные службы
От хранилища и сети
Хранилище, сеть
5
Физические серверы без виртуализации
От хранилища и сети
Хранилище, сеть
6
СХД и дисковые полки
От сети управления
Сеть, мониторинг
7
Primary-хост NUT, мониторинг и сеть управления
—
Гаснут последними, вместе с ИБП
Порядок остановки сервисов и зависимости
Порядок остановки сервисов идёт сверху вниз по стеку. Первыми останавливают приложения, иначе они продолжат писать данные, когда нижние слои уже уходят. Затем базы данных и очереди: они закрывают транзакции и сбрасывают буферы на диск. Затем виртуальные машины — штатным завершением гостевой ОС, а не выключением питания ВМ.
Дальше гипервизор: хосты переводят в режим обслуживания, выводят из кластера и останавливают. Только после всех потребителей выключают СХД. Хранилищу нужен сброс кэша на диски, и если выключить его раньше хостов, которые в него пишут, данные на томах окажутся повреждёнными.
Отдельная ловушка — сам сценарий тоже зависит от инфраструктуры. Команде на выключение нужна сеть, состоянию ИБП — primary-хост NUT или карта и сервер мониторинга. Если оркестратор выключения работает как ВМ внутри того же кластера, который он выключает, он рискует погасить сам себя раньше, чем закончит работу. Eaton, например, в документации к Intelligent Power Manager описывает выключение кластера vSAN отдельно для случая, когда консоль IPM и vCenter вынесены за пределы кластера, и для случая, когда консоль или vCenter работают внутри него. Поэтому последними гаснут коммутаторы управляющей сети, primary-хост и система мониторинга, и все они должны быть запитаны от ИБП.
Тайминги и запас времени: считаем от автономии
Универсальных цифр здесь нет, есть методика:
-
Измерить фактическое время автономной работы под текущей нагрузкой. Паспортное значение для этого не годится.
-
Измерить длительность каждого этапа выключения на учебном прогоне и сложить длительности последовательных этапов.
-
Добавить запас на непредвиденное: зависший хост, повторную попытку, медленный сброс кэша.
-
От полученной суммы отсчитать назад момент старта выключения и по нему задать порог низкого заряда или порог по остаточному времени.
Запас пересматривают при росте нагрузки и по мере старения батарей: время автономной работы со временем сокращается, а длительность выключения растёт вместе с числом ВМ.
Проверка обесточиванием и типичные ошибки
Сценарий, который не проверяли реальным обесточиванием, стоит считать неработающим. Учебное отключение проводят в согласованное окно: обесточивают ввод, засекают время, фиксируют длительность каждого шага и доводят прогон до конца, включая запуск после восстановления питания. Обратный запуск ломается не реже прямого: хранилище должно подняться раньше хостов виртуализации, а они раньше ВМ.
Типичные ошибки, которые всплывают на прогонах:
-
Хранилище выключается раньше потребителей, и данные повреждаются.
-
Запас времени нулевой или взят «на глаз», и процедура не успевает завершиться.
-
Сеть или сервер мониторинга не запитаны от ИБП, и команда на выключение никуда не доходит.
-
Единственный агент корректного завершения работы выключает свой хост первым и не успевает разослать команды остальным.
-
Порог низкого заряда задан в процентах без привязки к измеренной автономии.
Эксплуатация контура: проверки, батареи, оповещения
Регулярная проверка сценария
Проверку оформляют как регламентную процедуру: периодичность, ответственный, протокол. В протокол записывают дату, фактическое время автономной работы, длительность этапов, фактический порядок остановки сервисов, отклонения и принятые меры. Внеочередная проверка нужна после замены батарей, ввода новых серверов или ВМ, заметного изменения нагрузки и обновления платформы виртуализации или системы мониторинга.
Контроль батарей и маршрутизация оповещений
Деградация аккумуляторной батареи видна в данных задолго до отказа: сокращается время автономной работы при той же нагрузке, заряд быстрее падает при переходе на батарею, растёт время полного заряда, и в конце концов ИБП сам выставляет признак «требуется замена». Паспортному сроку службы доверять нельзя, ориентир даёт динамика этих показателей. По нашим продажам видно, что батарей для ИБП покупают больше, чем самих ИБП, и планировать эти замены удобнее по истории мониторинга.
Оповещения разводят по адресатам. Переход на батарею и низкий заряд — дежурной смене немедленно. Износ батареи — ответственному за инженерную инфраструктуру, в рабочее время. Недоступность карты — сетевой команде. Оповещения обо всём подряд быстро перестают читать.
Эксплуатация контура: учения, мониторинг АКБ и маршрутизация
Вывод
Мониторинг ИБП надёжен ровно настолько, насколько надёжен его самый слабый слой, и чаще всего это непроверенный сценарий выключения. SNMP-карту берут под серию ИБП и прячут в сегмент управления, Zabbix наблюдает и оповещает, NUT или агент выключают машины, а порог низкого заряда считают от реальной автономии. И всё это хотя бы раз проверяют учебным отключением.
А как у вас: проверяли ли вы сценарий выключения реальным обесточиванием, и что сломалось первым — хранилище, агенты или обратный запуск?
Источник: habr.com