Suggestions for event correlation managers?

[Frost, Mark {PBC}]

Splunk perhaps?

Mark
________________________________________
From: Furnish, Trever G [TGFurnish at herffjones.com]
Sent: Tuesday, August 09, 2011 12:30 AM
To: Nagios Users List
Subject: Re: [Nagios-users] Suggestions for event correlation managers?

Anyone?  C'mon, don't be shy! :-)

--
Trever

________________________________________
From: Furnish, Trever G [TGFurnish at herffjones.com]
Sent: Friday, August 05, 2011 4:45 PM
To: nagios-users at lists.sourceforge.net
Cc: Boeglin, Adam R
Subject: [Nagios-users] Suggestions for event correlation managers?

Hello,

I'm looking for suggestions for applying Nagios' style of event handling (escalations, recoveries, acknowledgements), hopefully with some improvements (aggregation), to events coming from many different (non-Nagios) sources.  I know of a few Nagios-specific notification aggregators, but can anyone recommend a good (preferably inexpensive / OSS) way of expanding that to include many other tools?  I know about SNARE and RiverMuse, but they're relatively expensive.

We make heavy use of Nagios as well as several other tools (MSFT SCOM, HP SIM, Oracle Grid Control, AlertSite.net, etc).  They're all sending alerts in various forms to a small group of admins and engineers, so many of us get alerts from all of the tools, sometimes from more than one tool regarding a single event.

Nagios does a great job of flexibly managing alerts from its own events, but I don't see how I'd hook in the other tools.  Several of the tools (e.g. SCOM and SIM) don't even have any concept of event correlation -- breakage and recovery are two separate events.

I see tools like SNARE, RiverMuse ECM, and a few others filling this gap, at least partially, but I don't yet have experience with them and they're relatively expensive.  Anyone doing this effectively with OSS tools or low-cost tools or a good home-grown approach you wouldn't mind sharing (and possibly collaborating on)?

--
Trever Furnish, tgfurnish at herffjones.com
Herff Jones, Inc. Solutions Architect
Phone: 317.612.3519


------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
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

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at:  http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
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

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
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