Мониторинг ИБП по SNMP: карта, интеграция с Zabbix и корректное выключение серверов
- Связка «карта — система мониторинга — сценарий выключения»: что она даёт и что настроить обязательно?
- Карта мониторинга: что в ней критично для интеграции и сценария выключения?
- Слотовая карта или внешний адаптер: что меняется для мониторинга
- Версии протокола SNMP, стандартная UPS-MIB и фирменная MIB производителя
- Датчики, поведение при разряде батарей и обновление прошивки карты
- Безопасный доступ к карте: что закрыть до подключения к мониторингу?
- Как интегрировать ИБП с Zabbix: опрос, ловушки и обнаружение?
- Опрос и SNMP-ловушки: что чем закрывать
- Шаблон системы мониторинга и низкоуровневое обнаружение
- Проверка связи с картой и валидация первых значений
- Какие элементы данных и триггеры нужны по ИБП: минимальный рабочий набор?
- Уровень заряда батареи и оставшееся время автономной работы
- Переход на питание от батареи, перегрузка по выходу и состояние байпаса
- Износ и дата замены батареи, температура и влажность
- Пороги срабатывания, задержка триггера и приоритеты
- Уведомления и эскалация: кто узнаёт об аварии питания?
- Как настроить корректное выключение серверов: пороги, порядок и бюджет времени?
- Что считать точкой запуска: процент заряда или остаток автономии
- Бюджет времени: сколько нужно на корректное завершение работы
- Порядок выключения виртуальных машин и хостов, кластера и хранилища
- Кто отдаёт команду: агент корректного выключения, скрипт по событию, фирменное ПО
- Риски преждевременного и запоздалого выключения
- Как проверить, что всё работает: контрольное отключение и учения
- Коротко о главном: что сделать в первую очередь?
Связка «карта — система мониторинга — сценарий выключения»: что она даёт и что настроить обязательно?
Мониторинг ИБП по SNMP состоит из трёх уровней. SNMP-карта мониторинга отдаёт телеметрию источника питания: заряд, нагрузку, состояние входа и выхода.
Zabbix хранит эти данные, сравнивает их с порогами и поднимает тревогу, а отдельный механизм корректного завершения работы гасит виртуальные машины, серверы и хранилище до того, как разрядятся батареи. Zabbix отвечает за наблюдение и эскалацию, но не должен быть единственным исполнителем выключения: если сервер мониторинга или его база недоступны в момент аварии, сценарий не отработает.
Чтобы связка работала, при интеграции ИБП с Zabbix обязательно настраивают три вещи:
- снятие с карты уровня заряда батареи и оставшегося времени автономной работы;
- триггеры на переход на питание от батареи и на достижение порога остатка автономии;
- сценарий корректного завершения работы с проверенным на практике порядком выключения.
Всё остальное — датчики, графики, отчёты — полезно, но вторично. Без этих трёх пунктов мониторинг ИБП по SNMP превращается в красивые графики, которые не спасут данные при аварии.
Карта мониторинга: что в ней критично для интеграции и сценария выключения?
Подбор карты под парк ИБП и бюджет — в том числе выбор между слотовой картой мониторинга и адаптером — подробно разобран в статье как выбрать карту мониторинга для ИБП. Здесь — только свойства, от которых зависят интеграция и автоматическое выключение: что карта отдаёт наружу, по каким версиям протокола SNMP, умеет ли слать ловушки и остаётся ли доступной в последние минуты автономии.
Слотовая карта и внешний адаптер SNMP: что меняется для мониторинга
| Параметр | Слотовая карта мониторинга | Внешний адаптер SNMP |
| Доступ к внутренней телеметрии | Полный набор, данные берутся изнутри ИБП | Зависит от того, какие данные ИБП отдаёт в сервисный порт |
| Зависимость от свободного слота | Нужен штатный слот в ИБП | Слот не нужен, достаточно сервисного порта |
| Доступность при разряде батарей | Питается от ИБП и работает до его отключения | Зависит от того, как организовано питание самого адаптера |
| Входы для датчиков | Есть у части карт | Зависит от модели адаптера |
| Набор параметров | Стандартная UPS-MIB и фирменная MIB производителя | Зависит от протокола сервисного порта |
| Обновление прошивки | Отдельно от прошивки ИБП, через веб-интерфейс карты | Отдельно от прошивки ИБП, через утилиту или веб-интерфейс адаптера |
Слотовая карта или внешний адаптер: что меняется для мониторинга
Слотовая карта мониторинга ставится в штатный слот, получает питание от ИБП и обычно отдаёт полный набор внутренних параметров: состояние батарей, режим работы, фазы, байпас. У неё есть собственный сетевой интерфейс управления, и для системы мониторинга она выглядит как отдельное сетевое устройство.
Внешний адаптер SNMP выручает, когда слота в ИБП нет. Он подключается к сервисному порту и переводит данные в SNMP, но набор параметров и поведение при разряде зависят от реализации. Главное требование и к слотовой карте мониторинга, и к адаптеру одно: устройство должно оставаться доступным в последние минуты автономии, иначе сценарий выключения потеряет источник данных именно тогда, когда он нужнее всего.
Версии протокола SNMP, стандартная UPS-MIB и фирменная MIB производителя
Данные карты описываются моделью данных — MIB, а каждый параметр в ней имеет свой идентификатор OID. Стандартная UPS-MIB описана в RFC 1628: в ней есть общий набор параметров ИБП — состояние батареи, расчётное время до разряда при текущей нагрузке, параметры входа и выхода. Стандартная UPS-MIB даёт переносимость: базовый контроль работает одинаково для карт разных производителей.
Фирменная MIB производителя добавляет специфику линейки: батарейные модули, режимы работы, байпас, фазы, датчики. Практичный подход — строить базовый контроль на стандартной UPS-MIB, а дополнительные показатели брать из фирменной ветки. Точные идентификаторы берут из MIB-файла производителя карты: материал сверен с RFC 1628 и документацией на октябрь 2026 года.
Из версий протокола SNMP предпочтительна третья, с аутентификацией и шифрованием. Старые версии передают строку доступа открытым текстом и допустимы только как вынужденный вариант внутри изолированного сегмента управления.
Датчики, поведение при разряде батарей и обновление прошивки карты
Входы для датчиков превращают слотовую карту мониторинга в источник данных о микроклимате стойки. Датчик температуры и влажности объясняет ускоренную деградацию батарей и ловит проблемы с охлаждением до того, как они приведут к отказу.
Карта должна оставаться доступной до отключения ИБП: если она перезагружается или теряет связь в момент разряда, сценарий выключения работает вслепую. Обновление прошивки карты планируют на окно обслуживания — на время перезагрузки мониторинг и передача событий прерываются.
Примеры в каталоге XCOM-SHOP:
- CyberPower RMCARD205 — слотовая сетевая карта для ИБП CyberPower со слотом SNMP;
- Powercom DA807 — SNMP-адаптер для ИБП Powercom с сетевым слотом;
- Сайбер Электро EMS-U02 — датчик микроклимата для мониторинга ИБП производителя;
- Systeme Electric SE9622 — датчик для систем мониторинга ИБП Systeme Electric.
Карты и датчики работают с ИБП и картами своего производителя: совместимость с моделью и ревизией ИБП проверяйте по таблице производителя.
Безопасный доступ к карте: что закрыть до подключения к мониторингу?
Карта мониторинга — сетевое устройство с доступом к управлению питанием: через неё можно выключить выход ИБП. Поэтому подключать её к системе мониторинга нужно уже настроенной.
Обязательные действия:
- сменить учётные данные и параметры доступа по SNMP, заданные производителем по умолчанию;
- основным режимом сделать версии протокола SNMP с аутентификацией и шифрованием;
- держать сетевой интерфейс управления карты в изолированном сегменте управления без доступа пользователей и Интернета;
- ограничить круг адресов для опроса и входа в веб-интерфейс, использовать HTTPS вместо HTTP;
- выдать системе мониторинга права только на чтение, а управление питанием оставить отдельной учётной записи;
- включить журнал событий и синхронизацию времени, следить за обновлениями прошивки.
Старые версии протокола без шифрования допустимы только как вынужденный вариант — внутри изолированного сегмента и с правами на чтение. Порядок действий сверяйте с документацией производителя карты и руководством по безопасности своей версии Zabbix, рекомендации актуальны на октябрь 2026 года.
Как интегрировать ИБП с Zabbix: опрос, ловушки и обнаружение?
Интеграция ИБП с Zabbix идёт по простой последовательности. В Zabbix создают узел, привязывают к нему SNMP-интерфейс с параметрами доступа третьей версии, подключают шаблон системы мониторинга, а часть сущностей появляется через низкоуровневое обнаружение. Цель — получить показатели, на которых строятся элементы данных и триггеры, а затем и сценарий выключения.
Цепочка данных выглядит так:
- ИБП;
- карта мониторинга со своим сетевым интерфейсом управления;
- изолированный сегмент управления;
- Zabbix — опрос по расписанию и приём SNMP-ловушек;
- элементы данных и триггеры;
- уведомления и эскалация дежурным;
- сценарий корректного завершения работы;
- виртуальные машины, хосты, хранилище.
Опрос и SNMP-ловушки: что чем закрывать
Опрос и SNMP-ловушки решают разные задачи. Опрос — регулярный запрос показателей системой мониторинга: он даёт историю, тренды и динамику разряда. Ловушка — сообщение, которое карта отправляет сама в момент события.
Метрики — заряд, остаток автономии, нагрузку, температуру — собирают опросом, а мгновенные события — пропадание питания, переход на батарею, уход в байпас — дублируют ловушками.
Полагаться только на ловушки нельзя: они идут по UDP, доставка не гарантирована, а карта может перезагрузиться в неудачный момент. Поэтому каждое критическое событие подтверждается опросом, а недоступность самой карты отслеживается отдельным триггером.
Полагаться только на опрос тоже нельзя: короткая авария между двумя циклами останется незамеченной. Поэтому опрос и SNMP-ловушки работают в паре.
Интервал опроса — компромисс. Слишком частый опрос нагружает маломощный контроллер карты, слишком редкий отнимает минуты у сценария выключения. Интервал для ключевых показателей подбирают от бюджета времени на завершение работы, о нём ниже.
Шаблон системы мониторинга и низкоуровневое обнаружение
Шаблон системы мониторинга — заготовка из элементов данных, триггеров и правил обнаружения, которую привязывают к узлу вместо ручной настройки каждого показателя. Низкоуровневое обнаружение само находит переменные сущности — фазы входа и выхода, внешние батарейные модули, порты датчиков — и создаёт для них элементы данных и триггеры по прототипам.
Готовность шаблона под конкретную карту не гарантирована. Список доступных шаблонов смотрите в своей версии Zabbix, а перед использованием сверяйте шаблон системы мониторинга с MIB карты: совпадают ли идентификаторы, перечисления состояний, единицы. Пороги по умолчанию почти всегда приводят к своей инфраструктуре.
Если подходящего шаблона нет, шаблон системы мониторинга собирают сами: элементы данных по стандартной UPS-MIB, дополнительные — по фирменной MIB производителя, сопоставление числовых кодов состояний с понятными названиями, правила обнаружения для повторяющихся сущностей.
Проверка связи с картой и валидация первых значений
Сначала убеждаются, что карта отвечает на опрос с сервера или прокси Zabbix из сегмента управления по третьей из версий протокола SNMP. Затем сверяют значения с дисплеем ИБП и веб-интерфейсом карты: напряжение, нагрузку, заряд, остаток автономии.
Отдельно проверяют единицы измерения и коэффициенты пересчёта — это частая причина «странных» графиков, когда напряжение показывается в десятых долях, а время в секундах вместо минут. Убеждаются, что данные попадают в историю с ожидаемым интервалом и что сетевой интерфейс управления карты не теряет связь под нагрузкой. Пока значения не сверены, строить на них элементы данных и триггеры для автоматики нельзя.
Какие элементы данных и триггеры нужны по ИБП: минимальный рабочий набор?
Задача — не максимальный, а минимальный достаточный набор: показатели, без которых нельзя ни предупредить дежурного, ни запустить сценарий выключения. Часть показателей нужна для тревоги человеку, часть — для автоматического действия, и путать их нельзя.
Минимальный набор наблюдаемых параметров ИБП
| Параметр | Зачем нужен | Логика порога | Ожидаемая реакция |
| Уровень заряда батареи | Страховочный показатель | Ниже страховочного уровня, заданного под свою нагрузку | Тревога, проверка готовности сценария |
| Оставшееся время автономной работы | Основа для запуска сценария | Меньше бюджета выключения плюс резерв | Автоматический запуск выключения |
| Работа от батареи | Первое событие цепочки | Сразу по событию, подтверждение опросом | Уведомление дежурному немедленно |
| Входное напряжение | Качество электросети | Выход за рабочий диапазон с задержкой | Запись в журнал, анализ ввода |
| Нагрузка по выходу | Прогноз автономии | Устойчивый рост выше расчётной | Предупреждение ответственному |
| Перегрузка по выходу | Риск ухода ИБП в защиту | Несколько измерений подряд | Высокий приоритет |
| Состояние байпаса | Нагрузка питается без защиты | Любой внеплановый байпас | Авария, разбор причины |
| Износ и дата замены батареи | Плановая замена | По статусу карты или результату самотестирования | Заявка на замену батарей |
| Температура и влажность | Микроклимат и деградация батарей | Выше порога с гистерезисом | Высокий приоритет |
| Доступность карты | Без неё нет данных для сценария | Несколько неудачных опросов подряд | Высокий приоритет |
Уровень заряда батареи и оставшееся время автономной работы
Процент заряда понятен, но плохо переводится в минуты: при разной нагрузке одинаковый уровень заряда батареи даёт разное время. Оставшееся время автономной работы — расчётная величина самого ИБП для текущей нагрузки. Она ближе к реальности, но это оценка, а не таймер: при росте нагрузки и износе батарей она меняется.
Наблюдают оба показателя. Тревогу и запуск сценария строят на оставшемся времени автономной работы, а уровень заряда батареи держат как страховочный порог на случай, если оценка ИБП окажется оптимистичной.
Переход на питание от батареи, перегрузка по выходу и состояние байпаса
Переход на питание от батареи — первое событие цепочки. Оно доходит до дежурного немедленно и фиксируется в журнале событий, а по частоте переходов видно качество ввода: если ИБП уходит на батарею несколько раз в неделю, проблема в электросети, а не в ИБП.
Перегрузка по выходу означает, что потребление выше расчётного. Автономия окажется короче ожидаемой, а при дальнейшем росте нагрузки ИБП уйдёт в защиту. Состояние байпаса требует отдельного триггера: в байпасе нагрузка питается напрямую от сети без защиты, и длительный внеплановый байпас — авария, а не штатный режим.
Износ и дата замены батареи, температура и влажность
Износ и рекомендуемая дата замены батареи дают предсказуемость: заранее видно, что фактическая автономия начинает расходиться с расчётной. Сменные аккумуляторы подбирают в каталоге аккумуляторных батарей.
Температура и влажность с датчиков объясняют ускоренную деградацию батарей и ловят проблемы с охлаждением стойки до отказа. Высокая температура в серверной сокращает срок службы свинцово-кислотных аккумуляторов, поэтому датчик рядом с ИБП окупается быстрее, чем кажется.
Пороги срабатывания, задержка триггера и приоритеты
Короткие провалы питания и одиночные неудачные опросы не должны поднимать тревогу. Для «мягких» триггеров задают задержку и условие возврата, чтобы событие не мигало при каждом колебании. Для критического порога запуска сценария правило обратное: задержка триггера минимальна, каждая лишняя секунда съедает бюджет времени.
Приоритеты расставляют по последствиям, а не по «громкости» события. Вторичные события одной аварии — низкое входное напряжение, пропадание ввода — делают зависимыми от главного триггера «работа от батареи». Тогда уведомления и эскалация уходят по одному событию, а не лавиной из десятка сообщений.
Уведомления и эскалация: кто узнаёт об аварии питания?
Наблюдение бесполезно, если о событии никто не узнал вовремя. Уровни реагирования выстраивают так:
- информационное событие — фиксируется в журнале;
- переход на питание от батареи — уходит дежурному немедленно;
- приближение к расчётному порогу — тревога с повышенным приоритетом;
- достижение порога — автоматический запуск сценария корректного завершения работы.
Требования к уведомлениям и эскалации: дублирующий канал доставки на случай, если основной недоступен; повторные уведомления при неподтверждённом событии; эскалация на ответственного, если дежурный не отреагировал; подавление лавины однотипных сообщений через зависимости между триггерами. Оповещение не заменяет автоматику: ночью человек может просто не успеть.
Как настроить корректное выключение серверов: пороги, порядок и бюджет времени?
Эта часть переводит телеметрию в проверяемый инженерный регламент: по какому показателю запускать, сколько нужно времени, в каком порядке гасить уровни и кто отдаёт команду.
Приведённая ниже логика — метод расчёта, а не готовые значения. Пороги и порядок сверяйте с руководством производителя ИБП и карты, документацией по завершению работы гипервизора и системы хранения, документацией своей версии Zabbix.
Что считать точкой запуска: процент заряда или остаток автономии
Порог по проценту заряда прост, но обманчив. При выросшей нагрузке и изношенных батареях «20 %» могут означать минуту, а не десять. Порог по оставшемуся времени автономной работы отвечает на нужный вопрос: успеем ли завершить работу.
Надёжная схема запускает сценарий по первому из трёх условий:
- время работы от батареи превысило заданное, а сеть не восстановилась;
- оставшееся время автономной работы стало меньше бюджета выключения плюс резерв;
- ИБП прислал событие «критически низкий заряд» — запуск безусловный.
Первое условие отсекает ожидание при длительной аварии, второе страхует от быстрого разряда, третье — последний рубеж, если оценка ИБП ошиблась.
Бюджет времени: сколько нужно на корректное завершение работы
Бюджет считают методом, а не берут «на глаз». Складывают:
- Реакцию системы мониторинга — интервал опроса плюс задержку триггера.
- Передачу команды агентам на узлы.
- Остановку прикладных сервисов и баз данных.
- Выключение виртуальных машин и хостов гипервизора.
- Корректную остановку систем хранения со сбросом кэша на запись.
- Резерв на старение батарей и погрешность оценки автономии.
Пример логики, не норматив: реакция мониторинга — 1 минута, остановка сервисов и виртуальных машин — 4 минуты, хосты — 2 минуты, хранилище — 1 минута. Итого 8 минут, с резервом 50 % порог запуска — 12 минут остатка автономии.
Сумму сравнивают с фактической автономией при текущей нагрузке, а не с паспортной. Если бюджет не помещается, сокращают время завершения, наращивают автономию батарейными модулями или снижают нагрузку на ИБП.
Порядок выключения виртуальных машин и хостов, кластера и хранилища
Правило «сверху вниз»: сначала прикладной уровень, затем вычислительный, затем хранение и сеть. Порядок выключения виртуальных машин и хостов документируют заранее, вместе с тем, что закладывают по времени на каждый шаг:
- Второстепенные виртуальные машины — тестовые среды, задания резервного копирования, пакетная обработка; время на их штатное завершение.
- Критичные виртуальные машины — прикладные сервисы; время на корректную остановку приложений.
- Машины, от которых зависят остальные, — службы каталога, базы данных, DNS; время на сброс транзакций.
- Хосты гипервизора; кластер переводят в режим без перераспределения нагрузки и учитывают кворум, чтобы выключение узлов не запускало миграцию.
- Сетевое хранилище — только после всех потребителей данных; время на сброс кэша на запись.
- Сеть сегмента управления и контроллер выключения — последними, чтобы команды доходили до конца сценария.
- Отключение выхода ИБП после заданной паузы — это сохраняет остаток батарей и даёт чистый запуск после возвращения сети.
Для серверов с двумя блоками питания от разных ИБП выключение запускают не при переходе одного ИБП на батарею, а когда исправных трактов питания остаётся меньше, чем нужно для нагрузки.
Кто отдаёт команду: агент корректного выключения, скрипт по событию, фирменное ПО
Агент корректного выключения на каждом узле не зависит от системы мониторинга и получает события напрямую от карты. Но его нужно устанавливать и обновлять на всех машинах.
Действие по событию из Zabbix централизованно, но зависит от доступности сервера мониторинга, его базы, сети управления и учётных данных в момент аварии. Фирменное ПО производителя обычно глубже интегрировано с гипервизорами и кластерами, но привязывает к экосистеме вендора. В смешанных Linux-средах используют и открытый набор утилит NUT.
Критичный контур не должен зависеть от единственного исполнителя: основной механизм назначают владельцем сценария, второй оставляют страховкой и проверяют оба на учениях. Контроллер выключения не размещают только внутри кластера, который он должен остановить, — иначе он погаснет раньше, чем закончит работу.
Риски преждевременного и запоздалого выключения
Риски симметричны. Ранний запуск — простой из-за короткого провала, который ИБП пережил бы сам, и подрыв доверия к автоматике: после пары ложных срабатываний сценарий начинают отключать «на всякий случай».
Поздний запуск — жёсткое обесточивание на середине завершения: незакрытые транзакции, повреждённые файловые системы, долгое восстановление. Порог настраивают от измеренного бюджета времени и пересматривают при изменении нагрузки или замене батарей.
Как проверить, что всё работает: контрольное отключение и учения
Систему нельзя считать готовой после появления зелёных графиков. Корректное завершение работы подтверждается только контролируемым испытанием в согласованное окно. Порядок учений:
- Согласовать окно обслуживания и оповестить владельцев сервисов.
- Зафиксировать исходные показатели: уровень заряда батареи, оставшееся время автономной работы, нагрузку.
- Контролируемо снять входное питание ИБП согласованным способом, а не выдёргиванием кабеля.
- Засечь время и наблюдать цепочку событий: ловушку, подтверждение опросом, уведомление.
- Дождаться срабатывания порога и запуска сценария.
- Записать фактическое время завершения каждого слоя — виртуальных машин, хостов, хранилища.
- Вернуть питание и проверить запуск в правильном порядке: сначала сеть и хранилище, затем хосты и сервисы.
После учений сверяют фактический порядок выключения виртуальных машин и хостов с документированным и смотрят журнал событий ИБП и карты, историю показателей и ленту событий в Zabbix, системные журналы серверов, журналы гипервизора и систем хранения, целостность файловых систем и баз данных. Признак штатного завершения — запись о корректном выключении в системном журнале и отсутствие проверок целостности при следующем запуске.
Чек-лист «Учения по сценарию выключения»:
- окно обслуживания согласовано;
- владельцы сервисов оповещены;
- исходные показатели зафиксированы;
- резервные копии актуальны;
- порядок выключения задокументирован;
- фактическое время отработки записано по слоям;
- журналы ИБП, карты, Zabbix и серверов проверены;
- возврат в работу подтверждён;
- дата следующих учений назначена.
Учения повторяют после изменения нагрузки, замены батарей, обновления прошивки карты или версии Zabbix. Фактическое время отработки каждый раз сравнивают с расчётным бюджетом.
Порядок проверки актуализирован: октябрь 2026 года. Идентификаторы и названия элементов интерфейса сверяйте с документацией производителя и своей версией системы мониторинга.
Коротко о главном: что сделать в первую очередь?
Мониторинг ИБП по SNMP работает как цепочка: карта даёт телеметрию, Zabbix превращает её в элементы данных и триггеры, а сценарий корректного завершения работы переводит событие в действие. Запускать выключение надёжнее по оставшемуся времени автономной работы, а не по проценту заряда. Слабое звено связки находят не по документации, а по результатам контрольного отключения.
Подобрать SNMP-карту мониторинга или карту мониторинга под свою серию ИБП, ИБП нужной мощности или батареи под расчётную автономию можно в каталоге XCOM-SHOP:
- аксессуары для ИБП — карты и адаптеры мониторинга;
- ИБП 3000–6000 ВА — для серверной;
Для этой новости пока нет комментариев. Ваш будет первым!





