Yes, we are running several rulesets in ESE.automation.
They all end with the action node except for two of them. These two end
with an action node and a check route. I'm not quite sure what the check
route is doing here. Could the 'check route' cause the events to fill
and hang the event subsystem?
Thanks.
Peter Chow
IBM / MNS
IBM Global Services
chowp@ca.ibm.com
Office: (905) 293-3006
James Shanks
<jshanks@us.ibm.c To: nv-l@lists.us.ibm.com
om> cc:
Sent by: Subject: Re: [nv-l] Re:
Rulesets
owner-nv-l@lists.
us.ibm.com
04/23/2004 12:52
PM
Please respond to
nv-l
netstat -a will show you all the sockets and the send and receive queues.
The queues should be zero or have very small numbers in them. Very large
numbers, into the thousands, indicates a problem. On your level of AIX the
"full" number is 32767.
Are you running rulesets in ESE.autromation?
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
Peter Chow <Peter.Chow@ca.ibm.com>
Sent by: owner-nv-l@lists.us.ibm.com
To
nv-l@lists.us.ib
04/23/2004 12:28 PM m.com
cc
Please respond to Subject
nv-l Re: [nv-l] Re:
Rulesets
Hi all. We are running netview 7.1.3 on AIX 4.3.3
A few times over the last several months, events would just stop appearing
on the event monitor for reasons unknown. To get Netview operating
properly again, we would recycle the application.
Would this be a symptom of the event socket being filled up and hanging the
event subsystem? How can we check if the event socket is being filled?
Thanks,
Peter Chow
IBM / TD Bank MNS
IBM Global Services
chowp@ca.ibm.com
Office: (905) 293-3006
James Shanks <jshanks@us.ibm.com>
Sent by: owner-nv-l@lists.us.ibm.com To:
john@cosmos.dcmds.co.in
cc:
04/22/2004 10:15 AM nv-l@lists.us.ibm.com
Please respond to nv-l Subject: [nv-l]
Re: Rulesets
Hello John,
I'm afraid you misunderstand the nature of the nv-l list and my role in it.
I am a volunteer there like all the other users, and IBM management permits
me to answer questions there so long as I respect their guidelines. I
cannot take user problems, nor receive problem data, nor provide
individualized assistance beyond answering questions. Everything else
requires that you must open a formal problem to IBM support for that. I
hope you understand.
If you do open a problem to Support, and the folks in your local area do
not know how to answer your questions, then they can escalate that problem
report (PMR) to NetView Support in the US, and if needed, then eventually
I will be involved. Otherwise you must confine your questions to the
public list. That's the only place I can answer them.
I will attempt to give you some broad guidelines but I cannot do much with
your individual rulesets, except to say that they look all right, but I
think they are incomplete. They should probably either end in a Foward or
an Action to be explicit about what you are doing. UNIX has an implied
"forward" action but this is very dangerous to rely on, especially for
rulesets in ESE.automation. I think the ones you have will eventually
cause you a problem in ESE.automation because they should end in some kind
of an action node, and not a "forward" operation, so please read on.
UNIX:
1. The secret to debugging rulesets on UNIX is to use the nvcorrd.trace.
You activate it by issuing the command "nvcdebug -d all" and then looking
in the nvcorrd.alog and blog for the results. You'll see the eyecatcher
"Received a trap" when a trap arrives and "Finished with the trap" when all
processing is done. Everything that happens in between is nvcorrd
processing that trap through your ruleset. Every 1000 lines nvcorrd
switches logs, from the alog to the blog and back again, to keep the log
from getting too big. You can turn tracing off again with the command
"nvcdebug -r". See the man pages about nvcorrd and nvcdebug.
2. Rulesets which run in ESE.automation should terminate in an action node
of some kind, either an Action node (a command or a script you write to be
executed outside of the event flow to be run by actionsvr), an in-line
action node (executed by nvcorrd - but be careful as when you script runs
in-line all events wait until it is done), or the pager node, which is a
special kind of action. The rulesets are said to run "in the background"
because they are independent of the GUI and what the operator sees. Note
that rulesets in ESE.automation should NEVER contain a Forward, Override,
or Resolve node, because these are for the GUI only, and if used in
ESE.automation, they will eventually cause the event subsystem to hang.
That's because they are run by the actionsvr daemon and he does not have a
display to display events, so unless you give him an action to run they
just fill up his socket and he will eventually hang. For the same reason
the Event Stream should always be set to Block.
3. Rulesets can also be run in the event windows. This is how they affect
what the operator sees. You simply open a new window using Create -->
Dynamic Workspace and you'll be given a panel to specify what ruleset you
want to use. Only rulesets run in this fashion will affect what you see in
the event window. They should end in Forward, Override, Block, or Resolve
nodes. You can also include actions and in-line actions here, but if you
do, those actions will run for every copy of the ruleset that is being
used. So if two operators use the same ruleset, and it contains an action,
that action will fire twice, once for each operator. Thus it is often a
good idea to separate rulesets by function, keeping those which affect the
display separate from those which perform actions like paging in the
background.
4. You can combine different rulesets into one only by using the editor
and editing one to contain the other. There is no import feature, if that
is what you are asking. Each original ruleset just becomes a branch of the
new one, but you must build that branch from scratch yourself. I hope this
is clear.
Windows:
Rulesets on Windows are implemented entirely differently. I
would stay away from them at least until you have a clear understanding of
how they work on UNIX.
1. There is no ruleset editor on Windows. You must modify them with
Wordpad. The changes should be kept simple and the you will have to create
new ones on UNIX and ftp them over to Windows if you do anything other than
what the samples do. Editing them is not simple nor easy. For this reason
alone most users shy away from rulesets on Windows.
2. Rulesets on Windows work entirely differently than on UNIX. Since trapd
on Windows stores all events in the ODBC database directly, there is no
event flow to the operator screen. The Event Browser reads only stored
events from the ODBC database. So the correlation daemon on Windows
(called nvcord, with only one "r" to differentiate it) works on copies of
events after they have been stored. When he correlates an event, he must
send a new copy of that event back to trapd to be stored so that the
operator can see it. This copy is slightly different than the original
because it has a correlation id placed in the first variable of the trap.
This is so that the Event Browser can pull up just the events correlated by
each ruleset from the database. And that is the primary purpose of ruleset
on Windows -- they are intended as custom Event Browser filters. They do
NOT have the same robust functionality that is available on UNIX.
Rulesets on Windows do not support Actions Nodes (there is no
actionsvr) nor the pager node (for the same reason). If you want to send a
page from a ruleset, then you must use a script or bat file launched from
an in-line action. In-line actions run by nvcord on Windows can take
longer than they do on UNIX and not hurt anything because nvcord does not
disrupt the flow of events to the ODBC database -- he is on the sidelines
of the event flow rather than part of it.
Rulesets on Windows also do not support SetState Nodes (no
executable to launch), nor Resolve nor Block (nvcord cannot remove events
that have already been stored in the ODBC database) nodes, and Override
nodes only partially because there is no way to change the severity of a
stored event.
Since the way rulesets on Windows work is to send near-duplicate
copies of the existing events to the ODBC database, the operator can see
both the original AND the near-duplicate event if he runs the Event Browser
with no filters and just sets it to "All Events" (which is the default).
This is another reason why most users do not use rulesets on Windows. The
near-duplicate events fill up their event database quicker and many users
do not like to see them, but they are a normal part of the process.
3. Rulesets on Windows are implemented only by specifying them in the
configuration of the Correlation Daemon, nvcord. You must pick them out of
the drop-down list in Serversetup (nvsetup.exe) and also select what
tracing options you want when you start the daemon. Changing rulesets or
tracing means that you must recycle the daemon. There is no other way.
My advice is to stay away from rulesets on Window altogether because of
their many limitations, but if you must have them, then you should try to
become familiar with them on UNIX first, because that implementation is
easier to use.
I sincerely hope this helps.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
john@cosmos.dcmds.co.in
Sent by:
SomenDas@cosmos.dcmds.co.in
To
James
04/22/2004 02:44 AM Shanks/Raleigh/IBM@IBMUS
cc
Subject
Rulesets
Hi Shanks
Thanks for your guidance for creating Rulesets.
I had created few rulesets as per your guidance.I have both AIX and Windows
platfom in which I had installed Netview-7.1.3
I had few more queries in this regard.who I will activate the rulesets in
Windows platform and how I will able to know the partcular rulesets output,
I had activated 6 rulesets in AIX by putting them in ESE.automation file,Is
there any method to taste the rulset individually,and where the output are
written.
Also I am attaching two rulesets created by me for your verification,pl.
let me know whether these are the right one or not
Is there any method to integrate all these 6 rulesets to one ruleset
The ndnu.rs for node down/node up events and iuid.rs for interface
down/interface up events
and the time period is 5 minutes
I will be greatfull to you if you please guide me
With Regards
John(See attached file: ndnu.rs)(See attached file: iuid.rs)
---------------------------------------------------------------------------
The information in this e-mail is the property of DCM DataSystems and may
be confidential and privileged. It is intended solely for the addressee and
access of this email by anyone else is unauthorised. If you are not the
intended receipient, any disclosure, copying, distribution or any action
taken in reliance of this message is prohibited and may be unlawful. If you
receive this message by error, please notify the sender immediately and
delete all copies of this message.
---------------------------------------------------------------------------
[attachment "ndnu.rs" deleted by James Shanks/Raleigh/IBM] [attachment
"iuid.rs" deleted by James Shanks/Raleigh/IBM]
|