vladimir, james,
1. as described: ovevents.log (max. only 2MB) and events-display (max only
1000).
the maximum values are not enough for our situation.
2. via xnmtraps i can only block out totally the specific traps.
i can't filter for example the server node-down traps (or only a list or
collection of ip-addresses)
3. this is exactly what i was trying to do (i even included the rule: see
below). unfortunately it doesn't work :-(
james, what do you mean by the expression "hand your events windows"?
we are using the rule block.rs as described below and we can't see a
difference to forwardall.rs.
4. please no dynamic filtering: ovevents.log is still clogged! the
important traps are still purged out! this is only a solution for the
display.
>To change the ruleset of the primary workspace you have to modify
/usr/OV/app-defaults/Nvevents
this is i was looking for - but the rule itself still doesn't work.
Mit freundlichen Gruessen - Yours sincerely
Giscard Fuchs
CompuNet Berlin
System Engineering
Mariendorfer Damm 1-3, 12099 Berlin, Germany
Phone: +49 30 70785-147, Fax: +49 30 70785-130, Mobile: 0172/8212409
Internet: giscard.fuchs @ gecits-eu.com
If you are going to use a ruleset for this, I have just one thing to add to
Vladimir's comments below.
No ruleset in ESE.Automation should ever have its initila event stream node
set to PASS. If you do that, you will hand your events windows
James Shanks
Tivoli (NetView for UNIX) L3 Support
Vladimir Petr <petr@DATASYS.CZ> on 10/28/98 07:38:38 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)
Subject: Re: how to block node-up/down traps?
Giscard,
There are a few ways how to do it depending upon what you prefer :
1. You can increase the ovevent.log size (assuming you did mean this log;
man ovelmd)
2. You can modify the traps that they be not logged, displayed or both via
xnmtrap
3. You can create a ruleset using Event Attributes or Trap Setting nodes,
e.g. Event Stream -> Trap Setting (Not equal to Specific 58916864) -> Trap
Setting (Not equal to 58916865) -> Forward)
4. You can use filters to prevent the events from being just displayed
However, I think you will not achieve your goal by using ESE.automation.
This file is read by actionsvr that executes
actions in rulesets (so use ESE.automation for performing actions). If you
enter a ruleset in this file, you have to
recycle actionsvr.
Also, ovactiond has nothing to do with rulesets; this daemon executes
automatic actions upon trapd's receiving an
event/trap (configured through xnmtrap and set in trapd.conf).
The ruleset name visible in the right-hand lower corner of the Event
Display is the name of the ruleset being active in
the current workspace. If you create a new workspace, you can choose a
ruleset that will then decide which events to
display. Your workspaces can be loaded automatically (if saved) after GUI
startup if you modify
/usr/OV/app-defaults/Nvevents file accordingly.
To change the ruleset of the primary workspace you have to modify
/usr/OV/app-defaults/Nvevents file as well.
You can read about workspaces etc. in Administrator's Guide. A valuable
article on rulesets has been posted by James
Shanks. It should be available in the archive.
Hope this helps,
Best regards,
Vladimir.
giscard.fuchs@GECITS-EU.COM wrote:
> how do i sort out node-up/down and link-up/down traps before they clog
> nvevents.log (max. only 2MB) and events-display (max only 1000)?
>
> we have 1500+ clients who switch on their systems every morning and
> power
> off in the evening.
> that makes approx. 6000 traps per day. i can't see the relevant traps
> any
> more.
>
> we built a rule block.rs:
> event-stream (pass) -> trap settings -> block events
> and put that rule in ESE.sutomatation and restartet ovactiond.
>
> but still i see in the event display (bottom right) that the rule
> forwardall.rs is in use and the traps are flooding my system.
> we are on aix 4.3.1, tmf 3.6, nv 5.1.
>
> block.rs:
> RuleSet3 RuleSet TrapID4 TrapID6 TrapID7 TrapID8
> "" 1
> TrapID4 TrapID BlockCorr5
> netView6000 1.3.6.1.4.1.2.6.3 "6 " "58916867 " 0 "netView6000
> 1.3.6.1.4.1.2.6.3" "IBM_NVIDWN_EV
> Specific 58916867 " "" 0
> BlockCorr5 BlockCorr
> ""
> TrapID6 TrapID BlockCorr5
> netView6000 1.3.6.1.4.1.2.6.3 "6 " "58916864 " 0 "netView6000
> 1.3.6.1.4.1.2.6.3" "IBM_NVNUP_EV
> Specific 58916864 " "" 0
> TrapID7 TrapID BlockCorr5
> netView6000 1.3.6.1.4.1.2.6.3 "6 " "58916865 " 0 "netView6000
> 1.3.6.1.4.1.2.6.3" "IBM_NVNDWN_EV
> Specific 58916865 " "" 0
> TrapID8 TrapID BlockCorr5
> netView6000 1.3.6.1.4.1.2.6.3 "6 " "58916866 " 0 "netView6000
> 1.3.6.1.4.1.2.6.3" "IBM_NVIUP_EV
> Specific 58916866 " "" 0
>
> Mit freundlichen Gruessen - Yours sincerely
>
> Giscard Fuchs
> CompuNet Berlin
> System Engineering
> Mariendorfer Damm 1-3, 12099 Berlin, Germany
> Phone: +49 30 70785-147, Fax: +49 30 70785-130, Mobile: 0172/8212409
> Internet: giscard.fuchs @ gecits-eu.com
--
Vladimir Petr
DATASYS
TEL +420-2-6138-8211
FAX +420-2-6138-8210
mailto:petr@datasys.cz
-----------------------------
|