nv-l
[Top] [All Lists]

Status Color change

To: nv-l@lists.tivoli.com
Subject: Status Color change
From: Leslie Clark <lclark@US.IBM.COM>
Date: Mon, 8 Nov 1999 23:17:14 -0500
Deep, I haven't sent this around lately, so here's one from the archives.
It gives
a good explanation of the issues involved in manipulating the status of
objects
owned by Netview. I am trying to clarify the issue, which is that you are
not actually
expected to set your own status on things that belong to ipmap. That's why
you are getting all of these alternative suggestions instead of the
straight
answer you are asking for.  I hope this helps.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager

>From the Support Center....
 ------------------------------------------------------------------

 One of the most common, and yet most complicated, things that NetView

 users ask about is how to alter the status (color) of an icon on the

 map using a trap, effectively overriding what netmon has done.  This

 can be accomplished in one of three ways, (1) using a ruleset with the

 override node in it, (2) issuing the 58916871 NetView trap, or (3) by

 configuring a non-NetView trap.

 This document is an attempt to explain how these processes work.

 Types of status

 There are three (3) sources of status for objects on a NetView map:

 1.  Object source -- status of a single object is kept in the

  database entry for that object

 2.  Compound Propagated source -- object has no status of its own, but

       it is derived from status of its constituent objects.

        Network symbols and collection objects have status source of

        'Compound Propagated'

 3.  Symbol source -- an ipmap status not part of the object host nodes

         in the map have this status source

 You can determine the status source for any map object by selecting

 it with the rightmost mouse button and clicking on Edit ==> Modify /

 Describe ==> Symbol.

 General requirements

 1. In order for an event, no matter how it is processed, to override

 status and change the color of an object on the map(s), the Event

 process (called nvevents) must be running in dynamic workspace in a

 control desk on the read-write map, and the control desk must have

 been started by ovw (the map process) initially.  This is the default

 NetView End User Interface configuration.

 The reason for this is that the APIs for the status override function

 are in nvevents and ovw, and they can only be used effectively when

 both are connected to the same read-write map.

 2. The API can easily override the status of objects which have a

  status source of 'Object' or 'Symbol', but a status source of

 'Compound Propagated' is more difficult.  Since this is a derived

 status it cannot be changed directly.  What nvevents can do in this

 case, is to change the status source of the object to 'Symbol' first,

 and then override it.  But as this means that from that time on, the

 map object will no longer reflect the combined status of the objects

 "below" it (unless you later change the status source back to

 'Compound Propagated again via Edit with the right mouse button) you

 must set the application defaults for nvevents to permit this to

 happen.  You must edit app-defaults/Nvevents to say

   nvevents.overrideCompoundStatus : True

 When your event requests a status override, the object's status source

 will be changed from compound to symbol, and then overridden.  But now

 you must take responsibility to change the status again when the

 condition which caused you to change it in the first place has passed,

 as it will never again reflect the status derived from its components.

 Failure to have  nvevents.overrideCompoundStatus : True set in your

 Nvevents file is the most common reason why users report that overrides

 do not work.  Be aware that each user could have his or her own

 copy of Nvevents in his or her $HOME directory or could have

 incorporated the Nvevents entries into a .Xdefaults file.  And be aware

 that X is not forgiving about user defaults.  The value here must be

 "True" and not "True " with any extra spaces trailing the 'e'.

 Note that if a host node is in a Collection, it has status source of

 'Compound Propagated', while on the IP Segment map it will have a

 status source of 'Symbol'.   If you do not have

   nvevents.overrideCompoundStatus : True

 set in the Nvevents app-defaults, then the status you set will not be

 reflected in the Collection.  This is another common problem which

 users report.

 Note that the host node on a Segment map typically has status source

 of 'Symbol'.  It is set when netmon issues a Node Up/Node Down trap.

 Note that interfaces have a status source of 'Object'.  Their status

 is set when netmon issues an Interface Up/Interface Down trap. At

 higher levels, networks and segments have a status source of 'Compound

 Propagated', so both the host node AND its "down" interfaces must

 have their status set to User1 or User2 to avoid having them alter the

 status of the network.  Failure to set both of them is another common

 user problem.

 3. Condsider how you will change the status back again.  If you are

 changing status of nodes and interfaces that netmon pings, remember

 that it will change them back again, so you might delay the netmon

 polling cycle for them.  If you are overriding the status source of an

 object that was 'Compound Propagated' and are changing it to 'Symbol',

 you must find a way to change the status again with so other "cleared

 condition" event, since it will not change on its own now.

 Override status with ruleset

 In order for a ruleset to override status and change the color of an

 object on the map(s), the ruleset must be running in dynamic workspace

 in a control desk on the read-write map.  This is general requirement

 #1.


 And for the ruleset to override the status of an object which has a

 status source of 'Compound Propagated', you must edit

 app-defaults/Nvevents to say

   nvevents.overrideCompoundStatus : True

 This is general requirement #2.

 But ruleset override will only override the status of the host node,

 the "origin" of the trap, and not the interface (unless the interface

 does not have a hostname associated with it in the NetView database).

 This can be inconvenient, especially if what you want to do is

 override the status of both the host node and the interface (to

 something like User1 or User2) so that they do not figure in status

 propagation to higher-level nodes.

 Note that the host node on a Segment map typically has status source

 of 'Symbol'.  It is set when netmon issues a Node Up/Node Down trap.

 Note that interfaces have a status source of 'Object'.  Their status

 is set when netmon issues an Interface Up/Interface Down trap. At

 higher levels, networks and segments have a status source of 'Compound

 Propa- gated', so both the host node AND its "down" interfaces must

 have their status set to User1 or User2 to avoid having them alter the

 status of the network.

 So NetView also provides another way that status can be overridden.

 Override status using the 58916871 trap.

 If you look at the description of this trap in Event Configuration,

 you will see that this trap is not issued by netmon but is in fact

 designed for customer use to change status (and therefore color) on a

 map.  It doesn't affect true status in the object database.  Below is

 a shell script which will issue this trap via the snmptrap command.

 You pass it two variables -- (1) the name of the object from object

 database, and (2) the status you want this changed to on the map(s).

 Here's the script:

 #!/bin/ksh

 set -x

 NAME=$1

 STATE=$2

 /usr/OV/bin/snmptrap `hostname` .1.3.6.1.4.1.2.6.3.1 \

 `hostname` 6 58916871 1 \

 .1.3.6.1.4.1.2.6.3.1.1.2.0 Integer 14 \

 .1.3.6.1.4.1.2.6.3.1.1.3.0 OctetString $NAME \

 .1.3.6.1.4.1.2.6.3.1.1.4.0 OctetString "Object status is" \

 .1.3.6.1.4.1.2.6.3.1.1.5.0 OctetString $STATE

 Obviously you can make this script more elaborate if you like.

 The permissable status values are Unknown, Normal, Marginal, Critical,

 Up, Down, User1, and User2.

 You can obtain the name of the object by highlighting the icon on the

 map and clicking with the RIGHT mouse button to get to Edit ==>

 Modify/Describe ==> Object and the name is in the Set Selection Name

 Typically, a host is known by its hostname and an interface by

 hostname:interfacename, where the interface name is the IFdescription

 from the MIB (such as "nv6ktst5.raleigh.ibm.com:tr0" for example).

 You can always verify you have a correct object name by doing

 ovobjprint -s <name>.  If the object is not found, then you have a bad

 name.

 Since this is being done using the nvevents API to ovw, the same

 restrictions apply. The snmptrap must be received by some NetView with

 nvevents running in a control desk attached to an ovw running the

 read-write map.  This is general requirement #1.

 And the Nvevents app-defaults file must have the same value set:

 nvevents.overrideCompoundStatus : True if what you are setting has a

 status source of Compound Propagated.  This is general requirement #2.

 Override with a trap setting

 As in all other cases, general requirements #1 and #2 apply here as

 well.

 In addition, you cannot alter the status set by netmon traps, so you

 have to use a trap from another agent.  Here you can also use snmptrap

 to create your own traps and issue those by script or automatic action

 from Event Configuration.


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

Archive operated by Skills 1st Ltd

See also: The NetView Web