To: | <nv-l@lists.us.ibm.com> |
---|---|
Subject: | RE: [nv-l] Ruleset Correlation |
From: | "Barr, Scott" <Scott_Barr@csgsystems.com> |
Date: | Fri, 28 May 2004 11:33:27 -0500 |
Delivery-date: | Fri, 28 May 2004 18:02:28 +0100 |
Envelope-to: | nv-l-archive@lists.skills-1st.co.uk |
Reply-to: | nv-l@lists.us.ibm.com |
Sender: | owner-nv-l@lists.us.ibm.com |
Thread-index: | AcREz+mTtKidWpWNQBa1INT3ZKBocgAAF3RQ |
Thread-topic: | [nv-l] Ruleset Correlation |
Stephen I use postemsg because I don't own TEC and that's
what the TEC integration person chose to use. Doesn't really matter too much to
me. We have LOTS of custom traps and supposedly that was a better choice. Can't
comment as I am not really TEC savvy.
As far as the timing issue goes... I Had observed problem
with single threading my listener calls, but after research I figured out how to
code the PERL script (listener) to handle up to N number of sockets (n currently
equals 100) The events do occur almost simultaneously, but the listener reflects
receiving 34, and also reflects generating the 34 up traps. So if it is a timing
issue, it doesn't show up through my logging. The PERL script does check for the
return code from postemsg, but since the notification script was only called 12
times, and all 12 were successful that doesn't really narrow it down very
much.
I am just still thinking that maybe there is a problem
trying to have 34 correlated up/down events simultaneously. Is there a
correlation "queue" for each ruleset or one global "queue" ? Is there a way to
dump/display whats in that queue?
|
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Previous by Date: | RE: [nv-l] Ruleset Correlation, Stephen Hochstetler |
---|---|
Next by Date: | RE: [nv-l] Ruleset Correlation, James Shanks |
Previous by Thread: | RE: [nv-l] Ruleset Correlation, James Shanks |
Next by Thread: | [nv-l] Juliet Grout is out of the office., Juliet Grout |
Indexes: | [Date] [Thread] [Top] [All Lists] |
Archive operated by Skills 1st Ltd
See also: The NetView Web