I hate to be negative, but it does not surprise me that you have trouble
with this rule. I have published on this forum several times a list of
ruleset suggestions and high on them was NOT to implement a rule like this:
Event Stream ---> Query SmarSet ---> Forward
You are only asking for performance problems, some of which are likely to
be so severe that things don't work right at all.
A "Query SmarSet" means that nvcorrd will have to suspend his processing,
contact nvcold to resolve the smartset, and wait for an answer. nvcold in
turn will query ovwdb for an object database lookup, and he will wait for a
response. ovwdb will put the query in his queue, which could be full of
similar requests from other sources, such as netmon, and service it in
turn. So when ovwdb is busy your performance goes right down the tubes.
But events are still coming in, and every one of them is being held up by
nvcorrd while he forces them, one at a time, through this bottle neck.
Depending on how fast the events are coming in, your processing will fall
behind in a hurry. Why? Because the events stream is for all events, even
the ones you don't care about, even the ones which are log-only, and they
too must go through the process.
By adding an action to this you may be making things worse. It's not an
inline action is it? If so, then nvcorrd does the work himself, and this
further adds to the delay for the next event. If you use an Action, done
by actionsvr, you should be able to see what is happening by looking at his
logs. My guess is that you have many actionsvr processes active (each
execution spawns a new one) at one time trying to write to the same file.
You need to redesign this in my view and add some trap settings nodes or
other such node (Event Attributes) which works just on the trap itself and
doesn't require such intense processing to get the job done. Only then
will nvcorrd and nvserverd be able to keep up. And then I think your
problems will disappear.
If you insist that it has to be this way, then I suggest you contact
Support and start tracing what's going on.
Sorry but that's the best I can do.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Graeme Nelson <Graeme.Nelson@macquarie.com.au>@tkg.com on 02/05/2001
05:25:33 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc: "ISD Client Svr I'Structure" <opiscsi@macquarie.com.au>
Subject: [NV-L] Advise on a rule to check events being forwarded to T/EC
In V5.1.1 we had a rare problem where NV received a trap but appeared not
to be forwarded to T/EC. With V6.0.1 implemented we want to set the T/EC
forwarding rule to log all events being processed.
This introduced a delay of several minutes in processing events and some
events being lost all together. When the rule is removed there's a flood of
bankedup events.
The rule is:
Event Stream ---> Query SmartSet ---> Action ---> Forward
Check if events Echo event Forward to T/EC
from this node variables
should go to T/EC to a file
The production rule set is:
Event Stream ---> Query SmarSet ---> Forward
We're running NV 6.0.1, Solaris 2.6 and Framework 3.6.2. T/EC is on a
different TMR to NV. The rule is NOT defined in ESE.automation. I do
realise this rule will process all events not just the ones we want sent to
T/EC.
Is anyone else trying to log events before they're forwarded to T/EC?
Thanks
Graeme Nelson
Macquarie Bank Ltd
Sydney, Australia
|