I have the same problem.

However, we have 12 core 10G links (24 ports) to monitor that are critical and they are the same ports on all 12 devices

Here are a few related links in case you haven't check these already

This details the change that was made to the interface monitoring:
 
http://dev.zenoss.org/trac/ticket/4997
 
The following changes are pending:
 
http://dev.zenoss.org/trac/ticket/5627
http://dev.zenoss.org/trac/ticket/5628

Here is the what my event transform is. Note that everything was fine prior to upgrade
and follow one of the interface monitoring how tos from the forum.
Prior to upgrading all that was require for a Net/Link transform was to change the
summary and/or message.

Core(2.5):

if hasattr(evt, 'component'):
   fs_id = device.prepId(evt.component)
   for iface in device.os.interfaces():
      if iface.id == fs_id:
          if iface.adminStatus == 1:
             if (fs_id == "Unit 1 Port 25") or (fs_id == "Unit 1 Port 26") or (fs_id == "Unit 1 Port 27") or \
 (fs_id == "Unit 1 Port 28") :
                evt.severity = 5
             else:
                evt.severity = 2 
if evt.summary.startswith('threshold of operational status exceeded'):
        evt.summary = "Interface operationally down"
elif evt.summary.startswith('threshold of operational status restored'):
        evt.summary = "Interface operationally up"

Core(2.4.x):

if evt.summary.startswith('threshold of operational status '):
    if evt.severity > 0:
        evt.summary = "interface operationally down"
    else:
        evt.summary = "interface operationally up"

Note: if you do the later now on 2.5  you get many alerts for interfaces that are Admin'd (UP), Oper'l(DOWN) which is  a normal occurance for many, Ports left active but not used, etc. because for some reason Zenoss now sees the port status as active even if the Operstatus is down.

I too would like a final solution for this and not some hack.

Operstatus and Adminstatus should no way be linked unless adminStatus is down. Why this is, I do not know.

If anyone can shed anymore light on this, that would  be great, possible 1 of the devs

Hi Ryan

I still have some confusion about this item and I kindly ask to read my synthesis and tell me if I have correctly understood:

If I have correctly understood, when you add a device (for example a cisco switch), zenoss will monitor ALL interfaces and, starting from zenoss 2.5 it will generate rrd graphs for all interfaces (this is explained by jcurry in this post message/44295#44295) but won't generate alerts whenever interface's status change from up to down. In my opinion this default setting is good because otherwise you could receive lot of alerts (I think to a 48 switch port on which are connected user's pc that often power off their computer) but, could be there situations in which is necessary to get alarms when specific interfaces on a specific device go down (or on a class like /network/cisco/router).

In this case the solution is in the link that you specified (docs/DOC-2494) but it is not correct because the event class is not "/Net/Link" but "/Status/IpInterface".

Questions:

-Does I have correctly understood how zenoss manage the status of interfaces (up/down) and the related alerts?

-Could you fix the documentation in the link?

Please feel free to correct me and give me some tips.

Regard

Marco

Hi Ryan

thans for your clarification.I kindly ask you just some other explanation that I'm sure will be appreciated by other users:

1) Are alerts generated whenever interface status change?

As you explained when you first model a device, Zenoss will ONLY set the interfaces that are shown as being active to monitored. This is clear but, in this case, will events AUTOMATICALLY generated if a monitored interface goes down?

2) If you want to change this behavior ( Zenoss will ONLY set the interfaces that are shown as being active to monitored), the solution is that one descibed in the Chet's document. To sum up this is a workaround because, as you explained, "Interface status polling is more effective than traps in my opinion and it should be a built in option (but not necessarily enabled by default)".

Correct?

3)You say: "it is then YOUR responsibility to go through and only set the ports that you want monitored to monitored status when commissioning the device".

Because this is time expensive and in my opinion quite frustrating, a good solution would be to "to massive disable monitor ipinterface for all devices" as described in this post message/19580#19580 and, after, manually reenable the monitoring for the interfaces on which you need get alerts whenever they go down.

Correct?

Marco

Ryan Matte wrote, On 1/7/2010 11:43 AM:

(what alerts are not generated automatically?).

Well, EVENTS are generated automatically, but at least for me, if you

haven't created an alerting rule to match on the event (which you might

well have done) you won't get an ALERT (That is, and e-mail)...

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University

Yes, I figured you did. I was trying to inform (though perhaps too

subtly) that Zenoss terminology is specific, and he may be confusing

himself or others with the wrong terms ...

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University

Ryan Matte wrote, On 1/7/2010 11:59 AM:

Right, I understand that, he seemed to be using the term "Alert" as general definition for events, so I responded accordingly.  Of course the actual alerting varies based on user configuration.

Hi Marco,

I think James and Ryan have covered just about everything.  One thing that doesn't seem to have been emphasised is that with the 2.5.x design, the "whether to model an interface" decision is based on the SNMP ifAdminStatus value.  If your organisation ensures that unused interfaces are configured down and this is reflected by the SNMP agent in ifAdminStatus, then there should be no problem.  They won't be discovered, modelled or have SNMP data gathered.  Our problem comes with lots of switches which have ifAdminStatus = Up and ifOperStatus = Down.

Did you find the TRAC ticket raised by Chet as a result of the earlier discussion? - http://dev.zenoss.org/trac/ticket/5943 .

As James and Ryan discussed, currently you can only generate events (with optional, customised alerts) based on ifOperStatus, if you set that up as an extra performance data point to be tested and thresholded every 5 minutes (by default).  If you ensure that the event generated by the threshold is  /Status/IpInterface rather than the default /Net/Link then the coloured icon against the interface in the main OS tab, will reflect the status of the most recent event - red for down and green for up.

If you really don't like the 2.5 way of determining active interfaces, based on ifAdminStatus, and want to return to the 2.4 design, based on ifOperStatus, then you can return to the previous model of data collection by modifying $ZENHOME/Products/ZenModel/IpInterface.py and change adminStatus to operStatus in the snmpIgnore method (make quite sure you have a backup of this file first and be aware that you would have to maintain this yourself after any Zenoss upgrade).  If you are largely monitoring switches with many inactive interfaces but all have ifAdminStatus = Up, then this change can save LOTS of performance polling every 5 minutes and LOTS of space for unwanted performance RRD files.

To answer your specific questions:

1) - you are correct (assuming by "Up" you mean ifAdminStatus = Up).   On the first discovery poll you will discover and start monitoring 30 interfaces.  12 hours later on the next modeler poll, another 10 are also ifAdminStaus = Up so they are added to the configuration database and added to the 5-minute SNMP performance poll list.  If you have done the extra configuration to performance poll and threshold ifOperStatus then, initially you could receive events for upto 30 interfaces; after the second modelling poll, potentially you get events from 40 interfaces.  If on the third modeler poll the remaining 8 interfaces are ifAdminStatus=Up, then you will model and poll (and potentially get events from) all 48 interfaces.  The issue, potentially, is that if the ifAdminStatus is not detected as ifAdminStatus=Down on a subsequent 12-hour modeler poll, but, say, 18 of your interfaces are now ifOperStatus=down, then you are still gathering data every 5 minutes for those 18 down interfaces.  Nothing will remove their rrd data files.

2) As you say, if you have a single collector (which is likely for Zenoss Core), then you have a single SNMP polling interval, whose default is 300 seconds, or 5 minutes.

Cheers,

Jane

Hi Marco,

You are absolutely correct - right up until your last suggestion - "would be to configure "active monitoring" on core switch (where interfaces with important devices connected never should be go down) and just leave the default on other switch. In practise I should apply the "interface template" only to core switch."

The slight problem with your suggestion is that one does not bind component templates  (which the interface ethernetCsmacd template is) - they get bound automatically - it's not your choice.  Neither can you bind component templates to a specific device - they simply don't appear in the dropdown list.

What you could do, is this.

Go to /Devices/Network/Switch and create a suborganizer, say, CoreSwitch.  Back at /Devices/Network , select the Templates tab.  Select the ethernetCsmacd  template and use the dropdown menu to copy this template to /Devices/Network/Switch/CoreSwitch.  From /Devices/Network/Switch/CoreSwitch, use the templates tab to modify this copy of  the etherCsmacd template to poll and threshold ifOperStatus, as discussed previously.  Whatever you do don't change the name of the template itself - it must be ethernetCsmacd - the same as the name of the component object.  You may need to do this for the etherCsmacd_64 template too.  Then move your core switch(es) from the /Network/Switch class to the /Network/Switch/CoreSwitch class.

With templates of the same name (in fact, whether they are component templates or device templates), the instance lowest down the device hierarchy applies; so your little switches will get the standard template without ifOperStatus monitoring but your core switch(es) down in /Network/Switch/CoreSwitch will have the extra ifOperStatus monitoring with it's events configured for thresholds.

Does that make sense??  Then, I think your statement "In this way I should receive events ONLY for critical interfaces and not whenever users power off their pc.", should be true.  You will still be polling for performance data from all interfaces with ifAdminStatus=Up and ifOperStatus=Down, but at least you won't be getting events about the status.

Cheers,

Jane