ИБП APC. Вопрос по мониторингу Battery Pack

[Diesel315]

Добрый день всем!
Может кто-то разобрался в мониторинге Battery Pack (далее BP) на APC (если честно, то там сам черт ногу сломит)? Требуется пояснительная бригада... Извиняюсь сперва будет немного "воды"

Суть.
1. Взял готовый шаблон APC с git zabbix. Всегда стараюсь выдергивать из них нужное мне в свои шаблоны, заодно анализируя и лучше понимая сам вопрос - "что я мониторю и как это работает/срабатывает"
2. Встал вопрос по мониторингу BP (MIB PowerNet). Для этого нужно смотреть в раздел - .iso.org.dod.internet.private.enterprises.apc.prod ucts.hardware.ups.upsBattery.upsHighPrecBattery.up sHighPrecBatteryPacks (.1.3.6.1.4.1.318.1.1.1.2.3.10)
И тут начинаются уже интересности, так как по факту есть два схожих раздела:
upsHighPrecBatteryPackTable (.1.3.6.1.4.1.318.1.1.1.2.3.10.2)
upsHighPrecBatteryPackOnlyTable (.1.3.6.1.4.1.318.1.1.1.2.3.10.4)

Не до конца понял их суть, но вроде как первый более детальный и видит BP как два отдельных логических устройства (обозначим этот режим как - "детальный").
Второй вроде как "смотрит" на BP как на одно логическое устройство (обозначим этот режим как - "общий").
Это легко коррелируется с выводами например по серийному номеру:
в первом случае это:
upsHighPrecBatteryPackSerialNumber.1.1.1 7A2004L38294
upsHighPrecBatteryPackSerialNumber.1.1.2 7A2004L38294
во втором случае это:
upsHighPrecBatteryPackOnlySerialNumber.1.1 7A2004L38294

В веб интерфейсе как бы тоже такой же подход. Сперва отображается статус BP "общий", потом, если провалиться в него, то видно BP как два логических устройства - "детальный".
При этом интересующие нас статусы отличаются. Для примера и понимания: "Общее здоровье - требует внимания. Детально - правая рука (Ок), левая рука (Bad)"

Решил, что надо мониторить детальный раздел с разделением на два логических устройства.
а) Интересует параметр - upsHighPrecBatteryPackCartridgeHealth (.1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7)
Его описание: "The battery cartridge health. bit 0 Battery lifetime okay bit 1 Battery lifetime near end, order replacement cartridge bit 2 Battery lifetime exceeded, replace battery bit 3 Battery lifetime near end acknowledged, order replacement cartridge bit 4 Battery lifetime exceeded acknowledged, replace battery bit 5 Battery measured lifetime near end, order replacement cartridge bit 6 Battery measured lifetime near end acknowledged, order replacement cartridge "
Получаемое значение: 1000000000000000

И вот собственно первый вопрос. Что это и как это интерпретировать?
Потому что из шаблона триггер срабатывает при таком условии - find(/02R04-UPS.18.28/battery.pack.cartridge_health[upsHighPrecBatteryPackCartridgeHealth.1.1],,"regexp","^(0)[0|1]{15}$")=1
В данном случае он не сработает, потому что в выводе первый символ стоит 1. Если бы первый символ был 0, то сработал, и вообще срабатывает, если первый символ 0, остальные любая комбинация.

Никак не могу найти корреляцию/связь между описанием параметра <-> настройкой триггера из шаблона <-> логикой

б) Интересует параметр - upsHighPrecBatteryPackCartridgeStatus (..1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.10)
Его описание: "The battery cartridge status. bit 0 Disconnected bit 1 Overvoltage bit 2 NeedsReplacement bit 3 OvertemperatureCritical bit 4 Charger bit 5 TemperatureSensor bit 6 BusSoftStart bit 7 OvertemperatureWarning bit 8 GeneralError bit 9 Communication bit 10 DisconnectedFrame bit 11 FirmwareMismatch"
Получаемое значение: 0010000000000000
Триггер: find(/02R04-UPS.18.28/battery.pack.status[upsHighPrecBatteryPackCartridgeStatus.1.1],,"regexp","^(0{16})$")=0

Он сработает. Потому что срабатывает на любую комбинацию кроме всех нулей.
Никак опять же не могу найти корреляцию/связь между описанием параметра <-> настройкой триггера из шаблона <-> логикой

Может кто-то разбирался в этом? Кто-то же написал этот шаблон и положил в git, значит вложил какую-то логику в триггеры, почему они срабатывают именно так (при таких условиях), а не иначе? Как интерпретировать логику срабатывания с описанием параметра, и в особенности с этими битами?

[Hamardaban]

Могу ответить чисто формально исходя из выражения триггеров:
Первый триггер на upsHighPrecBatteryPackCartridgeHealth срабатывает когда "здоровье"картриджа не ok - т.е.найдена строка в которой первый "бит" (Battery lifetime okay) равен 0 (не взведен\ не равен 1 ) и всё остальные 15 бит уже пофигу 0 или 1.
Второй триггер на upsHighPrecBatteryPackCartridgeStatus сработает когда не найдена строка из 16 нулей т.е. когда есть какие либо проблемы со статусом (установлен в 1 хоть какой-то бит сигнализирующий о проблеме)

Так что всё логично! :-)

Более детального "разбора" ситуации в этих триггерах нет! Видимо автор посчитал что достаточно маякнуть что есть проблема - а по последним данным можно узнать что именно за проблема. Если хочется феншуя - создайте кучку зависимых элементов в которые вытягивайте из битовой строки нужную позицию и навесте на эти элементы триггеры. Или еще проще - сразу несколько триггеров на разные позиции битов (выдирать - regexp ом)

[Kos]

А тип данных для этих параметров какой (в Zabbix-е и по факту, при просмотре snmpwalk-ом)?
Могу предположить, что должен быть целочисленный (чтобы его можно было разбирать по битам), но в Zabbix-е (судя по используемым функциям) - текстовая строка.
При этом, похоже, при преобразовании в текстовую строку наименее значащий бит (bit 0) почему-то оказывается слева, а не справа (как нам привычно).
То есть, для первого параметра выставлен бит "Battery lifetime okay", а для второго - "NeedsReplacement".

[Diesel315]

Могу ответить чисто формально исходя из выражения триггеров...

Вы в целом правы, оно и логично вроде даже. задача просто сообщить, что что-то не так, а дальше лезь в web и смотри...
Мне почему-то показалось, что автор того шаблона познал дзен и расшифровал "интерпретацию" этих значений и описания этого OID и именно так настроил триггеры

Но я все равно честно не понимаю. Почему именно так?
Я не вижу корреляцию для первого значения: upsHighPrecBatteryPackCartridgeHealth (.1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7) - 1000000000000000, его описанием: "The battery cartridge health. bit 0 Battery lifetime okay bit 1 Battery lifetime near end, order replacement cartridge bit 2 Battery lifetime exceeded, replace battery bit 3 Battery lifetime near end acknowledged, order replacement cartridge bit 4 Battery lifetime exceeded acknowledged, replace battery bit 5 Battery measured lifetime near end, order replacement cartridge bit 6 Battery measured lifetime near end acknowledged, order replacement cartridge " и триггером. Триггер сработает, если первое значение будет 0. Но с описанием это не как не вяжется, так как bit 0 это Battery lifetime okay. То есть все хорошо... Так почему тогда должен сработать триггер?

А тип данных для этих параметров какой (в Zabbix-е и по факту, при просмотре snmpwalk-ом)?

Если правильно понял вопрос:
1. Согласно базе MIB - OCTET STRING
2. snmpwalk - PowerNet-MIB::upsHighPrecBatteryPackCartridgeHealth.1.1.1 = STRING: "1000000000000000"
3. Zabbix - character

[Kos]

Но я все равно честно не понимаю. Почему именно так?
Я не вижу корреляцию для первого значения: upsHighPrecBatteryPackCartridgeHealth (.1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7) - 1000000000000000, его описанием: "The battery cartridge health. bit 0 Battery lifetime okay bit 1 Battery lifetime near end, order replacement cartridge..." и триггером

Я это описание понимаю так, что если всё ОК, то будет выставлен в единичку лишь нулевой бит (bit 0, "Battery lifetime okay"). В противном случае (когда на всё ОК) этот бит сбросится в ноль (и на это отреагирует триггер), а остальные биты покажут, что именно "не ОК" - например, если выставлен в единичку первый бит, то это означает "Battery lifetime near end, order replacement cartridge", т.е. что батарея пока ещё работает, но уже пора заказывать новую, т.к. её срок жизни подходит к концу.

[Diesel315]

Я это описание понимаю так...

Спасибо, кажется дошло...
Первый бит получается дает общее состояние - хорошо (1) или плохо (0), остальные раскрывают детальную информацию

[atravka]

)Мне кажется надо править дисковери. Там стоит фильтр на {#CARTRIDGE_STATUS} != ^$
У меня есть куча 1000ных, у которых всего один battery pack.При этом в .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7 есть статус для минимум двух паков. Для .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7.1.1.1 и .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7.1.1.2.
Для второго статус все нолики, то бишь проблема с ним. Для остальных .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7.1.1.Х действительно пустые строки. Если сверить остальные значения в ветке .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1., то можно увидеть один и тот же серийник для обоих паков, одинаковая температура, при этом будет разные даты прошедшей замены и планируемой.
В вебке ИБП и по факту, battery pack стоит один.
И вот сейчас нашёл один ИБП, на котором ВСЯ ветка .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7 имеет значение 15 нулей, кроме .1.3.6.1.4.1.318.1.1.1.2.3.10.2.1.7.1.1.1, в которой первый бит единичка. И дисковери обнаруживает там 22 картриджа, чего там конечно же нет.
Добавил у себя в дисковери фильтр на все нолики в {#CARTRIDGE_STATUS}