|Subject:||Re: [nv-l] Automatic clearing events and map status changes|
|From:||James Shanks <email@example.com>|
|Date:||Thu, 15 Apr 2004 16:56:43 -0400|
|Delivery-date:||Thu, 15 Apr 2004 22:10:45 +0100|
The short answer to your questions is that you cannot duplicate the function you are used to in NetView without some considerable effort.
Either you will have to learn to do without it or you can implement something of your own, but even then, that may only approximate but not duplicate what you are used to. It is difficult to judge at this point. But the answer to both your questions involves using rulesets and customizing the event displays, not the trap log.
1. There is only one trapd.log. You control what is logged there by altering the log message in trapd.conf using the xnmtrap editor. But trap severity is not a field that is logged, unless you add it yourself in the log message. The trap severity is used rather to alter the color of the event in the user's event display(s), which is where users typically watch events, in the events window, which is a real-time, in-memory display and not a log. You can affect a user's displays by using rulesets. It would be easy to write a ruleset which would resolve an event, that is, remove it from the user's display, upon receipt of another. But you must familiarize your self with what is written about the ruleset editor in the Administrator's Guide and then play with it a little. You can start the editor outside of the GUI using the command /usr/OV/bin/nvrsEdit . Open the sampcorrNuNd.rs file for an example of how a resolve works. You'd need only change the Trap Settings to be the events you want, and the Pass-On-Match to indicate the matching attributes those have and the hold time.
2. You can use the 58916871 status trap but there are several caveats when doing so. First the event window must be open on a display having been started with the read-write map, or the update will not occur. This is because the API is in the event window GUI, a process called "nvevents", and it requires access to the read-write map to update the status. And these objects you affect the status on should be ones which you add to NetView yourself because, if netmon is also updating them, then whenever the GUI is recycled, the status that netmon has for the object, which is stored in the database will be used when the map is reopened. Updating the status of netmon-controlled objects is much more difficult. If that's what you want to do, then you had better take up that issue in a separate note.
The rest of what you say you want for this second case is rather murky to me because you are still using some terminology from your other system. But let me see whether I can clarify a few points. You can set whatever severity you want for a trap initially in trapd.conf. That's how it will display. And you may override that severity with a ruleset which changes that severity for the user viewing it . And your ruleset could further log that trap with it's new severity to a new log file of your own devising. But the trapd.log does not log event severities as a field in the log record. They are only used to alter the color of the event in the display. So your new log could record a severity, but the default one would not have it. I hope that it clear.
All this customization is just with NetView itself as a stand-alone product. If you have plans to use the Tivoli Event Console as a replacement for the NetView event display, then the correlation you describe can be achieved within the TEC display and TEC log using TEC rules, but it is beyond the scope of my reply to explain to you how to do that. The learning curve for customizing TEC is rather steep and user's typically go to class or get help from IBM Services to do anything out of the ordinary. You might want to ask your IBM marketing rep about the availability of classes on NetView and TEC in your area.
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
I have a Netview 7.1.3 running Solaris 8 on a SUN box.
As we are migrating from a different SNMP manager to Netview, we were accustomed to have a current log and a history log. Some events were configured to auto-clear others (this means to remove them from the current and send them straight to the history). Do you know how can we implement this in Tivoli?.
Also, we have and external application that should set some objects status in the Netview map. I am planning to use the Netview specific trap 58916871 to change the object color?. I would like to see the traps in the netview event history with a priority linked to them (per instance an "Up" event should be a clear event, an "User2" event should be a warning one). How can I change the trap severity depending on the trap content?.
Technical Center Supervisor, Argentina
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||RE: [nv-l] Solaris Bad PDU Type, Barr, Scott|
|Next by Date:||Recall: [nv-l] locations, John Sobrinho|
|Previous by Thread:||[nv-l] Automatic clearing events and map status changes, alejandro . gabay|
|Next by Thread:||Re: [nv-l] Automatic clearing events and map status changes, alejandro . gabay|
|Indexes:||[Date] [Thread] [Top] [All Lists]|
Archive operated by Skills 1st Ltd
See also: The NetView Web