Ad Widget

Collapse

Item prototype name dependent on value of {#SNMPINDEX} macro

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • rondo
    Junior Member
    • Feb 2022
    • 5

    #1

    Item prototype name dependent on value of {#SNMPINDEX} macro

    Zabbix 6.0.0
    I am monitoring a Dell SAN with two storage controllers networked together. Due to this, my current item prototypes are returning values for both controllers, as expected.
    Problem: The item names that are generated for both storage controllers are identical. See below:

    Click image for larger version  Name:	image.png Views:	11 Size:	47.0 KB ID:	440608

    My preferred solution would be to use the {#SNMPVALUE} of the OID that returns the controller name in its corresponding item. Below is the snmpwalk that returns the controller name.

    Code:
    snmpwalk 192.168.128.220 -v1 -c public .1.3.6.1.4.1.674.11000.2000.500.1.2.13.1.4
    scCtlrName.1 = STRING: SN 45064
    scCtlrName.2 = STRING: SN 45065
    So the items would read like this:

    Click image for larger version  Name:	image2.png Views:	8 Size:	21.4 KB ID:	440609
    All OIDs that correspond to SN 45064 end in 1.x, and all OIDs that correspond to SN 45065 end in 2.x. See example below:
    Code:
    snmpwalk 192.168.128.220 -v1 -c public .1.3.6.1.4.1.674.11000.2000.500.1.2.16.1.4
    scCtlrFanName.1.1 = STRING: Fan 1
    scCtlrFanName.1.2 = STRING: Fan 2
    scCtlrFanName.1.3 = STRING: Fan 3
    scCtlrFanName.1.4 = STRING: Fan 4
    scCtlrFanName.1.5 = STRING: Fan 5
    scCtlrFanName.1.6 = STRING: Fan 6
    scCtlrFanName.2.1 = STRING: Fan 1
    scCtlrFanName.2.2 = STRING: Fan 2
    scCtlrFanName.2.3 = STRING: Fan 3
    scCtlrFanName.2.4 = STRING: Fan 4
    scCtlrFanName.2.5 = STRING: Fan 5
    scCtlrFanName.2.6 = STRING: Fan 6
    This is true for all OIDs I am working with in this SAN.
    What I have tried:
    1. Making separate hosts for each controller using the IP address of the controller itself instead of the IP address of the SAN - problem: the OIDs still discover both controllers even when snmpwalk-ing the hosts individually.
    2. Using an OID in the prototype OR discovery rule that will only return one controller at a time. - problem: There is no OID that can produce output for just one controller. Adding a .1 or .2 to the end of the snmpwalk above in hopes of producing one controller or the other yields no results.
      Code:
      snmpwalk 192.168.128.220 -v1 -c public .1.3.6.1.4.1.674.11000.2000.500.1.2.16.1.4.1
      or
      Code:
      snmpwalk 192.168.128.220 -v1 -c public .1.3.6.1.4.1.674.11000.2000.500.1.2.16.1.4.2
    3. Using a regsub macro function with {#SNMPINDEX} in the item prototype to "filter" only one controller at a time. See below
      Click image for larger version  Name:	image3.png Views:	8 Size:	24.7 KB ID:	440610
      problem: this still creates items for both controllers (I did not think it would, but I must be misunderstanding how the regsub function works). The items that don't match the regex above are still created, but have an error. See below:
      Click image for larger version  Name:	image4.png Views:	9 Size:	54.7 KB ID:	440611
      The error reads - snmp_parse_oid(): cannot parse OID ".1.3.6.1.4.1.674.11000.2000.500.1.2.16.1.5.".
    4. Add the OID that returns the SN 45xxx to the discovery rule - discovery[{#CTLRNAME}, oid1 …,] and add {#CTLRNAME} to the item prototype. problem: {#CTLRNAME} corresponds to two values (SN 45064, SN 45065) and cannot generate more than two items with that macro when there are more than two fan/temp/cpu/psu items.
    The fact that all OIDs for controller 45064 end with 1.x and all OIDs for controller 45065 end in 2.x makes me think there is an easy solution to this. I believe that is all I have tried troubleshooting. Does anybody have any suggestions for how to solve this? Thank you.
    Last edited by rondo; 01-03-2022, 19:24.
Working...