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

Low-level discovery IP-Adresses

XMLWordPrintable

    • Icon: New Feature Request New Feature Request
    • Resolution: Duplicate
    • Icon: Trivial Trivial
    • None
    • 1.9.4 (alpha)
    • None
    • All

      First of all, let me say: i'm a great fan of this product and love the new low-level discovery feature.

      I was testing the 1.9.4, and would need it almost exclusivly for it's SNMP monitoring capabilities.
      The low-level discovery feature is a great help in deploying and maintaining a large network environment, thumbs up for that one!
      Monitoring storage usage with this feature works like a charm.

      When it comes to monitoring network traffic however, low-level discovery has some restrictions for me. Let me explain by example:

      When we monitor network traffic, we like to make items/graphs/triggers and categorize all items/triggers/graphs with the IP-Adres.
      So it would say something like "Incoming traffic on 192.168.50.1". In previous versions i was able to do this with macro's.

      Here's the kicker: when you use low-level discovery the items created can only have either the given name (e.g. eth0) or the index number of the NIC.
      This naming convention is great if you only have a couple of servers and know your way around each of them. For large environments however these item/graph/trigger names would be useless.
      Unless you know what "Intel(R) PRO/1000 MT Network Connection #4" on machine gate02.example.com is connected to by haert.

      A workaround for this would be to use the ipAdEntIfIndex OID. This produces something like:

      root@zbx-beta:/tmp/zabbix-1.9.4# snmpwalk -v1 -cpublic 172.16.80.151 1.3.6.1.2.1.4.20.1.2
      iso.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 1
      iso.3.6.1.2.1.4.20.1.2.172.16.80.151 = INTEGER: 2

      So you could use the index (being the IP-Address) and the value (being the NIC card OID Index). This would work great except for the fact that the index macro (

      {#SNMPINDEX}

      ) in this case is only the last digits of the OID.
      So i get items like: "Incoming traffic on 151" instead of the full IP. It would be great to have an option on choosing wether to use the last part of the OID or use the last 4 parts, as is the case with IPv4 addresses.

      I think that using only the last digits of the OID as a hardcoded option will cause issues for other OID's as well.

            Unassigned Unassigned
            simonris Simon Kerckhof
            Votes:
            6 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: