Или что пригодится знать и уметь, если замена ИБП после поломки – урон профессиональной гордости.

Часть 1
Часть 2
TL;DR

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

Об офисных UPS

В очередной раз повторюсь: поставить и забыть – не прокатывает.

ИБП без функции передачи данных бесполезны практически полностью, так как не решают одну из важнейших проблем – безопасное выключение с сохранением данных. К сожалению, ИБП с передачей данных тоже далеко не панацея. Тому есть несколько причин:

1. Качество соединения

На основании двухлетнего наблюдения могу с уверенностью сказать, что это беда.
Если не следить за подключениями достаточно внимательно, большинство из бесперебойников поотваливаются в течение полугода. Такое поведение сильно зависит от конкретных условий и меняется от машины к машине. Основные причины потери соединения (насколько мне удалось разобраться):

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

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

чуть подробнее

вообще, обмен данным с ИБП идёт постоянно, но всё же не раз в миллисекунду. Драйвер usbhid-ups получает данные раз в 2 секунды (видно в дебаг-режиме, если запускать руками с параметром -D+), что-то похожее, наверняка, и в стандартном драйвере Windows и WMI. Но это только "частичное" обновление, "полное" обновление происходит раз в 30 секунд

есть вероятность, что "полный" запрос сильно нагружает электронику ИПБ, и при частых запросах она начинает подглючивать. Это напрямую касается реализации сервера, о котором идёт речь в статьях. Чем это чревато и что с этим делать – см. далее

2. Работа внутренних систем, сенсоров и логики UPS

Во-первых, ИБП от разных производителей обращаются с батареей по-разному. В моей практике хуже всех обращаются с батареями ИБП Powercom, лучше всех – IPPON (далее по батарее см. п.3). Отличие не принципиальное, Powercom тоже через пол-года не дохнут, но оно есть и весьма заметно, если анализировать накопленные данные за достаточно длительный период. Здесь переходим к во-вторых: наиболее интересные параметры, которые ИБП сам считает и выдаёт:

а) нагрузка (load)

б) предсказание времени работы от батареи (runtime), вычисляемое на основе нагрузки

в) текущий заряд батареи (charge)

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

К сожалению, есть куда больше параметров, которые анализировать, считать и даже просто получать стоило бы, но это не реализовано.

Простейший пример: просадка напряжения на батарее, когда пропадает питание. Это показательнейший параметр, на основании которого можно куда точнее сделать вывод об убитой батарее. Постоянная память EEPROM есть сейчас где угодно, и ИБП запросто может записывать такие данные самостоятельно. Но ни одного ИБП с таким функционалом мне не попалось.
Другой пример: Powercom'ы после потери питания и разряда батареи до 30 процентов могут "зарядить" 12-вольтовую батарею за 10 минут и утверждать, что всё прекрасно, а Self-test passed.

Это прямо натуральный epic fail.

Те же Powercom не умеют в вольтаж батареи вообще, только в проценты. На основании чего там эти проценты внутри считаются – покрыто китайской мракой.

Очень важного параметра "температура" (батареи, внутри корпуса, да хоть чего-нибудь) не найти днём с огнём в офисных ИБП, хотя датчик копеечный и вообще встроен в почти все микроконтроллеры. Тут переходим к третьему пункту раздела.

3. Батарея и её состояние

Из того зоопарка, с которым я имел дело, "посредственно" справляется с задачей анализа состояния батареи серверный ИБП IPPON. Потуги остальных иначе как "бессмысленно" назвать не могу. Очень важный параметр батареи – кривая разряда – просто игнорируется.

немного о кривой разряда

Свинцовые батареи ИБП разряжаются нелинейно. Проще говоря, чем меньше заряда осталось в батарее, тем быстрее она разряжается. Ещё проще: время разряда со 100% до 90% будет в разы больше, чем с 20% до 0%. Но и это ещё не всё. Кривая разряда становится круче в более старой батарее и/или в зависимости от внешних условий (та же температура). В итоге это выглядит так:

Чувствуете подвох? Угадайте, проводит ли ИБП запись скорости последнего разряда, анализ, учитывает ли дату установки батареи?

Вспомним, с чего мы начали этот раздел: передача данных с ИБП нужна для того, чтобы сохранить данные, пока ещё осталось время. Но ни ИБП, ни драйвер не знают, какое время является безопасным: 50% новой батареи совсем не то же самое, что 50% годовалой батареи. И единственное решение проблемы на данный момент: параметр нужно периодически модифицировать вручную.

Запись и расчёт параметров реализован в очередном обновлении сервера мониторинга. В частности, теперь видно:

• просадку заряда батареи непосредственно после потери питания. Если этот показатель низкий, сервер выдаст предупреждение;

• скорость разряда батареи. Этот параметр требует для расчёта не менее 2 мин наблюдаемого разряда ИБП.

Для корректного учёта этих параметров требуется довольно частый опрос ИБП. Соответствующие изменения внесены в код сервера (см. раздел "NUT и сервер мониторинга"). К сожалению, здесь мы упираемся в ранее озвученный п. "б" ч. 1 текущего раздела – при частых обращениях за данными возможны глюки. Более того, в первые секунды после потери питания ИБП данные не отдаёт вообще, а вместо этого передаёт "WAIT". По-хорошему, после потери питания ИБП для целей мониторинга нужно бы опрашивать как можно чаще. На данный момент частота опроса от 10 до 30 секунд, в целом для более-менее приличного анализа этого хватает. Более интенсивные опросы не тестировались достаточно долго, чтобы делать какие-то однозначные выводы.

Краткие итоги раздела:

• обязательно нужен мониторинг самого факта подключения ИБП к машине;

• нужно собирать и хранить данные о датах установки батарей;

• в идеале нужно очень детально мониторить процесс разряда и заряда батарей.

NUT и сервер мониторинга

Изначально NUT был выбран как кроссплатформенное универсальное решение. В целом функции свои выполняет. Без нюансов, впрочем, не обошлось:

а) Не слишком дружелюбная и неочевидная установка на клиентских машинах, под Windows особенно. В частности:

• иногда отказывается видеть библиотеки;

• встроенный драйвер не обновлялся давно и половину ИБП не знает. Драйвер надо ставить вручную, и это отдельная песня;

• на клиентах под Windows служба стартует "невовремя", раньше, чем фактически нужно (похожая история есть при поиске домена на Windows с некоторыми сетевыми адаптерами). Из-за этого приходится городить костыли.

б) Заявлено, что клиент NUT может оповещать сервер о пропадании и восстановлении питания, и даже выполнять скрипты по этим событиям. Это убрало бы и необходимость частого опроса ИБП, и позволило бы вести более точечный мониторинг важных состояний (см. предыдущий раздел). Однако заставить стабильно работать этот функционал мне не удалось. Некоторые машины не триггерят сервер вообще, либо делают это один раз из десяти. При этом есть машины, с которых это работает стабильно.

В качестве альтернативы я попробовал (и даже написал "адаптер") получать данные из WMI по предложению @firedragon. Суть, в общем, та же. Плюсы: не нужно альтернативных дайверов и библиотек, не нужно костылить некоторые вещи. Минусы: информации сильно меньше, а по сравнению с настроенным клиентом NUT стабильность ровно та же, при этом отсутствует, хотя бы потенциальная, возможность "триггера".

По результатам изысканий решено было оставить NUT в качестве основного решения для сервера. При этом "сильно больше данных" в какой-то момент обернулось базами, раздутыми по 100 Мб на бесперебойник, что повлияло на производительность. В итоге, сервер был перенесён из среды Windows в Linux, и:

• написан соответствующий скрипт-демон на bash для непрерывного опроса;

• оптимизировано хранение данных: если есть питание на входе и некоторые другие параметры в норме, последняя строка не добавляется в базу, а обновляется.

В саму веб-морду сервера, как уже говорилось, добавлено:

• отображение заряда батареи сразу после последней потери питания и соответствующий алерт;

• расчёт времени работы от батареи на основе реальных данных. Некоторым образом это тоже синтетика, т.к. реальная кривая разряда не строится. Однако, отлично себя показала следующая формула: рассчитанное на основе последних реальных данных время / 1+ лет с десятыми.

Итоги, советы, планы

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

1. Тщательно выберите марку и модель ИБП и по возможности используйте только выбранный ИБП во всем офисе;

2. Запишите серийные номера и/или присвойте каждому ИБП уникальный номер. Запишите дату установки батареи в каждый ИБП. Меняйте батареи раз в два года, и сразу, заранее, закладывайте эти расходы в бюджеты – для бизнеса запланированные расходы гораздо удобнее внезапных;

3. Любым способом следите за тем, чтобы машины, обеспеченные ИБП, имели с ним постоянную связь;

4. Раз в пол-года обновляйте параметры battery low и battery warning в используемом вами драйвере/решении, прибавляя к ним от 5% до 20% в зависимости от опыта использования вашей модели ИБП, вручную или скриптами;

5. По возможности проводите ручное тестирование ИБП (отключить от розетки и подождать) раз в квартал-полгода.

Это то, что нужно делать обязательно.

Использование постоянного и подробного мониторинга, в целом, скорее чрезмерно, хотя и может оказаться полезным и наглядным. Заводить для этого отдельный сервер или нет, решать вам. Некоторые параметры можно мониторить в том же Zabbix (и даже посредством WMI), однако лично у меня в целом не очень удачный опыт с Zabbix active parameters; к тому же, сложность реализации некоторых описанных решений внутри Zabbix по сложности приближается, на мой вкус, к сложности реализации представленного сервера мониторинга.

Я удивлён и рад, что довольно много читателей задумалось о мониторинге ИБП после первой статьи, и многие посоветовали довести решение "до энтерпрайза" после второй статьи. Благодарю за отклики и ответы!

Учитывая накопленный опыт, реализация "до энтерпрайза" может быть довольно длительной. Есть проблемы и на клиентской стороне, и в самом NUT; в веб-интерфейсе многое надо выносить в бэкэнд, нет даже банальной авторизации. Можно было бы даже в таком виде запихнуть всё это в контейнер Docker в качестве версии 0.1 alpha, но мой энтузиазм к теме несколько поугас. Если у кого-то энтузиазм найдётся – пишите, буду рад поработать вместе!

Рад, если мой опыт вам пригодится. Спасибо всем, кто прочитал!