There appear to be some subtle changes between 2.4.1 and 2.5.1 with respect to the way performance data is collected for interfaces of devices. I know that interface status display has changed from separate icons for Admin Status and Operational Status (in 2.4) to a single icon representing Status (in 2.5).
With 2.4.1, when a device is initially discovered the InterfaceMap collector gets all interfaces (of any status). It looks like zenmodeler sends an Async update to zenperfsnmp for every interface with an operational status of Up. When zenperfsnmp next runs, it creates RRD files for those interfaces with an Up operational status and collects data. If an interface subsequently changes from Down to Up, this is not detected until the device is remodeled. At this time, an Async update is sent to zenperfsnmp and on the next perf cycle, a new RRD file is created for that extra Up interface and data is collected. If on a modeler cycle, the interface oper status has changed from Up to Down then on the next perf cycle, data is ONLY collected from interfaces with operStatus = Up.
With 2.5.1, when a device is initially discovered the InterfaceMap collector gets all interfaces (of any status). It looks like zenmodeler sends an Async update to zenperfsnmp for every interface - regardless of ifOperStatus. When zenperfsnmp next runs, it creates RRD files for ALL interfaces and continues to monitor them all every zenperfsnmp cycle, regardless of ifOperStatus. However, 2.5.1 does appear to detect a change in ifOperStatus on a performance cycle - no remodel is needed to detect the change - but it still collects data on all interfaces, regardless.
Where devices are switches, many of which have ports that have never been connected, this means that there are hugely more RRD files and that ALL interfaces are polled every snmp polling cycle, rather than just the ifOperStatus=Up interfaces. Typically the ifAdminStatus of all ports is Up.
I have had quite a good look around the code and cannot see where the test is done to decide whether to collect interface performance data - can anyone help???
A combination of the old and new code would be great if a perf cycle could detect changes in ifOperStatus (new in 2.5) but could also then use that status to determine what data to gather on this perf cycle.
Any other comments?
Cheers,
Jane
