They are being filtered - by nvcorrd. That's what the "Block" in the
ruleset does. What you are asking, I take it, is can they be pre-filtered
by some other process before they go to nvcorrd, and the answer is "No".
I could be wrong (not the first time) but I still think, however, that part
of the explanation is missing from your account. 80 traps a minute is only
a little over 1 per second, and I have not seen nvcorrd slow down as much
as you say under those conditions. I have never seen a performance problem
with just traps coming from netmon, unless the rulesets were doing things
which required external checking (MIB queries, checkroutes, database
queries and that sort of thing which requires nvcorrd to wait for some
external process to complete). Normally netmon cannot supply traps to
trapd (and on to nvcorrd) at a rate which will cause a slowdown. So
who/what else is sending traps and how often do they do it?
Event traffic is by nature "bursty" and NetView relies on this. A
sustained rate which never subsides will cause problems, as will a huge
burst, which doesn't get cleaned up before the next big burst arrives.
Are you looking for performance suggestions? The number one thing is the
same as I told Art, don't send what you don't need. One customer I know
did a study and found that on occasion they were getting over 100,000 traps
per day. When they calculated how much bandwidth they were losing, they
instituted a policy of restricting agent traps to just those someone in the
network center was actually going to use to solve a problem. Every one had
to have and action plan of the sort "when you get one of these, do this".
The result was that they reduced the amount of traps going to trapd by
something like 40 per cent.
But that may not be the only thing. If you think you have a genuine
performance issue, then call Support. They can look at what you are doing
and make suggestions. They can also involve the Tivoli Performance Group
as well, if detailed analysis is required.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Jan Green <greenjan@YAHOO.COM> on 05/19/99 12:42:32 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: traps being processed
James -
Thanks for the help.
trapd receives a trap, nvcorrd process it. nvcorrd can
process one trap per second. At Peak times, trapd is
receiving 80 traps per minute which puts nvcorrd 45
minutes behind and causes 2500 pages to be generated
on Sunday Morning due to an AT&T outage.
Of these 80 traps, 20 are Segment Down/Up/Marginal, 20
are Network Down/Up/Marginal, 20 are Node Up/Down and
20 are Interface Down/Up(the only ones I need).
I currently have 10 rulesets, all of which have the
"Purple Pizza" set to block. The next nodes are "Trap
Settings" which traps for specific traps(Interface
Down and Interface Up).
I wondered if there was a way to filter out the 60
traps I don't need so that NetView can spend it's time
processing the 20 traps I do?
Thanks
Jan
--- James Shanks <James_Shanks@TIVOLI.COM> wrote:
> Jan -
>
> I don't mean to be rude but the nature of your
> question indicates some
> fundamental misconception about rulesets.
> So if I seem to be pedantic, I apologize, but I
> don't understand (yet) what
> you don't understand.
>
> Anyway, here goes. All traps, regardless of origin,
> go to nvcorrd for
> processing. What he does with them depends upon
> what rulesets have
> registered with him. Every events workspace
> registers some ruleset or
> other, the default being forwardall.rs, and it --
> the workspace -- displays
> what the ruleset forwards. Now forwardall.rs has
> just two nodes in it: the
> event stream initial node (the " purple pizza") and
> a Forward. Since the
> event stream node is set to PASS, all incoming traps
> are passed on to the
> Forward node, and thus, all are displayed in the
> window, except those which
> have been set to "Log Only" or Don't Log or Display"
> in Event
> Configuration. The events window process, nvevents,
> reads trapd.conf, and
> suppresses traps which have been configured in this
> way.
>
> You can control what is sent to the events window by
> using a different
> ruleset than forwardall.rs To do that you use the
> ruleset editor and
> create a new one. You could, for example, start
> with an initial node set
> to PASS (to send all traps to the next node) and
> connect that to two trap
> settings nodes, one which picks out Network Marginal
> and one which picks
> out Segment Marginal, and have each of these
> followed by a Block. Also
> connect the initial node to a Forward. Then all
> events will be forwarded
> to the events window, but Network Marginal and
> Segment Marginal will have
> the "block" attribute set, and nvevents will not
> display them.
> Alternatively, you could configure those two traps
> to be 'Log Only" in
> Event Configuration and get the same result.
>
> If you have a ruleset which takes actions on
> specific traps, then you will
> want to set the initial node to BLOCK so that only
> those traps which are
> picked out in trap settings nodes or event attribute
> nodes and so on are
> considered. That is how you keep your ruleset from
> considering too much
> data.
>
> OK, now given this (meager) explanation, what did
> you mean when you said,
>
> >>I am only needing Interface Up/Down
> traps to be
> >>processed but, many other traps get
> processed along
> >>with them, which slows my system down.
>
> What does your ruleset do with Interface Up/Down
> traps and how do you know
> that your system is being slowed down?
>
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
>
>
_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com
|