Thanks Rory
I was considering option 1 but it is not feasible as the OID of the additional
varbinds may refer to entries in large tables, e.g. UCD-SNMP-MIB::prTable. It
is simply impossible to list the thousands of possible varbind mappings.
Regardless of that it's good to know that one can have more varbind mappings
than actual varbinds in a trap. I might need this somewhere else.
Regarding option 2 I had a look at the relevant section in the Event
Configuration Guide but it's not really clear to me how to achieve what I want.
I am still a bit confused with Spectrum terminology here (I only started
working with Spectrum at this level about three weeks ago). My understanding of
Spectrum's workflow with trap processing is this:
TRAP -> AlertMap -> EVENT -> EventDisp -> ALARM
So isn't it true that once we reach the EVENT stage all varbinds in the TRAP
that were not mapped in AlertMap are "lost". So how can I access such
"un-mapped" varbinds through Event Procedures?
Markus
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Monday, 19 October 2009 8:03 PM
To: Juenemann, Markus; [email protected]
Subject: Re: [spectrum] Additional varbinds with varying OID
Markus,
You have 2 options here.
1. Include all possible oids in your alertmap mapping. Just because your trap
has 5 varvinds doesn't stop you having 100 varbind mappings. Then use an event
condition to decide which of your mapped event you pass though to your final
event.
2. Use an event procedure in your event disp to do what you suggest and pull
additional attrs into your event. Event procedures are documented in v9 docs
but have worked since v7. They take a bit of effort to get your head round them
but are really powerful. Make sure you define an eventdisp log file in .vnmrc
so you have chance of debugging them.
Rory
________________________________
From: Juenemann, Markus <[email protected]>
To: spectrum <[email protected]>
Sent: Mon Oct 19 05:12:39 2009
Subject: [spectrum] Additional varbinds with varying OID
Hi all
I want to process DISMAN event traps which are sent by a Net-SNMP daemon. The
problem I have is that these traps contain additional varbinds whose OID depend
on the value of another varbind.
The Net-SNMP software can monitor certain resources (processes, disk space,
etc.) locally. If a configured threshold is violated a mteTriggerFired (see
http://tools.ietf.org/html/draft-ietf-disman-event-mib-09) notification will be
sent. While the standard lists five varbinds for this notification, the trap
actually contains another two varbinds with important information (I believe
sending additional varbinds is actually standards-compliant). Unfortunately the
OID of these varbinds depend on the resource that was monitored, i.e. they are
not fixed!
In terms of AlertMap entries this can be described like this:
1.3.6.1.2.1.88.2.6.1 0xffffff10 \
# mteHotTrigger
1.3.6.1.2.1.88.2.1 (1,0) \
# mteHotTargetName
1.3.6.1.2.1.88.2.2 (2,0) \
# mteHotContextName
1.3.6.1.2.1.88.2.3 (3,0) \
# mteHotOID
1.3.6.1.2.1.88.2.4 (4,0) \
# mteHotValue
1.3.6.1.2.1.88.2.5 (5,0) \
# additional varbind 1
1.3.6.1.4.1.2021.a.b.c (6,7) \
# additional varbind 2
1.3.6.1.4.1.2021.x.y.z (7,8)
The problem is that the actual values of 'a.b.c' and 'x.y.z' depend on the
value of mteHotOID and only the last two varbinds provide sufficient
information to understand the event without any further investigation.
Is there a method in Spectrum where one can either have a wildcard notation for
varbind OID or alternatively can I dynamically poll SNMP information during
event processing?
I hope I provided sufficient information.
Thanks
Markus
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
_____________________________________________________________________
This e-mail has been scanned for viruses by MCI's Internet Managed
Scanning Services - powered by MessageLabs. For further information
visit http://www.mci.com
* --To unsubscribe from spectrum, send email to
[email protected]<mailto:[email protected]> with the body: unsubscribe spectrum
[email protected]
_______________________________________________
This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. If you are not an intended recipient of
this e-mail, do not duplicate or redistribute it by any means. Please delete it
and any attachments and notify the sender that you have received it in error.
Unless specifically indicated, this e-mail is not an offer to buy or sell or a
solicitation to buy or sell any securities, investment products or other
financial product or service, an official confirmation of any transaction, or
an official statement of Barclays. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Barclays. This
e-mail is subject to terms available at the following link:
www.barcap.com/emaildisclaimer<http://www.barcap.com/emaildisclaimer>. By
messaging with Barclays you consent to the foregoing. Barclays Capital is the
investment banking division of Barclays Bank PLC, a company registered in
England (number 1026167) with its registered office at 1 Churchill Place,
London, E14 5HP. This email may relate to or be sent from other members of the
Barclays Group.
_______________________________________________
_____________________________________________________________________
This e-mail has been scanned for viruses by MCI's Internet Managed
Scanning Services - powered by MessageLabs. For further information
visit http://www.mci.com
---
To unsubscribe from spectrum, send email to [email protected] with the body:
unsubscribe spectrum [email protected]
