Uploaded image for project: 'ZABBIX FEATURE REQUESTS'
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-2250

Evaluating NULL values in trigger (Combine SNMP-trap item and and SNMP-get item in one trigger expression)

XMLWordPrintable

    • Icon: New Feature Request New Feature Request
    • Resolution: Duplicate
    • Icon: Major Major
    • None
    • 2.2.2, 2.2.3
    • Server (S)

      I'm trying to create one neat trigger for IF-MIB port operational status monitoring,

      This Trigger is ON when either:
      A: (the classic polling way) When last snmp-get polling returns 2 like:

      ifOperStatus.["1"].last(0)}=2)

      OR
      B: (snmptrap way) When snmptrap is received by snmptrapd, parsed by snmptt and delivered by zabbix using snmprtap. like:

      host:snmptrap[interface\s1].str(down)}=1

      Trigger is OFF when
      A: (trap way) new trap is received stating that interface is up ( not down)
      OR
      B: (polling) snmp-get polling returns that interface is not down (!=2)

      Complete trigger expression is for if1:

      ({host:snmptrap[interface\s1].str(down)}=1 & {host:snmptrap[interface\s1].nodata(600)}=0)
      |
      ({host:ifOperStatus.["1"].last(0)}=2 & {host:snmptrap[interface\s1].nodata(600)}=1)
      

      This trigger is attached to the switch template that is universal. Some switches send traps and some of them don't.

      Trigger like this gives me all the benefits from SNMP polling and SNMP traps:

      • instant notification (SNMP trap)
      • Port statuses syncronization via SNMP-get (which is important in case of network transport problems when SNMP-trap UDP packet might get lost in transition)
      • Universal approach and backward compatibility: I can monitor all kind of network devices, no matter if they support snmp-traps and were they configured properly or not.
      • Warranty that trigger stating "Port x is down" will never become enternal ON, in case when (linkdown is received by the system and clearing trap linkup isn't)

      But there is one little problem that blocks this trigger from proper working:

      Problem is that when zabbix never receives a trap from the switch for that interface (since there is individual snmp-trap item for every interface index)

      Trigger is never evaluated since part of expression: snmptrap[interface\s1] item's last value is NULL (trap is never received)

      Once you receive a single trap - it's all fine from that moment

      ___________________________

      I suggest:

      Make evaluation of trigger's expression like:

      host:snmptrap[interface\s1].str(down)} to return 1 (TRUE) if there are no values collected for that item (

      so the triggers are in OK status not UNKNOWN in such a case

            Unassigned Unassigned
            gospodin.horoshiy Vitaly Zhuravlev
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: