Если у вас больше 5–10 шкафов, знакомый хаос обеспечен. Один шкаф стучится SNMP-трапами... — 25 февраля 2026 г. в 12:13:05.386
Если у вас больше 5–10 шкафов, знакомый хаос обеспечен. Один шкаф стучится SNMP-трапами, другой шлет HTTP-запросы, третий вообще общается по Modbus RTU через левый конвертер. И каждый раз, когда что-то падает, ты прыгаешь по разным интерфейсам и собираешь картину по крупицам. Это не масштабируется. 1. Для начала договоритесь, что меряем везде. Золотой стандарт для каждого шкафа: - температура и влажность - открытие двери (или протечка) - потребление — хотя бы по фазе, а лучше по розеткам - статус ИБП: от сети или от батарей, заряд - состояние PDU: ток, напряжение, мощность Если метрики будут плавать от шкафа к шкафу, потом ничего не сопоставишь. 2. Приводим железо к общему знаменателю По возможности выбирайте PDU, ИБП и датчики, которые говорят на SNMPv3 или Modbus TCP. Это избавит от лишних телодвижений на интеграции. Если оборудование уже есть и оно разношерстное — смотрите, можно ли его поднять до этих протоколов через конвертеры или прокси. Главное — уйти от "зоопарка". 3. Ставим шлюз-агрегатор По сути, это местный сборщик данных. Шлюз опрашивает всё железо на их родных языках (Modbus, SNMP), буферизирует данные, если связь упала, и отдает их наверх уже по единому легкому протоколу. Идеально — MQTT. Как вариант — HTTP/JSON или SNMP-трапы, но MQTT здесь удобнее всего. 4. Выбираем платформу, где всё будет лежать Тут уже зависит от ваших заморочек: облако или своя железка (on-prem). Главное, чтобы было: - дашборды с графиками температуры и мощности - история, чтобы видеть тренды (когда начал греться кондиционер) - движок алертов, который ругается при выходе за пороги 5. Настраиваем оповещения с головой - Критичное: ИБП упал в батареи, перегрев, дверь открылась ночью — летит в Telegram или SMS дежурному. - Некритичное: влажность поднялась, батареи скоро сядут — уходит в лог, на почту или в тикет-систему. И сразу пропишите SLA: кто и за сколько должен реагировать на каждый тип тревоги. 6. Запускаем пилот на 3–5 шкафах Ни в коем случае не лейте сразу на всё. Выберите пару типовых шкафов и погоняйте недельку. Проверьте, не теряются ли пакеты. Отловите ложные срабатывания и посмотрите, не перегружает ли шлюз сеть. 7. Масштабируем по шаблону Когда пилот обкатан, делаете шаблон конфигурации. Новый шкаф — просто применили шаблон, и он уже в системе. Прикрутите автоматическое создание тикетов при авариях (через API). Пусть система мониторинга сама обновляет CMDB, когда появляется новое железо. 8. Не забываем про безопасность Мониторинг — это управление, его надо защищать: - Только HTTPS и SSH, забыли про Telnet. - Где можно — OTA-обновления прошивок. - Управление сертификатами и регулярная смена паролей (или ключи). И обязательно вынесите управление в отдельную VLAN, чтобы доступ к шкафам был только у мониторинга и админов. После выполнения всех шагов у вас будет организованный и масштабируемый мониторинг важных параметров множества шкафов одновременно.