Zabbix v7.2.1, APC UPS battery lifetime not okay

[ezoltan]

Hi there,

I've recently upgraded my entire distributed Zabbix infrastructure (server + proxies) to the latest version, 7.2.1. Added a brand-new site with its own v7.2.1 proxy.

There is an APC Smart-UPS SRT 3000 on the network. The UPS reports the following when querying battery health:



None of the bits are "1", therefore the battery is reported by the UPS as healthy.
Testing the item returns the same:



The trigger also seems to work:





Yet, I it is still telling me that the battery lifetime is not okay:



I tested with the generic "APC UPS by SNMP", as well as the "APC Smart-UPS 3000 XLM by SNMP" templates, both pre-canned official Zabbix templates.

From my research it looks like it's been a problem for years throughout a number of Zabbix releases, and despite some claiming that it's been fixed in a prior version, it isn't - see https://www.zabbix.com/forum/zabbix-...mplate-apc-ups. I've been battling this problem since day 1. Zabbix 6.4 was the latest at the time. Never been able to solve it, and now, at v7.2.1, it still persists.

Any pointers would be very much appreciated.

Thank you.

[peperinopomuro]

Hi there! I am having the same issue. Did you find a solution?

[markfree]

I can't really confirm this because I don't have such a UPS to test with, but it seems that the regex in the "find" function is wrong. The trigger becomes true because the find function always finds the 0 in the octet string returned by the UPS.

Since that is an official template, you may be able suggest improvements to Zabbix.

[cyber]

Totally agree... that regex there "^(0)[0|1]{15}$" .. it will not match only if it starts with 1... and rest of 15 places, it may contain 0,1 or |, which also includes "all zeros"
I think that prototype should be ...

find(/APC UPS by SNMP/battery.pack.cartridge_health[upsHighPrecBatteryPackCartridgeHealth.{#BATTERY_PACK}.{#CARTRIDGE_INDEX}],,"regexp","^(0)(0{15})$")=0

Then it will react, when there is at least 1 non-zero value within those 15 places... and it all starts with 0, but then it migth aswell be ".... ,"regexp","^(0{16})$")=0" same as for "Battery status not ok" trigger prototype... Just the item is different.

Other question is, why there is at all 16 bits in that bitmap...:P Mib only describes 7 ... https://mibs.observium.org/mib/Power...artridgeHealth
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

[peperinopomuro]

I'm not sure if I did the right thing. But in the discovery rule for "External Battery Packs Discovery" I change the filter to: Cartridge Status matches "^1000000000000000$" and now I only have the real battery packs that I have in every UPS. Before this the discovery was finding a lot of battery packs that I didn't had.

[[email protected]]

We have many SMARTUPS6000 units and are experiencing both issues, some units find batteries that don't exist, and all units find bad batteries 3.1 - 3.2 - 2.2 - 2.1 - 1.1 - always show "Battery Status is Not OK" Can anyone confirm if changing the Regex to what Cyber indicated above fixed the issue for them?

[markfree]

Try it out and tell us if it works.

[[email protected]]

It did not work for us unfortunately. we are disabling that trigger for now in our templates and may open an official support ticket with Zabbix.

[Tyler]

The solution for this I've got was I modified the template to be filtered to (Regex and Regex).

One to match that it contains only 0s and a single 1
^(0{0,15}10{0,15})$
A Second to match the desired/expected length of 16
^([01]{16})$

If it fills both conditions, it will be the expected 16 length of 0 or 1 while also containing at least one number 1.

[dvt]

Tyler's solution worked for me. I didn't have issues until I added an APC Smart-UPS SRT 3000 running firmware 16.5 to the system. My older Smart-UPS 3000 running 09.3 dont seem to have the discovery issue and stay at 26 items rather than 31.

[ezoltan]

Okay folks, I think I have identified the root cause. The UPS only has an internal battery pack, and the battery pack has room for two cartridges. One cartridge is present while the second is missing. This is indicated by the following result when queried via SNMP:

[{"{#SNMPINDEX}":"1.1.1","{#CARTRIDGE_STATUS}":" 100 0000000000000","{#BATTERY_PACK}":"1","{#CARTRIDGE_ INDEX}":"1"},
{"{#SNMPINDEX}":"1.1.2","{#CARTRIDGE_STATUS}":" 000 0000000000000","{#BATTERY_PACK}":"1","{#CARTRIDGE_ INDEX}":"2"},
{"{#SNMPINDEX}":"2.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"2","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"2.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"2","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"3.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"3","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"3.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"3","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"4.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"4","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"4.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"4","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"5.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"5","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"5.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"5","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"6.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"6","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"6.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"6","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"7.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"7","{#CARTRIDGE_INDEX}":"1"},
{"{ #SNMPINDEX}":"7.1.2","{#CARTRIDGE_STATUS}":"","{#B ATTERY_PACK}":"7","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"8.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"8","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"8.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"8","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"9.1.1","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"9","{#CARTRIDGE_INDEX}":"1"},
{"{#SNMPINDEX}":"9.1.2","{#CARTRIDGE_STATUS}":" "," {#BATTERY_PACK}":"9","{#CARTRIDGE_INDEX}":"2"},
{"{#SNMPINDEX}":"10.1.1","{#CARTRIDGE_STATUS}": "", "{#BATTERY_PACK}":"10","{#CARTRIDGE_INDEX}":"1 "},
{"{#SNMPINDEX}":"10.1.2","{#CARTRIDGE_STATUS}": "", "{#BATTERY_PACK}":"10","{#CARTRIDGE_INDEX}":"2 "},
{"{#SNMPINDEX}":"11.1.1","{#CARTRIDGE_STATUS}": "", "{#BATTERY_PACK}":"11","{#CARTRIDGE_INDEX}":"1 "},
{"{#SNMPINDEX}":"11.1.2","{#CARTRIDGE_STATUS}": "", "{#BATTERY_PACK}":"11","{#CARTRIDGE_INDEX}":"2 "}]

From what I read, the string of 16 zeroes for CARTRIDGE_INDEX 2 means that the slot for that cartridge is not populated. Having a non-null value returned and bit #0 set to 0 fools Zabbix to believe that we do have a cartridge _and_ it is unhealthy.

Apparently according to APC parlance a bitmap of 16 zeroes means no cartridge/empty slot.

This isn't confirmed by APC, but rather the conclusion based on googling it.

Basically we should instruct Zabbix to ignore entries with 16 zeroes in the CARTRIDGE_INDEX field. But that's a double-edge sword: if we happen to have cartridge #2 populated and it indeed is unhealthy then Zabbix would just ignore it. Same issue disabling the trigger.

I am at a loss.

[markfree]

It seems to me that you can filter out battery packs that are absent.
Configure your discovery rule to filter out objects with an absent status.