Not sure if I follow (hope others do)

Dear Sir,

I am writing to thank you for your interesting letter about this matter 
and say,

On Thu, Nov 07, 2002 at 11:34:18AM -0500, Brian E. Seppanen wrote:
> Hi Folks:
> 
> I have a theoretical question to which there is no right or wrong answer,
> but I wanted to present a situation and see if there was a possible
> solution or a best practice.
> 
> We use netsaint for a lot of our monitoring, and despite the fact that
> netsaint (nagios) isn't intended as a NMS -- as the documentation
> indicates,

The combination of Netsaint/Nag and Net-SNMP seems superb to me.

> -- I find myself being told to script trap events into netsaint
> on a regular basis. 

This seems to be a matter of (if you are using net-snmp as documented)

. installing the MIB defining the trap you are interested in (managing 
numeric OIDs sounds too much like work)

. indentifying the trap to the trap handler (snmptrapd.conf if you are 
using snmptrapd) and arranging for the appropriate handler to be invoked 
(maybe passing it the trap number as the Netsaint docco illustrates)

. having a handler map the trap into a Netsaint service check (defined 
accordingly) by identifying the Netsaint host and Service and then 
outputting the PROCESS_SERVICE_CHECK_RESULT message to the Netsaint 
command queue (named pipe) as so wonderfully documented.

> One of the problems with trap events is that you can
> receive multiple traps at any one time for a single device.  If you're
> like me and you define a single placeholder for traps to ease
> administration, this usually means the last trap wins, and others would be
> missed, or the traps need to be consolidated so that they all show up and
> are aggregated, which isn't always very easy to do.   I've used both 
> scenarios.
> 

I agree that multiple traps is not good if the service check is
non-volatile (I have abandoned non-volatile services for traps as a
result)  because the extra traps lead to superfluous notification.

But wouldn't you either want to handle any traps that weren't ignored 
(logged or whatever) individually and independently of other traps ?

When you say 'a single placeholder for traps' do you mean that one event 
handler deals with many different traps without distinguishing them ?


> Is there any way to include what I would term expandable containers that
> would increase to hold an increasing number events.  Of course the problem
> becomes one of then making sure that a corresponding container for a
> specific event has it's corrolary event clear/reset/expand the original
> trap.  Which introduces a number of different problems.
> 

What is a container; a persistent store of trap events ?

Why would you want to keep traps (since they are logged anyway by 
snmptrapd) ?

Or is it an 'aggregate/container object' (as in OO) that the trap
handler can refer to for what to do, perhaps by generating a new 'trap
object' from the trap and then calling that objects handle method ?

Such an object would eliminate the case structure that the documented
and intuitive event handlers have, and perhaps replace maintaining the
event handler by maintaining the 'object' (adding new methods,
recognising new traps etc).

If this is what you were referring to then maybe the CPAN Mon::SNMP
module might be useful.


> What have others done?   
>

I am only starting down this road so I hope someone that knows something 
will respond, but I am 

. handling Foundry SLB trap alerts of 'real server' state changes by a
handler that informs Netsaint of a hard state change between 'OK' and
'CRITICAL' depending on the trap number.

. handling newRoot bridge traps by a handler that changes the state of a 
key switch/bridge to 'CRITICAL'

(this service must be reset by a synthetic trap from the manager
informing Netsaint that STP has recomputed the original root of the
spanning tree. Lots of fun if you like inventing trap OIDs.)

. I am hoping to get routers to send Frame Relay PVC traps as soon as I 
can find the MIB that Cisco uses ...


 
> Thanks,
> 
> Brian Seppanen


Yours sincerely.


-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html