James,
I did some readings and testing last two days. It's working now. Thank you
very much for your help.
Regards,
David
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of James Shanks
Sent: Friday, March 04, 2005 3:55 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] NV if_down trap source
David,
I recommend that you do some serious reading in the NetView documentation.
There's an entire chapter on events in Administrator's Guide which covers
filters, rulesets, and the formatting events.
1) How can I make it permanent (filter and ruleset) for the default event
window (the first one open)?
1. There are several ways this can be accomplished.
A. For filters, you can make filter permanent, by userid, by using a user
events filter file. That is the older method and is mentioned in the
NetView Administrator's Guide. In the user's home directory, you create a
file called ".<userid>.events". Don't omit the initial dot in the name.
In it you put the full path to the filter file and the name of the filter,
as in "/usr/OV/filter/filter.samples <myfilter>". When nvevents starts
up, it will find this file and automatically apply the specified filters if
that was the user who started him.
B. For rulesets, you change the Nvevents X resources file. You can edit
the one in /usr/OV/app-defaults, which affects everyone, or move it to the
user's $HOME directory. The latter method is preferred, of course, for
migration purposes. In that file you'll find an entry which specifies the
default ruleset to be used:
nvevents. correlationRule : forwardall.rs
You can specify whatever ruleset you have in /usr/OV/conf/rulesets.
Whenever you change the app-defaults file(s), I would recommend that you do
"xrdb -merge <full-path-to-the-app-defaults-file>". This forces X to
incorporate your changes immediately. On Solaris this command may not be
in your default path as they typically don't put the X11 libraries in the
default path, so you may have to hunt for it.
C. A third method is to create an nvevents Workspaces file. This allows
very precise control over the environment and is what you would do if you
wanted to have multiple windows with different rulesets and filters started
automatically. Modify the Nvevents app-defaults file, or your local copy
to say
nvevents.loadEnvOnInit : True
Once you've done that and merged it, when you start nvevents you'll get a
pop-up window saying the environment file was missing and you should create
one. OK that message. When nvevents settles down, you can apply what
filters you want or open whatever additional workspaces you want. Then on
the main panel, pull down Options, and select "Save Environment". This
creates a file $HOME/NvEnvironment/Workspaces containing information about
what was active at the time. Then when you exit and restart, nvevents will
find this file and automatically open all the correct windows, with the
correct rulesets, and apply the same filters.
2) Can I assume that when I use either of them, the event will also be
blocked to the TEC since we have the TEC integration?
2. No. TEC forwarding is independent of the event window. Event windows
belong to GUI users, not to the TEC adapter. What you seeing going to TEC
has NOTHING TO DO WITH the ruleset running in your event window. The TEC
ruleset is specified in the /usr/OV/conf/tecint.conf file, and if you want
to block events that are currently going to TEC, then you must modify that
ruleset or create a new one.
3) What if I have more traps (e.g. 5 tarps) with more sources (100 hosts)
to block?
3. There is no magic bullet here. Either you need to create more filters,
a more complicated filter, or a different ruleset. This is user
programming and like all programming exercises, you have to do the design
yourself and maintain it. In the case of a ruleset this complicated, I
would write a script to execute as an in-line action which grep'd a file
for a list of traps and hosts to be blocked. Then you could just add or
subtract to the file as you wished. But be careful. An in-line action
could slow all event processing because events are held up while nvcorrd
executes it, so make sure it is the sort of thing which completes in a
couple of seconds or less.
BTW, I have NV 7.1.2 on Solaris.
By the way, NetView 7.1.2 is out of support. You can still Call IBM
Support about issues you may have with it, but anything requiring a code
change will mean that you must migrate to 7.1.3 or 7.1.4. Obviously,
7.1.4 is the better choice.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Liu, David"
<david.liu@eds.co
m> To
Sent by: "'nv-l@lists.us.ibm.com'"
owner-nv-l@lists. <nv-l@lists.us.ibm.com>
us.ibm.com cc
Subject
03/03/2005 08:14 RE: [nv-l] NV if_down trap source
AM
Please respond to
nv-l
James (and list),
I'm back from testing with success, thank you very much. I prefer the
ruleset one since it has more power and flexibility. Unfortunately, more
questions coming when I know more.
1) How can I make it permanent (filter and ruleset) for the default event
window (the first one open)?
2) Can I assume that when I use either of them, the event will also be
blocked to the TEC since we have the TEC integration?
3) What if I have more traps (e.g. 5 tarps) with more sources (100 hosts)
to block?
BTW, I have NV 7.1.2 on Solaris.
Waiting for your advice.
Regards,
David
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com
[mailto:owner-nv-l@lists.us.ibm.com]On Behalf Of James Shanks
Sent: Wednesday, March 02, 2005 3:19 PM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] NV if_down trap source
What you are doing has nothing to do with excluding traps from the
event window, nothing at all.
The source box in the event configuration panels is there so that you
can format the same trap from different sources in a different way.
First you make a copy of the Interface Down trap, giving it a new
name. Then you add your sources, and finally, you change the
formatting or the command for automatic action. But none of that will
force an event off the screen. It just allows a different display
when it comes in.
To exclude traps from the event windows screen you must either use a
filter or a ruleset to do the job.
To build a filter, pull down Options --> Filter Control and then
click the button to start the filter editor. You are going to do an
Add Simple (filter) so click that button. Now a filter is for
filtering in (not out) what you want to see. So you would click the
radio button for "Events Not Equal To Selected" and then pick out
Interface Down from the list. Click Add/Modify to get the list
selection box and pick out Interface Down. Then go on the second part
and identify the hosts to be excluded ("From Objects not Equal to
List"). Once you've identified the hosts and the trap you want to
exclude, give the filter a name and a short description and save it
by clicking OK. When you exit the editor and go back to the filter
control window, then you will see your new filter in the list of
those which can be activated. Select it and activate it. From that
point on you will not see the trap in the event window. Every time
you restart the window you will have to re-apply the filter, unless
you make some more elaborate changes to the way nvevents works. All
this is covered in elaborate detail in the NetView for UNIX
Administrator's guide, but if you get your filter working and you
then want to apply it automatically, ask again and we'll go over that
part. Right now you should just be testing the filter. If you bring
up an other events but don't apply the filter you should be able to
see the difference when the Interface Down traps from the excluded
hosts come in.
Building a ruleset is considerably more complicated.
To build a ruleset, you use the ruleset editor, nvrsEdit. If you
bring that up, you get two windows, a box of multiple icons called
templates and a workspace window which allows you to build and edit
rulesets. On the workspace panel, do File --> Open and you'll see a
sample called sampcorrIuId.rs.
Open that one and edit it. Pull down Edit --> Delete Node and your
cursor will tun into a little hammer. Use it to smash the Resolve
node icon, the Pass-on-Match node icon, and the bottom Trap Settings
node icon, which is the one for Interface Up. (You can see that if
you double-click on it). You should be left with just the Event
Stream icon (which looks like a purple pizza) with an arrow pointing
to a Trap Settings node icon, which if you double click it, will
bring up a panel and show you what trap is selected. It should be
Interface Down. If it is not, then make it so.
Next you'll be adding two Event Attributes node icons. Find that on
from the Templates display. Drag and drop it down onto the ruleset.
It will open a panel which will allow you to specify what attribute
you want. Select 2, which is the hostname in the Interface Down Trap,
and then make the comparison be Equal To, and finally fill in the
value of one of the hostnames you want to exclude. OK your way out.
Now repeat that process. Drag down another Event Attributes block,
and make it equal to the other hostname you want to exclude. Now you
have to connect those two Event Attribute nodes to the Trap Settings
node.
Use the Edit --> Connect two nodes function for this. Pull down Edit
-> Connect two nodes and your cursor will change to a semaphore
signal with the left side highlighted. Position it over the Traps
Settings node and left click. The cursor semaphore will now highlight
the right side. Position it over either one of the Event Attributes
node and left click. The cursor will revert to normal and there will
now be an arrow from the Trap Settings node to that Event Attributes
node. Repeat that process with the other Event Attributes node. You
should end up with two arrows going from the Trap settings node, one
to each of the Event Attribute nodes. At this point is will be
helpful to pull down Edit --> Refresh Layout , which will clean up
the picture and make it easier to see.
Next you'll be adding a Block event node icon from the Templates
display. Drag and drop it down onto the ruleset. It will open a panel
which will allow you to append a comment if you like. Do that or just
click OK, so that you now have it on the workspace panel with the
other icons. The editor will automatically connect it to the last
Event Attributes icon. That's fine; it's just one less thing you have
to do. Pull down Edit -> Connect two nodes, and this time connect the
other Event Attributes box to the very same Block event node.
At this point you are finished editing and should save your ruleset.
Pull down File--> Save As, and give your ruleset a new name of your
own choosing. Don't change the path. Leave it in the
/usr/OV/conf/rulesets directory. Then exit the editor.
To activate you ruleset, bring up the events window. Once
initialized, pull down Create --> Dynamic Workspace and on the
resulting panel click the Rules List box and select the ruleset you
just created. You can give this new workspace a title if you like (it
defaults to Dynamic Filtered Workspace 1) or just hit the OK button
in the lower left and get it created. Now you have two event
workspaces, one running the default ruleset forwardall.rs, the other
running your ruleset. This allows you to test yours. When the
Interface Down traps from the hosts to be excluded come in, they will
be shown on the original workspace, the one running forwardall.rs,
but not on yours.
Once your ruleset has been tested, then you can decide whether you
want to make it permanent or not, and for you or everyone. When you
are ready to decide that step, you can ask on the list again.
So there you have it. That's how to use filters or rulesets to
control the event display in NetView for Windows.
Take your pick.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
(Embedded image moved to file: pic31051.gif)Inactive hide details for
"Liu, David" <david.liu@eds.com>"Liu, David" <david.liu@eds.com>
"Liu, David"
<david.liu@e
ds.com>
Sent by: (Embedded image moved to file:
owner-nv-l@l pic05627.gif)
ists.us.ibm. To
com (Embedded image moved to
file: pic23010.gif)
"'nv-l@lists.us.ibm.com'"
03/02/2005 <nv-l@lists.us.ibm.com>
07:33 AM (Embedded image moved to file:
pic07419.gif)
cc
Please respond to (Embedded image moved to
nv-l file: pic16212.gif)
(Embedded image moved to file:
pic04086.gif)
Subject
(Embedded image moved to
file: pic02749.gif)
[nv-l] NV if_down trap
source
(Embedded image moved to file:
pic12767.gif)
(Embedded image moved to
file: pic09084.gif)
Dear list,
I have experienced following problem hope to get your advices.
For the Netview6000 traps I need to exclude some source hosts from
the interface down trap. I choose from GUI the Options... Event
configuration: trap configuration... SNMP the find the specific trap
(internal number 58916867). I selected modify and in the source field
add all hosts except two which I want to exclude. But after that this
trap for these two hosts still appear on the event window. Does
anyone has the similar experience before? Thank you in advance.
Regards,
David[attachment "graycol.gif" deleted by James Shanks/Raleigh/IBM]
[attachment "ecblank.gif" deleted by James Shanks/Raleigh/IBM]
|