So I am guessing the events you are interested in are all those /Unknown traps in the top half of your screenshot? We need to find a way to decide which ones are important. Again, I am guessing that the different traps are from different types of Cisco device??? Double click on some of those traps and scroll into the event detail - there may be stuff down there with other OIDs that we can use to determine whether it is an "important" device / interface or not. What I am thinking is there may be an attribute for interface name and we could then do a pattern match on such an attribute.
| Subject: |
RE: Monitor and send alarm on important interfaces |
| Author: |
Stig Wangdell |
| Posted: |
2018-01-17 09:05 |
Hi
I try to unplug a rj45 cabel in the switch. Some test interface
port GigabitEthernet0/1 and GigabitEthernet0/6.
See the trap information further down.
Then I agree with you how to name or how to know which interface is important. Can i give them a special name on the description field in cisco so zenoss can pick it up what is the best and easiest way to to this.?I have try this event transform in the root, but no luck.
if evt.component=='GigabitEthernet0/1' and evt.device=='172.27.1.21':
evt.severity=5
Getting this events in zenoss.
| Resource: |
|
| Component: |
|
| Event Class: |
|
| Status: |
New |
| Message: |
snmp trap 1.3.6.1.6.3.1.1.5.3 |
|
|
|
| agent |
zentrap |
| component |
null |
| dedupid |
|
| eventClass |
|
| eventClassKey |
1.3.6.1.6.3.1.1.5.3 |
| eventClassMapping |
|
| eventGroup |
trap |
| eventKey |
|
| eventState |
New |
| evid |
00505685-717d-bf17-11e7-fb7a344f8ce7 |
| facility |
|
| message |
snmp trap 1.3.6.1.6.3.1.1.5.3 |
| ntevid |
|
| priority |
|
| severity |
3 |
| summary |
snmp trap 1.3.6.1.6.3.1.1.5.3 |
|
|
|
| DeviceClass |
/Network/Router/Cisco |
| DeviceGroups |
|
| DevicePriority |
Normal |
| Location |
|
| Systems |
|
| device |
|
| ipAddress |
172.27.1.21 |
| monitor |
localhost |
| prodState |
Production |
|
|
|
|
|
|
|
| 1.3.6.1.2.1.1.3.0 |
1287335692 |
| 1.3.6.1.2.1.2.2.1.1.10101 |
10101 |
| 1.3.6.1.2.1.2.2.1.1.10106 |
10106 |
| 1.3.6.1.2.1.2.2.1.2.10101 |
GigabitEthernet0/1 |
| 1.3.6.1.2.1.2.2.1.2.10106 |
GigabitEthernet0/6 |
| 1.3.6.1.2.1.2.2.1.3.10101 |
6 |
| 1.3.6.1.2.1.2.2.1.3.10106 |
6 |
| 1.3.6.1.4.1.9.2.2.1.1.20.10101 |
down |
| 1.3.6.1.4.1.9.2.2.1.1.20.10106 |
down |
| community |
public |
| manager |
|
| oid |
1.3.6.1.6.3.1.1.5.3 |
| zenoss.device.device_class |
/Network/Router/Cisco |
| zenoss.device.ip_address |
172.27.1.21 |
| zenoss.device.priority |
3 |
| zenoss.device.production_state |
1000 |
|
| Resource: |
|
| Component: |
|
| Event Class: |
|
| Status: |
New |
| Message: |
snmp trap 1.3.6.1.6.3.1.1.5.4 |
|
|
|
| agent |
zentrap |
| component |
null |
| dedupid |
|
| eventClass |
|
| eventClassKey |
1.3.6.1.6.3.1.1.5.4 |
| eventClassMapping |
|
| eventGroup |
trap |
| eventKey |
|
| eventState |
New |
| evid |
00505685-717d-bf17-11e7-fb7a3d39a7a8 |
| facility |
|
| message |
snmp trap 1.3.6.1.6.3.1.1.5.4 |
| ntevid |
|
| priority |
|
| severity |
3 |
| summary |
snmp trap 1.3.6.1.6.3.1.1.5.4 |
|
|
|
| DeviceClass |
/Network/Router/Cisco |
| DeviceGroups |
|
| DevicePriority |
Normal |
| Location |
|
| Systems |
|
| device |
|
| ipAddress |
172.27.1.21 |
| monitor |
localhost |
| prodState |
Production |
|
|
|
|
|
|
|
| 1.3.6.1.2.1.1.3.0 |
1287336617 |
| 1.3.6.1.2.1.2.2.1.1.10101 |
10101 |
| 1.3.6.1.2.1.2.2.1.1.10106 |
10106 |
| 1.3.6.1.2.1.2.2.1.2.10101 |
GigabitEthernet0/1 |
| 1.3.6.1.2.1.2.2.1.2.10106 |
GigabitEthernet0/6 |
| 1.3.6.1.2.1.2.2.1.3.10101 |
6 |
| 1.3.6.1.2.1.2.2.1.3.10106 |
6 |
| 1.3.6.1.4.1.9.2.2.1.1.20.10101 |
up |
| 1.3.6.1.4.1.9.2.2.1.1.20.10106 |
up |
| community |
public |
| manager |
|
| oid |
1.3.6.1.6.3.1.1.5.4 |
| zenoss.device.device_class |
/Network/Router/Cisco |
| zenoss.device.ip_address |
172.27.1.21 |
| zenoss.device.priority |
3 |
| zenoss.device.production_state |
1000 |
|
From cisco
http://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?local=en
1.3.6.1.6.3.1.1.5.41.3.6.1.6.3.1.1.5.4ifIndex ifAdminStatus ifOperStatus
"A linkUp trap signifies that the SNMP entity, acting in anagent role, has detected that the ifOperStatus object forone of its communication links left the down state andtransitioned into some other state (but not into thenotPresent state). This other state is indicated by theincluded value of ifOperStatus."
---------------------------1.3.6.1.6.3.1.1.5.3
Trap Components ifIndex ifAdminStatus ifOperStatus Description "A linkDown trap signifies that the SNMP entity, acting inan agent role, has detected that the ifOperStatus object forone of its communication links is about to enter the downstate from some other state (but not from the notPresentstate). This other state is indicated by the included valueof ifOperStatus."
------------------------------
Stig Wangdell
------------------------------
| Subject: |
RE: Monitor and send alarm on important interfaces |
| Author: |
Jane Curry |
| Posted: |
2018-01-18 04:14 |
OK - so a couple of things you might look at....
Your idea with transforms is definitely on the correct lines but your problem is that evt.component is not populated by this trap. However, the information you want is in the event details against the OID 1.3.6.1.2.1.2.2.1.2.10101. In a transform, care is needed in grabbing values of event attributes whose key has a "." in it (ie. 1.3.6.1.2.1.2.2.1.2.10101 ). Get my "Event Management for Zenoss Core 4" paper from
https://www.skills-1st.co.uk/papers/jane/zenoss4-events/ and have a look at chapter 9 for help with testing such attributes.
With regard to filling in description fields for interfaces, this is always good practice and can be helpful. Zenoss will pick up a description field when it models the device. What I don't know is whether a trap that is sent from this box, will also use description information on the trap. I suggest you configure it on your test device and interface and see if you get any more of those OID event attributes showing your description.
Another thing I would caution you is that you obviously have not imported any relevant SNMP MIBs for this device as your OIDs are starting with 1.3.6.1. TRAPS (and only TRAPs and NOTIFICATIONs) use imported MIBs to translate OIDs, which can sometimes be very helpful. You do not HAVE to import MIBs, however the thing to be very wary of is if you write a transform now that looks for an event key of 1.3.6.1.2.1.2.2.1.2.10101 and subsequently you, or a colleague, import a relevant MIB that translates some of this trap to something like enterprises.2.1.2.10101, then your transform will fail. The MIB translation, if possible, happens as the TRAP is received by Zenoss - you don't get to say whether to do the translation if the MIB has been imported. Net of all that is that you might consider determining what MIBs might be useful and importing them BEFORE doing your transform work.
Cheers,
Jane
------------------------------
Jane Curry
Skills 1st United Kingdom
jane.curry@skills-1st.co.uk
------------------------------
