Zabbix, как SCADA для мониторинга электропитания ЦОДа

Разрыв между Modbus и SNMP: ключевая причина слепых зон в мониторинге.

По данным Uptime Institute, до 37% крупных аварий ЦОДов происходят из-за отказов в силовой инфраструктуре, при этом в большинстве случаев IT-отдел не имел данных о состоянии питания в момент инцидента, а реагировал уже на последствия. В отчётах за 2022–2024 годы подчёркнуто: главная причина затянувшихся простоев — отсутствие у IT прозрачного мониторинга наличие напряжения на вводах ЦОДа, состояние и работоспособность АВР, автоматов и источников питания. В стрессовых ситуациях и при дефиците времени критичным становится не столько сам факт того, что «упал коммутатор» или «недоступен IT-сервис», а понимание первопричины, то есть почему это произошло. Без ясности, что именно вызвало инцидент — сетевой сбой, железо, перегрузка питания, отказ ИБП или отключившийся автомат — эксплуатация действует вслепую, теряя время и деньги.

Но, если причина известна, IT-отдел из режима «тушим пожар вслепую» переходит в режим управляемого инцидента.

Появляется возможность:

• быстро оценить масштаб проблемы и риски для других сервисов;

• принять осознанное решение: перезапуск, перевод нагрузки, ручной обход, переключение на резерв;

• сократить количество выездов «наугад» и время простоя до минимума.

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

Неудивительно, что мировой тренд последних лет — IT/OT Convergence, то есть объединение технологической (OT) и IT-инфраструктуры в единое поле наблюдаемости. Cisco, Schneider, Eaton, Vertiv и другие производители напрямую заявляют: без передачи данных о питании в SNMP-экосистему невозможно обеспечить фактический SLA, а разделение зон ответственности между IT и АСУТП является источником рисков, финансовых потерь и неэффективных выездов на объекты.

Современные ЦОДы и промышленные объекты живут в условиях, где простои стоят дорого, а ответственность за доступность систем ложится на IT-эксплуатацию. Однако IT по-прежнему видит только сетевую часть — то, что «говорит» на SNMP. При этом, силовая инфраструктура работает на Modbus, который IT-подразделения не принимают, не хотят поддерживать и не считают «своим» протоколом, что создаёт критическую информационную разрывность. Именно из-за этого возникает самая опасная эксплуатационная ситуация — слепые зоны в мониторинге электропитания, когда IT видит последствия (обрыв связи, падение PoE, сбой оборудования), но не видит первопричину (отключение автомата, отказ ИБП, потеря ввода, перегрев).

Поэтому сегодня ключевая задача — устранить разрыв между Modbus и SNMP, предоставив IT-эксплуатации полноценную картину состояния электропитания в привычных инструментах мониторинга. Пока силовое оборудование не говорит на SNMP, объект остаётся частично невидимым, а значит — потенциально аварийным.

Как команда «Алестел» решает задачу объединения Modbus и SNMP по принципу Plug&Play?

1.     Требование заказчика: мониторинг силовой части ЦОДа без SCADA и Modbus.

Проблематика понятна: IT-эксплуатация работает с SNMP, энергетическая инфраструктура — с Modbus, а между ними образуется критическая слепая зона. Но на реальных объектах необходимо не философствовать, а давать работающий инструмент, который делает силовое оборудование таким же прозрачным и управляемым для IT, как сетевой коммутатор.

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

• состояние всех коммутационных аппаратов (автоматы, рубильники, сигнальные цепи),

• контроль режима и состояния блока АВР,

• получение инженерных параметров качества электроэнергии по двум вводам, включая гармоники,

• а также передачу всех данных в уже существующую систему мониторинга на базе Zabbix.

Заказчик не хотел внедрять отдельную SCADA, не хотел модифицировать текущие процессы и категорически не хотел, чтобы IT-отделу приходилось изучать Modbus.

Мониторинг должен был работать в парадигме Plug&Play, то есть: данные приходят в Zabbix как обычные SNMP-переменные, а вся математика и обработка остаются внутри ПЛК - никакие таблицы регистров и коэффициентов на стороне IT не нужны, при этом SNMP-трапы должны приходить штатно, как с любого сетевого устройства.

Таким образом, перед нами стояла задача объединить два мира — Modbus и SNMP — так, чтобы заказчик даже не почувствовал сложности протоколов, а получил единое прозрачное решение, привычное IT-команде и соответствующее внутренним SLA.

2.     Состав оборудования и базовая инфраструктура мониторинга.

Изначально мы имели следующую архитектуру силовой части:

• вводной щит с двумя независимыми вводами от трансформаторов подстанции;

• на каждом вводе установлен промышленный измеритель электроэнергии SATEC PM335 PRO;

• отдельный щит байпаса для промышленного ИБП, также требующий мониторинга.

Наша задача заключалась не только в том, чтобы собрать два НКУ, но и встроить в них полноценную систему мониторинга, способную:

1. получать данные от измерителей и дискретных цепей,

2. обработать их внутри ПЛК,

3. передать в систему верхнего уровня по SNMP,

4. включая автоматическую генерацию trap-сообщений.

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

• контроллер Owen ПЛК210-12 — центральное ядро сбора и обработки данных;

• два многофункциональных измерителя качества электроэнергии SATEC PM335 PRO;

• четыре модуля дискретного ввода МВ210-214 — по два на каждый щит.

ПЛК210 размещался во вводном НКУ, там же находились два модуля МВ210-214. Ещё два модуля МВ210-214 устанавливались в щите байпаса. Таким образом обеспечивался полный охват всех дискретных сигналов: состояние автоматов, положение переключателей, аварийные контакты ИБП и вспомогательных устройств. Все приборы: оба SATEC PM335 PRO, контроллер ПЛК210-12 и четыре модуля МВ210-214 были объединены в локальную подсеть Modbus TCP/IP, предназначенную для внутреннего обмена данными внутри шкафов.

Контроллер ПЛК210 конфигурировался с разделением интерфейсов LAN и WAN:

• LAN использовался как изолированная внутренняя сеть НКУ, где происходит Modbus-обмен и обработка данных;

• WAN предоставлялся заказчику для подключения ПЛК к корпоративной сети и получения всех данных и trap-уведомлений по SNMP в Zabbix.

Все блоки системы диспетчеризации, а также блок АВР получал питание в нормальном режиме от промышленного ИБП заказчика, а в случае его отказа автоматически переходил на питание от любого из доступных вводов НКУ. Этим мы обеспечили непрерывность передачи данных даже в случае частичного отказа инфраструктуры заказчика – это особенно важно в аварийных ситуациях. Так была создана базовая аппаратная платформа, на которую впоследствии легла логика обработки, диагностики, структурирования OID-дерева и формирование нескольких SNMP-агентов.

3.     Подготовка данных и построение OID-архитектуры.

Теперь, когда аппаратная часть была собрана и логическая структура шкафа определена, настало время переходить к программной части и настройке системы передачи данных. Первый и самый критичный шаг — это формирование полного перечня переменных, которые должны передаваться от ПЛК в Zabbix по SNMP-get запросам. На этом же этапе необходимо разработать структуру OID-дерева, чтобы вся система была прозрачной, поддерживаемой и документированной для заказчика. Мы приняли решение использовать официальную enterprise-ветку компании Owen и логически сгруппировать все теги по тематическим разделам.

Общее количество SNMP-тегов — 684 переменных, которые далее распределяются по пяти SNMP-агентам, работающим на отдельных UDP-портах.

Следующим шагом стало формирование полного описания всех SNMP-тегов, что критически важно как для программиста, так и для инженеров заказчика, осуществляющих ввод системы в эксплуатацию. Для каждого тэга в таблицу включаются:

• конкретный OID;

• русскоязычное наименование;

• англоязычное наименование;

• подробное описание и правила интерпретации значений;

• тип переменной (INTEGER или OCTET STRING);

• уровень доступа;

• единицы измерения.

Отдельно необходимо подчеркнуть важность трёх параметров: описания, типа данных и единиц измерения.

Описание служит ключом к правильной интерпретации данных. Например, под OID `.1.3.6.1.4.1.51014.9.1.18.0` передаётся состояние дискретного входа DI6 ПЛК210-12CS, где «1» означает «Автомат QF2 включён», а «0» — «Автомат QF2 отключён». Без корректного описания Zabbix не сможет корректно преобразовать значение в человекочитаемый вид, и эксплуатация потеряет контекст происходящего.

Тип данных также имеет фундаментальное значение. Для инженерных величин достаточно двух типов:

INTEGER — для целочисленных параметров;

OCTET STRING — для значений с плавающей точкой, что и было выбрано заказчиком.

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

4.     Обработка данных измерителей и динамическая математика в ПЛК

Когда подготовительный этап завершён, начинается работа инженера-программиста. Здесь важный момент: разные измерительные приборы передают данные в Modbus совершенно по-разному. Как пример, приборы Dekraft передают измерения в виде целочисленного значения и отдельного регистра, определяющего положение запятой. То есть в одном регистре хранится значение мощности «2349», а в другом — величина, позволяющая преобразовать его в «23.49 Вт».

SATEC PM335 работает иначе: большинство параметров передаётся уже с учётом настроек коэффициентов трансформации, диапазонов измерений и уставок. Поэтому в коде ПЛК строго запрещено использовать значения настроек прибора как константы. Если эксплуатация изменит коэффициенты, предельные значения или настройки ТТ/ТН, фиксированные в коде числа неминуемо приведут к ошибочным расчётам.

Правильный путь — это реализация отдельной подпрограммы, которая регулярно считывает все необходимые параметры с прибора, формирует актуальные коэффициенты, и только затем используется в математике. Такой подход гарантирует, что любые изменения настроек SATEC автоматически и корректно учитываются ПЛК, обеспечивая точность и достоверность всех передаваемых значений без вмешательства программиста или IT-персонала.

5.     Событийная модель системы: стандартные и enterprise Trap-сообщения

Следующий ключевой этап — формирование SNMP trap-сообщений, которые должны не только фиксировать факт события, но и давать максимально полную картину для операторов и систем аналитики. В нашем проекте мы разделили trap-уведомления на две категории: стандартные сетевые события и enterprise-события, отражающие изменение дискретных сигналов и состояний коммутационных аппаратов.

Стандартные trap-сообщения: потеря и восстановление связи

Каждое сетевое устройство — измерители SATEC и модули дискретных входов МВ210-214 — имеет свой собственный trap-поток. Это позволяет Zabbix однозначно определить, с каким конкретно прибором потеряна связь, и сформировать корректные триггеры.

При восстановлении связи отправляется соответствующее событие linkUp.

Enterprise trap-сообщения: изменения дискретных сигналов и состояний аппаратов

Второй, более сложный тип trap-уведомлений отвечает за фиксацию изменений дискретных сигналов: положения автоматов, состояния АВР, аварийных контактов и входов/выходов модулей. Вне зависимости от того, каким образом изменилось состояние — вручную, автоматически или вследствие аварии — ПЛК генерирует trap и отправляет его в Zabbix.

Мы разработали структуру enterprise-trap таким образом, чтобы оператор мог видеть не только сам факт изменения, но и контекст:

• Что было до события.

• Что стало после события.

• Какой именно канал изменился.

• Как изменилось состояние всего модуля в целом.

Это критически важно — в отличие от простых «канал №7 = 1», такая структура даёт возможность полноценно анализировать логику работы оборудования.

Почему такая структура важна?

• Оператор видит реальную причину события, а не только факт изменения.

Например, не просто «QF2 = 0», а что ранее он был включён, а теперь отключился — возможно, аварийно.

• Zabbix получает всю контекстную информацию в одном trap-пакете.

Это даёт возможность строить интеллектуальные триггеры и отчёты.

• Битовая маска даёт мгновенное понимание состояния всего модуля.

Если одновременно изменилось несколько входов (например, групповая авария), это легко узнаётся из одного уведомления.

• Можно автоматически отслеживать предысторию.

Аналитикам теперь видно, как изменялось состояние системы «до» и «после» события.

Итог: такая структура trap-сообщений выводит мониторинг на уровень сетевого оборудования — события становятся прозрачными, полными, легко интерпретируемыми и пригодными как для Zabbix, так и для любых SIEM/аналитических систем.

В совокупности со стандартными linkUp/linkDown-уведомлениями предприятие получает полноценную событийную модель, в которой любая потеря связи, изменение состояния автомата или аварийное переключение фиксируется мгновенно и с максимальной информативностью.

6.     Что в итоге получил заказчик?

По завершении проекта заказчик получил единый, полностью интегрированный программно-аппаратный комплекс, который сводит разрозненную энергетику и IT-инфраструктуру в единую точку контроля. Причём без необходимости внедрять SCADA, писать драйверы или обучать персонал работе с промышленными протоколами. Все данные оказываются там, где IT-команде привычно и удобно — в Zabbix.

1. Мониторинг энергоинфраструктуры в Zabbix без SCADA и сложных интеграций.

Весь учет энергии, состояние блока АВР, состояние аппаратов, гармоники, токи, напряжения, мощности, аварийные события — всё отображается в стандартных дашбордах, графиках, логах и трендах Zabbix.

То есть заказчик использует существующую IT-платформу мониторинга, минуя дорогое и долгое внедрение SCADA-систем.

2. Полноценное Plug&Play-решение для IT-команды.

Контроллер ПЛК210 скрывает под собой всю работу с Modbus, регистрами, коэффициентами, преобразованиями и математикой.

Для IT остаётся только SNMP — привычный, стандартизированный протокол, с которым они работают в ежедневной практике.

С точки зрения эксплуатации устройство работает как стандартный сетевой элемент: подключил — получил данные.

3. Готовый и структурированный набор переменных по всей системе.

   Заказчик получил более 600 SNMP-тегов:

• измерения по двум вводам,

• гармоники,

• состояния всех аппаратов,

• состояние АВР,

• статусы DI/DO,

• служебные параметры ПЛК (CPU, память, дескрипторы, температура, аптайм).

   Всё это — уже обработанные инженерные величины, а не «сырые регистры».

4. Полный комплект документации с детальными описаниями.

   Каждый OID задокументирован:

• название на русском и английском,

• описание параметра и его физический смысл,

• тип данных,

• единицы измерения,

• правила интерпретации.

   Заказчик получает понятную, системную карту данных, пригодную как для эксплуатации, так и для аудита.

5. Готовые настройки для Zabbix: шаблоны и MIB-файл.

   По желанию заказчика предоставлены:

• заранее сконфигурированные Zabbix-шаблоны с Item’ами и preprocessing,

• MIB-файл для автоматической интерпретации OID.

   Это минимизирует время интеграции — достаточно импортировать шаблон.

6. Невидимая, но критически важная прослойка Modbus → SNMP.

Вся обработка Modbus-регистров, пересчёты, учёт коэффициентов, обработка настроек SATEC, нормализация и округление значений происходят внутри ПЛК210.

Для IT остаётся только итоговый SNMP-интерфейс.

То есть заказчик получает единый «мост» между промышленным оборудованием и IT-миром — без необходимости обучать IT персонал промышленным протоколам.

Итог: заказчик получил промышленную телеметрию, работающую в IT-экосистеме, полностью прозрачную, готовую к эксплуатации и не требующую дополнительного ПО, обучения или ручного сопровождения.