simon123
08-06-2011, 22:34
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 (as described in the manual) the items created can only have either the given name (e.g. eth0) or the index number of the NIC (OID).
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 hart.
A workaround for this would be to use the ipAdEntIfIndex OID (as rule). 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) in your prototype item. This would work great except for the fact that the index macro ({#SNMPINDEX}) in this case is only the last digits of the OID (everything following the last point).
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.
Any ideas on this?
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 (as described in the manual) the items created can only have either the given name (e.g. eth0) or the index number of the NIC (OID).
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 hart.
A workaround for this would be to use the ipAdEntIfIndex OID (as rule). 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) in your prototype item. This would work great except for the fact that the index macro ({#SNMPINDEX}) in this case is only the last digits of the OID (everything following the last point).
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.
Any ideas on this?