win eventlog snmp monitoring (was: ev2T -> snmptrapd -> Nagios )

Stanley Hopcroft Stanley.Hopcroft at IPAustralia.Gov.AU
Thu Mar 18 23:45:07 CET 2004


Dear Sir,

I am writing to thank you for your letter and say,


> Date: Thu, 18 Mar 2004 09:34:58 +0100
> From: =?windows-1250?Q?Dezider_G=F3ra?= <gora at wittmann.sk>
> Organization: I. Wittmann & Syn, spol. s r.o.
> To: nagios-users at lists.sourceforge.net
> Subject: [Nagios-users] win eventlog snmp monitoring (was: ev2T -> snmptrapd -> Nagios )
> 
> Hi all,
> 
> after 3 days battle I'm glad to report success on this :-)
> So here comes the story (if anyone's interested)...

> Needed stuff
> ev2T, http://www.ncomtech.com/download.htm
> net-snmp package http://www.net-snmp.org
> obviously nagios, libmcrypt, nsca
> Docs:
> http://nagios.sourceforge.net/docs/1_0/int-snmptrap.html

> 
> Install ev2T on windows machine, and configure it. There's one small bug 
> in ev2T, so read the info on download page.

> Configure it, set snmp server where to send traps, and set it to use 
> snmp v2c. It's usefull to set filter on eventsource, otherwise it will 
> raise trap everytime a new record appears in win eventlog. Also uncheck 
> unneeded fields in sent trap ( like event description, event type, etc. )

> Copy the mib file to mibs directory on target server and restart snmp.

> Configure snmp traphandle to catch the trap from win station. Well, this 
> was my biggest problem. I'm a total newbie in snmp, so it was a 
> trial-failure procedure.... The only way I got it to work, was to use 
> "number representation" of ::eventLogGeneralTrap OID.

(This sounds like the MIB files were not comprehensible to the Net-SNMP 
tools: \r in the MIB text, or perhaps wrong paths)

> So my snmptrapd.conf looks like this:
> traphandle .1.3.6.1.4.1.2854.6.1.2.1.0.1 
> /usr/local/nagios/libexec/eventhandlers/handle-eventlog-trap 2

> Then it comes an easy part. Create shell script that handles passed snmp 
> trap info and runs submit_check_results script as described at
> http://nagios.sourceforge.net/docs/1_0/int-snmptrap.html

 .. snip (valuable information about writing the trap handler)

> 
> This is how it works for me. I don't know why, but it works. I don't 
> understand snmp, mibs, so if anyone can improve this and "shed a little 
> light" for me, I'll be glad.
> 

I abandoned this approach after writing about 6 trap handlers when I 
realised that to handle 'just one more trap', I needed to write another.

Perhaps I could have written a class; probably should have (since so 
much of the processing is common to each handler), but the 
trap handler approach requires you maintain code - testing, design etc.

Nagios::TrapHandler anywone ?

The approach I use now is

1 install the MIBs corresponding to the trap - I usually put them in a 
~me/.snmp so all the issues with 'unlinked OIDs ...' can be sorted out 
without potential impact on any other applications. snmptranslate is 
_invaluable_ to ensure that the MIB can be understood by the Net-SNMP 
tools.

2 Install _no_ trap handler. Simply let the trap be logged (snmptrapd 
must be configured to use syslogd to log and put the traps somewhere).

3 Use a pattern matching log file analyser like swatch or logsurfer to 
  match each logged trap against patterns that represent events of 
  interest to you and react accordingly.

  You could also use an Event Correlator like Sec or RuleCore to
  interpret the temporal significance of the logged traps to, for
  example, filter matched pairs of events (down followd by up within
  some minimum period) that represent a transient you don't want to
  know about.
  
Whatever you use, the software should be able to generate a passive 
service check result and write it to the Nagiso commnad input file so 
that Nagios can be made aware of it.

What you end up with in the Sec case, is instead of a whole bunch of 
unrelated code for each handler, _one_ easily RCS managed configuration 
file.

Actually in this case, I probably would have replaced ev2trap with a 
product like Snare/BackLog that converts event log messages to syslog 
messages that can be harvested on a central syslog server (for all your 
Win boxes) and this can be one of the files processed by LogSurfer, Sec 
etc.

Whatever you do, the magic word is 'Event Correlation': a means of 
relating time sequenced messages from many sources into inferences about

 . business system health

 . automated actions required

 . escalation required

 . impact severity


> hope this helps.
> regards,
>     Dezider.
> 
> 
> 
> 

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: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list