The longer you make the hold time in the ruleset the more you will increase the
memory requirements for nvcorrd, since the cache will grow with every held event
and not flush until the time limit expires. In addition you will gradually
increase the processing time (and cpu used) for nvcorrd since he will have to
check an ever-increasing, and seldom decreasing, cache for expired events. He
does that every 15 seconds. But it will work if your system can stand it.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Leslie Clark <lclark@US.IBM.COM> on 01/18/2000 02:18:46 AM
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: Sending Interface Down & Interface up pages and correlation
I think I understand what Patrick is looking for, since I have just
started to
look at the same question. If a down event comes in, and no up event
within
the specified time, you want to send a page (for instance). That is the
part
everyone seems to agree on.
A little later, the up event does come in, and you want to send the
all-clear page.
But only if the down page was sent in the first place. It seems like it
ought to
work, but I worry about the long caching. What do you think about that,
James?
This is how I understand Steve's suggestion:
Node down is input 1 for reset-on-match (5 min)
Node up is input 2 for same.
Outputs of the reset-on-match go to:
1) Send the down page
2) and also input 1 for a pass-on-match (long time)
The same Node up is also input 2 for the pass on match
Output for the pass-on-match is send the up page. The trap
info available would be from the down event, not the up event,
but you would know that and could act accordingly.
Patrick, I vote that you verify this for us. Steve, is this something that
you are
actually running?
By the way, my current customer tells me that there are real dollars to be
saved by preventing unneccessary pages...
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
---------------------- Forwarded by Leslie Clark/Southfield/IBM on
01/18/2000 01:40 AM ---------------------------
James Shanks <James_Shanks@TIVOLI.COM>@UCSBVM.UCSB.EDU> on 01/17/2000
08:40:00 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
Sent by: Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc:
Subject: Re: Sending Interface Down & Interface up pages and correlation
Patrick -
I am not certain that I understand what your second case is for, and Steve
Francis has given you a suggestion which may work, in any case, but I
thought I
would comment on your questions.
You guessed correctly about how the Reset-on-Match and Pass-on-Match
functions
work with incoming events. I tried to clarify that in my second append
last
week. Only events of the type connected to Slot 1 are held in cache.
The
Slot 2 event is used to evaluate the events in the cache as soon as it is
received. The Slot 2 events are not cached at all, and once used, they
are
discarded unless you added additional processing for them, which is why
your
ruleset doesn't handle your second case. If no matches are received during
the
time interval, the cache is flushed, and the appropriate action taken for
the
Slot 1 event -- for Reset, it is passed along to the next ruleset node, for
Pass, it is dropped.
James Shanks
Tivoli (NetView for UNIX) L3 Support
|