nv-l

RE: [nv-l] Activating Filters

2002-01-22 13:08:44
Subject: RE: [nv-l] Activating Filters
From: "James Shanks" <jshanks AT us.ibm DOT com>
To: "'nv-l'" <nv-l AT lists.tivoli DOT com>
Date: Tue, 22 Jan 2002 13:08:44 -0500

I must still be missing something here.  I still see no need for user programming.

The filter editor allows you to build as many simple filters as you want and then combine them into one big compound filter.
Applying the compound filter in your workspace would have the same effect as applying the many small ones.
So you could pre-build all your "Defcon1" - "Defcon10" as compound filters and then the operators could just pull down the Options --> Filter Control " menu and apply them. No scripts needed.  No user programming, except the filters themselves, which you build with the Filter Editor.  You can, of course, use your own program to build the filter(s) if you like, but even that is already provided.

But if you want total control, then you can use the documented APIs to write an alternative event viewer/logger.
You could write your own program to use nvSnmpTrapOpenFilter to apply the various Defcon filters and write out the events which pass them to its own log file, or display them in a separate window from nvevents, if that's what you would prefer.  There are people who have done this I am told.

But there is no way to mix them, no way to insert your own programming into  the flow of nvevents.  If you still think that your final objectives cannot be accomplished unless you can do that, then you will have to contact Support or your marketing rep and have them open an enhancement request.

HTH

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group




"Allison, Jason (JALLISON)" <JALLISON AT arinc DOT com>

01/22/2002 11:05 AM

       
        To:        "'nv-l'" <nv-l AT lists.tivoli DOT com>
        cc:        
        Subject:        RE: [nv-l] Activating Filters

       


"It is pointless to quote the manual to me.  I know what it says.  But you
may not understand what it means."
I agree, I have a different interpretation of what it says, which may be
incorrect.

As an operator, these are our discussed situations:

A.
- Change /usr/OV/app-defaults:  (this is so the operator does not need to
navigate to find a desired filter file).
nvevents.filterDir            : /usr/OV/filters/operational_filter_file
operational_filter_file only contains the filters I want the operator to
have the ability to activate

Operationally
- From the Main nvevents display 'Options -> Filter Control'
- Locate proper filter(s), highlight filter, 'Activate -> Close'

B.
Operationally
- 'My Menu Action' -> Activate -> 'Filter #1'

My point of this is not to simply discuss 'ease of use', an example:

1.  From B, remove 'Filter #1' and replace it with 'Defcon 1'.  War breaks
out and I want the nvevents main display to only display events associated
with 'Defcon 1'.  The operator does not need to have the knowledge of what
filters are currently activated, what filters should not be activated, or
what filters need to be activated as per 'Defcon 1'.  All the operator needs
to know is that if someone or something tells them to go into 'Defcon 1',
they pull-down and activate.  This application will, behind the scenes,
query what filters are in place, remove current filters (or all), and apply
any filter(s) that need to be in place.  It is possible that 'Defcon 1' has
10 different filters that need to be applied.  These 10 different filters
could be used in other Defcon scenarios, so we do not want to copy filters,
thus increasing ease of maintainability.  The upkeep of all defined filters
and filter file names will be greatly reduced.  Think about the written
procedures for entering 'Defcon 1'.  There would need to be a scripted step
by step instruction set of how to enter 'Defcon 1' with respect to which
filters should and should not be activated which would need to be updated
each time there was an addition or removal of a particular filter.  What I
am looking to do is automate that with embedded logic in an application.
The operator does not need to know (educated/trained) on this except the
fact that they know if they choose Defcon 1' they are only seeing the events
that they need to see.  From an applicability standpoint, my program insures
that the operator only sees the traps that they are supposed to see, and
that set of traps can be changed on the fly, behind the scenes, depending on
logic embedded in the application.  This application can have many other
features including, but not limited to, security, traceability and logging.

I hope this example explained my desires more clearly.  If my interpretation
of the Admin Guide is incorrect, then I will not be able to write an
application like the one discussed.  My goals are information hiding and to
ease the operational environment for our operators.  This also decreases the
likelihood of an operator making a mistake.  I still need to address a
solution to my problem.  Having the ability to write an application like I
have outlined would be best.  I do have some thoughts on other options, but
my interpretation of the Admin Guide led me to believe that I could address
my problem with this solution approach.

A side question:
I am creating a "Dynamic" workspace (NvEnvironment/Workspaces) that starts
on startup.  I noticed that I cannot activate a filter against this nvevents
display (i.e. No 'Filter Control' under Options).  Does this mean I cannot
add a filter to this Workspace?


Thanks again for your time,


Jason Allison
Principal Engineer

ARINC Incorporated
Office:  (410) 266-2006
FAX:  (410) 573-3026


-----Original Message-----
From: James Shanks [mailto:jshanks AT us.ibm DOT com]
Sent: Tuesday, January 22, 2002 9:19 AM
To: 'nv-l'
Subject: RE: [nv-l] Activating Filters



Jason -

It is pointless to quote the manual to me.  I know what it says.  But you
may not understand what it means.

I don't understand your situation.  You can already create a filter on the
fly and activate it using the Options pull-down in the Event window.
No additional programming needs to be done.   You pull down "Options->Filter
control"  If you don't like the filters that are shown, you click the "Start
Filter Editor" button and create a new one.  You then activate it, or as
many of the others as you like.  From then one, new events will be added to
he open workspace only if they pass the ruleset AND the filter(s).  That
seems to me to be what you said you want -- it's all under the user's
control.

Are you asking, "How can I get the events in the current open window sent
back through my filter, so that he currently open window shows only what now
passes the filter?"   Well technically you cannot, but you can get very much
the same thing by using the Create button to open a new dynamic workspace
with the same ruleset but applying the filter as you create it.  There's a
button to do that.  It's all point and click for the user, so again, it
seems to be what you said you want.

Where the manual talks about programmatically applying filters it means that
you can (1) use either the Workspaces method or the ".<userid>.events"
method to apply filters automatically, and (2) you can also write your own
application which can create and apply filters to the event stream it
receives.  But it does not mean that you can write an application which will
apply filters for the users in nvevents.  The nvevents menu is not
user-customizable the way ovw is.  

Note however that you can specify "Additional Actions"  to be performed on
selected events.  But you cannot force the users to select them, nor to
perform the actions.  They have to do it themselves.


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group





                "Allison, Jason (JALLISON)" <JALLISON AT arinc DOT com>


01/22/2002 08:47 AM


       
       To:        "'nv-l'" <nv-l AT lists.tivoli DOT com>
       cc:        "Allison, Jason (JALLISON)" <JALLISON AT arinc DOT com>
       Subject:        RE:  [nv-l] Activating Filters

     


"are you just looking for a way to have certain filters automatically
applied to the events display when users open it?"
Yes and no.

My situation
I would like to provide my operators with a TME10 GUI pulldown menu option
that will:

- Create a filter.
- Activate that filter against any currently open nvevents displays.
- ... Another pulldown that will deactivate the filter.

I am assuming this can be done since I can manually do this via
"Options->Filter Control, etc" under a single nvevents display.

For the record, I already have "nvevents.LoadEnvOnInit" set to true.  I
currently have 2 nvevent displays on startup.  I am looking to -apply- a
filter, on the fly, to an nvevent display as per the quote in the
Administratos guide:  "Filters can also be activated and deactivated
programmatically.  Refer to
the TME 10 Netview Programmers Guide for information about event filtering
API."

Thanks,

Jason Allison
Principal Engineer
ARINC Incorporated
Office:  (410) 266-2006
FAX:  (410) 573-3026


-----Original Message-----
From: James Shanks [mailto:jshanks AT us.ibm DOT com]
Sent: Friday, January 18, 2002 2:03 PM
To: NV-L AT tkg DOT com
Subject: Activating Filters



Since the reference in the Admin Guide directs you the Programmer's Guide,
and the Programmer's Guide (Chapter 17. Filtering Network Events) talks
about creating filters for use within an application you write yourself, I
think what is being referred to is the fact that once you have your filters
created, you can open a (new) session with trapd within your application to
use your own filters by invoking  nvSnmpTrapOpenFilter, which will then
deliver just those events matching your filter to your program.   Is this
what you wanted?

Or are you just looking for a way to have certain filters automatically
applied to the events display when users open it?
If this latter, then you can create your filters and specify them by name in
a special file called $HOME/.<userid>.events  (see "Customizing Event Filter
For Users" in the Admin Guide) or by creating a Workspaces file
($HOME/NvEnvironment/Workspaces) using the events GUI and the Save
Environment button under Options.   To have it read on startup you must
modify that user's Nvevents file (or the main one in /usr/OVapp-defaults) so
that nvevents.LoadEnvOnInit is set to True.   That's mentioned in the Admin
Guide too.  


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group


----- Forwarded by James Shanks/Raleigh/IBM on 01/18/2002 01:26 PM -----

               "Allison, Jason (JALLISON)" <JALLISON AT arinc DOT com>


01/18/2002 12:26 PM


     
      To:        nv-l AT tkg DOT com
      cc:        "Allison, Jason (JALLISON)" <JALLISON AT arinc DOT com>
      Subject:        Activating Filters

     


List:

I am trying to have a registered application dynamically activate and
deactivate filters.  I have been successful in generating the filters I so
desire using nvDefineFilter() (and using nvDeleteFilter() to remove them).
However, using those calls will only create the filter file, no
activation/deactivation occurs.  I can go in and manually
activate/deactivate them and all is good.

Administrators guide 5-55 "Activating and Deactivating Event Filters", the
last paragraph:
"Filters can also be activated and deactivated programmatically.  Refer to
the TME 10 Netview Programmers Guide for information about event filtering
API."

In the Programmers Reference I found only the nvFilter calls.  In nvFilter.h
there are no additional listings.  After some searching I found
"./man1/selectfilter" with is a utility for this, however I have been unable
to get it to work due to tralertd not running nor being able to be started.
I also looked at OVeRegister, but it does not seem to be in the same field
as nvFilterDefine.

Any and all input appreciated,

Jason Allison
Principal Engineer
ARINC Incorporated
Office:  (410) 266-2006
FAX:  (410) 573-3026




---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)






---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)



<Prev in Thread] Current Thread [Next in Thread>