{#SNMPINDEX} macro manipulation

[novakm]

Hello, Im trying to make a template that would walk CISCO-ENTITY-SENSOR-MIB and create items monitoring Transceiver Receive/Transmit Power Sensor values.

There are two important tables in the MIB:
1) 1.3.6.1.4.1.9.9.91.1.1.1 (entSensorValueTable)
2) 1.3.6.1.4.1.9.9.91.1.2.1 (entSensorThresholdTable)
Also I need to walk ENTITY-MIB to know which interface/sensor Im getting values of - im using 1.3.6.1.2.1.47.1.1.1.1.2 (entPhysicalDescr).

The catch is that not for every transceiver the entSensorThresholdTable is populated. In fact for most devices in our network from some reason there are no values in the MIB despite the device lists CISCO-ENTITY-SENSOR-MIB as supported. My goal is to create items related to this MIB only if the table is populated (which means that the macros exist and is not empty).

To get an idea, here is how it looks for one interface/optical sensor.
...
{"{#SNMPINDEX}":"300003533","{#ENTPHYSICALDESCR }": "Ethernet1/3 Lane 1 Transceiver Receive Power Sensor"}
,{"{#SNMPINDEX}":"300003533.1","{#ENTSENSORTHRESHO LDVALUE}":"5399"}
,{"{#SNMPINDEX}":"300003533.2","{#ENTSENSORTHRESHO LDVALUE}":"2399"}
,{"{#SNMPINDEX}":"300003533.3","{#ENTSENSORTHRESHO LDVALUE}":"-13306"}
,{"{#SNMPINDEX}":"300003533.4","{#ENTSENSORTHRESHO LDVALUE}":"-10301"}
...

I did as advised in https://www.zabbix.com/documentation...snmp_oids_walk so created one item with walk[1.3.6.1.2.1.47.1.1.1.1.2,1.3.6.1.4.1.9.9.91.1.2.1. 1.4] and then discovery rule as a dependent item with SNMP walk to JSON to fill those macros used above (see attached pics)


The issue is that while for macro {#ENTPHYSICALDESCR} I get {#SNMPINDEX} of 300003533, for the {#ENTSENSORTHRESHOLDVALUE} I get four different indexes with appended .1-.4

Therefor when I create item prototype with
Name: "{#SNMPINDEX} entSensorThresholdValue"
and
SNMP OID: "1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}"

I get an error that macro {#ENTPHYSICALDESCR} doesnt exist - because the {#SNMPINDEX} is 300003533.x. Im looking for a way how to remove the last digit and dot from the {#SNMPINDEX} macro.

Can anyone point me in the right direction, please? I thought I might try to use additional preprocessing step .regsub but couldnt get it working.

[markfree]

Try out macro functions. See if the regsub or regrepl functions helps.

[novakm]

Try out macro functions. See if the regsub or regrepl functions helps.

Try them in which step? In item prototype I think it's too late. I tried to use replace in preprocessing step in the discovery but didn't succeed.

[kyus]

You can use it in your item prototype.

I guess you could try something like this:

Name: {{#SNMPINDEX}.regsub("..$", "")} entSensorThresholdValue
SNMP OID: 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{{#SNMPINDEX}.regsub( "..$", "")}

"..$" Should match the last 2 characters, so if your snmp index is 300003533.x. it would become 300003533.
If you want to also remove that last dot, you could try "...$"

I can't really test this, so I'm not sure whether or not it'll work for your scenario, but I guess you can give it a try .

[mrnobody]

Hello, Im trying to make a template that would walk CISCO-ENTITY-SENSOR-MIB and create items monitoring Transceiver Receive/Transmit Power Sensor values.

There are two important tables in the MIB:
1) 1.3.6.1.4.1.9.9.91.1.1.1 (entSensorValueTable)
2) 1.3.6.1.4.1.9.9.91.1.2.1 (entSensorThresholdTable)
Also I need to walk ENTITY-MIB to know which interface/sensor Im getting values of - im using 1.3.6.1.2.1.47.1.1.1.1.2 (entPhysicalDescr).

The catch is that not for every transceiver the entSensorThresholdTable is populated. In fact for most devices in our network from some reason there are no values in the MIB despite the device lists CISCO-ENTITY-SENSOR-MIB as supported. My goal is to create items related to this MIB only if the table is populated (which means that the macros exist and is not empty).

To get an idea, here is how it looks for one interface/optical sensor.
...
{"{#SNMPINDEX}":"300003533","{#ENTPHYSICALDESCR }": "Ethernet1/3 Lane 1 Transceiver Receive Power Sensor"}
,{"{#SNMPINDEX}":"300003533.1","{#ENTSENSORTHRESHO LDVALUE}":"5399"}
,{"{#SNMPINDEX}":"300003533.2","{#ENTSENSORTHRESHO LDVALUE}":"2399"}
,{"{#SNMPINDEX}":"300003533.3","{#ENTSENSORTHRESHO LDVALUE}":"-13306"}
,{"{#SNMPINDEX}":"300003533.4","{#ENTSENSORTHRESHO LDVALUE}":"-10301"}
...

I did as advised in https://www.zabbix.com/documentation...snmp_oids_walk so created one item with walk[1.3.6.1.2.1.47.1.1.1.1.2,1.3.6.1.4.1.9.9.91.1.2.1. 1.4] and then discovery rule as a dependent item with SNMP walk to JSON to fill those macros used above (see attached pics)


The issue is that while for macro {#ENTPHYSICALDESCR} I get {#SNMPINDEX} of 300003533, for the {#ENTSENSORTHRESHOLDVALUE} I get four different indexes with appended .1-.4

Therefor when I create item prototype with
Name: "{#SNMPINDEX} entSensorThresholdValue"
and
SNMP OID: "1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}"

I get an error that macro {#ENTPHYSICALDESCR} doesnt exist - because the {#SNMPINDEX} is 300003533.x. Im looking for a way how to remove the last digit and dot from the {#SNMPINDEX} macro.

Can anyone point me in the right direction, please? I thought I might try to use additional preprocessing step .regsub but couldnt get it working.

Tested your Regex with regex101.com and it seems wrong
Try this
.*Receive.*Power.*|.*Transmit.*Power.*

[novakm]

Tested your Regex with regex101.com and it seems wrong
Try this
.*Receive.*Power.*|.*Transmit.*Power.*

This is not the part I have problem with. I think I used "Power Sensor" as more general string to search but even what I shared already worked to get the example I shared in original posts.

[novakm]

You can use it in your item prototype.

I guess you could try something like this:

Name: {{#SNMPINDEX}.regsub("..$", "")} entSensorThresholdValue
SNMP OID: 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{{#SNMPINDEX}.regsub( "..$", "")}

"..$" Should match the last 2 characters, so if your snmp index is 300003533.x. it would become 300003533.
If you want to also remove that last dot, you could try "...$"

I can't really test this, so I'm not sure whether or not it'll work for your scenario, but I guess you can give it a try .

Substituting in item prototype is too late as then I dont have the {#ENTPHYSICALDESCR} filled because it needs the {#SNMPINDEX} without the last digit already (300003533.1 -> 300003533)

I think I need a way (not sure there actually IS such way) in the discovery rule.

[kyus]

So you expect to modify the {#SNMPINDEX} macro in order to get the {#ENTPHYSICALDESCR} within the same discovery rule?

I think you could just use a Filter in your Discovery Rule to create only the items that have the desired value on those macros.

[novakm]

So you expect to modify the {#SNMPINDEX} macro in order to get the {#ENTPHYSICALDESCR} within the same discovery rule?

I think you could just use a Filter in your Discovery Rule to create only the items that have the desired value on those macros.

Maybe I am approaching it from the wrong direction. My initial idea and experiment was to only use discovery with 5 item prototypes (refering to the original example data I shared).


{#ENTPHYSICALDESCR} entSensorValue
1.3.6.1.4.1.9.9.91.1.1.1.1.4.{#SNMPINDEX}
{#ENTPHYSICALDESCR} entSensorThresholdValue 1
1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.1
{#ENTPHYSICALDESCR} entSensorThresholdValue 2
1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.2
{#ENTPHYSICALDESCR} entSensorThresholdValue 3
1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.3
{#ENTPHYSICALDESCR} entSensorThresholdValue 4
1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.4

However, then I ended up with lots of unsupported items because on most devices the entSensorThresholdValue 1-4 do not exist.

Basically the only thing I need is not to create items I know will be unsupported so I tried to use filter in the discovery to carry on with the discovery only if the macro {#ENTSENSORTHRESHOLDVALUE} exists and I ran into the issue I described in the original posts.

[kyus]

Maybe your macros aren't working as expected? I'm still a bit unsure about what's the error happening, maybe you could share a bit of the snmp walk result.
What is weird to me is that in your first post, you said that SNMPINDEX was "300003533"; "300003533.1"; "300003533.2" and so on. It seems like the 300003533 should be a part of your OID and only the 1 2 3 4 should be your index.

[rusadm]

Hello, I'm solving the same problem now.
I have an Item "SNMP walk" which contains:

.1.3.6.1.2.1.47.1.1.1.1.7.300088062 = STRING: "Ethernet1/51 Lane 4 Transceiver Transmit Power Sensor"
.....
.1.3.6.1.4.1.9.9.91.1.1.1.1.1.300088062 = INTEGER: 14
.....
.1.3.6.1.4.1.9.9.91.1.1.1.1.2.300088062 = INTEGER: 8
.....
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.300088062 = INTEGER: -1911
.....
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.1 = INTEGER: 3998
.....
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.1 = INTEGER: 3998
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.2 = INTEGER: 2397
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.3 = INTEGER: -10604
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.4 = INTEGER: -7619

I have configured Discovery rule with Preprocessing steps "SNMP walk to JSON":

{#TYPE} 1.3.6.1.4.1.9.9.91.1.1.1.1.1
{#VALUE} 1.3.6.1.4.1.9.9.91.1.1.1.1.4
{#SCALE} 1.3.6.1.4.1.9.9.91.1.1.1.1.2
{#NAME} 1.3.6.1.2.1.47.1.1.1.1.7
{#ALARM_HIGH} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.1
{#ALARM_LOW} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.3
{#WARNING_HIGH} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.2
{#WARNING_LOW} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.4

{#TYPE}, {#VALUE}, {#SCALE}, {#NAME} - work correctly.
{#ALARM_HIGH}, {#ALARM_LOW}, {#WARNING_HIGH}, {#WARNING_LOW} - don't work.
These are the Macros I want to use in Triggers.
I did the same settings with "discovery[....]" and they worked.

[novakm]

Maybe your macros aren't working as expected? I'm still a bit unsure about what's the error happening, maybe you could share a bit of the snmp walk result.
What is weird to me is that in your first post, you said that SNMPINDEX was "300003533"; "300003533.1"; "300003533.2" and so on. It seems like the 300003533 should be a part of your OID and only the 1 2 3 4 should be your index.

The 300003533 is the ifIndex and the 300003533.1-4 are additional information connected with thresholds for that particular interface.

[novakm]

Hello, I'm solving the same problem now.
I have an Item "SNMP walk" which contains:

.1.3.6.1.2.1.47.1.1.1.1.7.300088062 = STRING: "Ethernet1/51 Lane 4 Transceiver Transmit Power Sensor"
.....
.1.3.6.1.4.1.9.9.91.1.1.1.1.1.300088062 = INTEGER: 14
.....
.1.3.6.1.4.1.9.9.91.1.1.1.1.2.300088062 = INTEGER: 8
.....
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.300088062 = INTEGER: -1911
.....
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.1 = INTEGER: 3998
.....
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.1 = INTEGER: 3998
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.2 = INTEGER: 2397
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.3 = INTEGER: -10604
.1.3.6.1.4.1.9.9.91.1.2.1.1.4.300088062.4 = INTEGER: -7619

I have configured Discovery rule with Preprocessing steps "SNMP walk to JSON":

{#TYPE} 1.3.6.1.4.1.9.9.91.1.1.1.1.1
{#VALUE} 1.3.6.1.4.1.9.9.91.1.1.1.1.4
{#SCALE} 1.3.6.1.4.1.9.9.91.1.1.1.1.2
{#NAME} 1.3.6.1.2.1.47.1.1.1.1.7
{#ALARM_HIGH} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.1
{#ALARM_LOW} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.3
{#WARNING_HIGH} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.2
{#WARNING_LOW} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.4

{#TYPE}, {#VALUE}, {#SCALE}, {#NAME} - work correctly.
{#ALARM_HIGH}, {#ALARM_LOW}, {#WARNING_HIGH}, {#WARNING_LOW} - don't work.
These are the Macros I want to use in Triggers.
I did the same settings with "discovery[....]" and they worked.

The issue is with the added .1-4 for the entSensorThresholdTable

Would be nice if your idea of using {#ALARM_HIGH} 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.1 worked but Im afraid it's not how it is processed.

For anything from entSensorThresholdTable the {#SNMPINDEX} will be 300088062.1-4 which is what causes issues as I described in my posts above.

[rusadm]

I solved this problem.

1. I changed Discovery rule:
Removed {#ALARM_HIGH}, {#ALARM_LOW}, {#WARNING_HIGH}, {#WARNING_LOW}
Added {#THRESHOLDS} 1.3.6.1.4.1.9.9.91.1.2.1.1.4
2. Then I created 4 Item prototypes with Preprocessing SNMP walk value:
Alarm high 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.1
Alarm low 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.3
Warning high 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.2
Warning low 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.4
3. Created Trigger prototypes using these Item prototypes:
Alarm Trigger (Value > Alarm high or Value < Alarm low)
Warning Trigger (Value > Warning high or Value < Warning low)

The downside of this solution is that it creates a lot of Items.

[novakm]

I solved this problem.

1. I changed Discovery rule:
Removed {#ALARM_HIGH}, {#ALARM_LOW}, {#WARNING_HIGH}, {#WARNING_LOW}
Added {#THRESHOLDS} 1.3.6.1.4.1.9.9.91.1.2.1.1.4
2. Then I created 4 Item prototypes with Preprocessing SNMP walk value:
Alarm high 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.1
Alarm low 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.3
Warning high 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.2
Warning low 1.3.6.1.4.1.9.9.91.1.2.1.1.4.{#SNMPINDEX}.4
3. Created Trigger prototypes using these Item prototypes:
Alarm Trigger (Value > Alarm high or Value < Alarm low)
Warning Trigger (Value > Warning high or Value < Warning low)

The downside of this solution is that it creates a lot of Items.

This works but you end up with lots of unsupported items in case the device has the entSensorThresholdTable empty as I described above. I started with this but dont want to have thousands of unsupported items. If there is a way to not create the item in case it would be unsupported this would be an acceptable solution for me.