To: | nv-l@lists.us.ibm.com |
---|---|
Subject: | RE: [nv-l] NV if_down trap source |
From: | James Shanks <jshanks@us.ibm.com> |
Date: | Fri, 4 Mar 2005 09:55:03 -0500 |
Delivery-date: | Fri, 04 Mar 2005 14:55:33 +0000 |
Envelope-to: | nv-l-archive@lists.skills-1st.co.uk |
In-reply-to: | <C353F42ACF29E240B9050B86F1852A4F0C270A@nlspm204.emea.corp.eds.com> |
Reply-to: | nv-l@lists.us.ibm.com |
Sender: | owner-nv-l@lists.us.ibm.com |
Sensitivity: |
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]
pic31051.gif
pic05627.gif
pic23010.gif
pic07419.gif
pic16212.gif
pic04086.gif
pic02749.gif
pic12767.gif
pic09084.gif |
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Previous by Date: | Re: [nv-l] host added by loadhost loaded into two different MLMs, alejandro . gabay |
---|---|
Next by Date: | [nv-l] C5d exited on signal 11 when I installed new Solaris MLM, Abadir Hany-O10544 |
Previous by Thread: | RE: [nv-l] NV if_down trap source, Liu, David |
Next by Thread: | RE: [nv-l] NV if_down trap source, Liu, David |
Indexes: | [Date] [Thread] [Top] [All Lists] |
Archive operated by Skills 1st Ltd
See also: The NetView Web