Zabbix Team,
I have been testing 1.9.9 in the lab and am finding some issues with low level discovery, so I figured I would post some feedback:
1. Low level discovery is useful to automatically generate graphs and items for routers. Other projects such as cacti do this very well, but zabbix has always required the user to manually create the items and graphs for everything which is very work intensive.
While using low level discovery I used
ifInOctets["index","ifDescr","{#SNMPVALUE}"]
for the OID and
ifInOctets["{#SNMPVALUE}"]
for both the key and name.
The idea is to have low level discovery detect all of the interfaces, then create an ifInOctets for each one. It's important to use dynamic indexes because the oid index tends to change on routers over time.
This worked fine until I hit a router that used this for it's interface description:
1/2/7, 10/100/Gig Ethernet SFP, "to 7705-1.lnbg GE1/1/7 PathC via CRMT"
It seems that zabbix doesn't escape the " in the string so the item that is created never returns data.
2. When using 86400 seconds for the interval for discovery rules (I don't want zabbix walking the interface table all the time) it doesn't start to detect interfaces for 86400 seconds. I would expect it to run the first poll immediately then wait, but it seems like it waits first.
3. When you create the discovery rules in a template then link the template to a host you can't delete or disable the detected interfaces. I don't want to monitor every interface, but I want it to find them all so that I can disable the ones I don't want.
I think I would rather zabbix create the items for each host according to discovery instead of having everything in a template, unfortunately the only way I can see to do that would be to create discovery rules for each host which is kinda silly since they would be exactly the same in the case of interfaces.
These issues are big enough to cause our network engineer to look at cacti since he can point it at a router and it sorts out the interfaces and graphs using dynamic indexes, however it would be much better to have this in zabbix so that we can use the same data for alarming as well.
Let me know if you need any other details or need me to test anything.
I have been testing 1.9.9 in the lab and am finding some issues with low level discovery, so I figured I would post some feedback:
1. Low level discovery is useful to automatically generate graphs and items for routers. Other projects such as cacti do this very well, but zabbix has always required the user to manually create the items and graphs for everything which is very work intensive.
While using low level discovery I used
ifInOctets["index","ifDescr","{#SNMPVALUE}"]
for the OID and
ifInOctets["{#SNMPVALUE}"]
for both the key and name.
The idea is to have low level discovery detect all of the interfaces, then create an ifInOctets for each one. It's important to use dynamic indexes because the oid index tends to change on routers over time.
This worked fine until I hit a router that used this for it's interface description:
1/2/7, 10/100/Gig Ethernet SFP, "to 7705-1.lnbg GE1/1/7 PathC via CRMT"
It seems that zabbix doesn't escape the " in the string so the item that is created never returns data.
2. When using 86400 seconds for the interval for discovery rules (I don't want zabbix walking the interface table all the time) it doesn't start to detect interfaces for 86400 seconds. I would expect it to run the first poll immediately then wait, but it seems like it waits first.
3. When you create the discovery rules in a template then link the template to a host you can't delete or disable the detected interfaces. I don't want to monitor every interface, but I want it to find them all so that I can disable the ones I don't want.
I think I would rather zabbix create the items for each host according to discovery instead of having everything in a template, unfortunately the only way I can see to do that would be to create discovery rules for each host which is kinda silly since they would be exactly the same in the case of interfaces.
These issues are big enough to cause our network engineer to look at cacti since he can point it at a router and it sorts out the interfaces and graphs using dynamic indexes, however it would be much better to have this in zabbix so that we can use the same data for alarming as well.
Let me know if you need any other details or need me to test anything.
Comment