Leslie -
Thank you very much for the information you sent. I appreciate it.
Bob Twomey
Leslie Clark wrote:
> This sort of trap managment is frequently requested, but always turns out
> to be more complicated than you thought it was going to be. Here are some
> of my thoughts on the subject, and this applies to traps from all devices, not
> just Stratus.
>
> First, distinguish between the mib and events. The mib is usually just
> provided to describe questions that the agent in the device can answer,
> translated from dotted decimal to dotted words. It helps you use the
> mib browser, data collection, and the mib application builder. Then there
> are the events, or traps, that it can forward to an snmp manager such as
> netview, the things you want to react to graphically. If they did not come
> pre-defined in Netview, you have to define them. It is possible that
> Comtek provides a script to issue addtrap commands to define (and
> format) those traps in the trapd.conf file. It is also possible that they
> deliver
> those traps in a pseudo-mib file, using a mib-like grammer that sort of
> describes the traps, instead of mib variables. That sort of mib can be
> processed with the mib2trap command instead of using the EUI or the
> addtrap command. Usually they are just defined in a manual somewhere
> (if you are lucky) and you enter them using the EUI (Options..Event..)
>
> Now. You have some events that Stratus machines will send to Netview.
> Probably they include the generics, cold start, warm start, etc. Then there
> are some vendor-specific ones. Like, I don't know, "I'm Sad" and "I'm Happy"
> and you want to make operators aware of this status. There are a couple
> of ways to do this, some harder than others.
>
> You can add an object to the node submap, along side the interface cards,
> for "Happiness". Give it a status source of Object. Then you either customize
> the trap, or define a ruleset to manage that status of that object. The
> simplest
> way to do this is with the Status trap. You issue the trap for the object and
> it sets
> the status. The trap is 58916871.
>
> /usr/OV/bin/snmptrap \
> $HOSTNAME .1.3.6.1.4.1.2.6.3.1 \
> $HOSTNAME 6 58916871 1 \
> .1.2.6.1.4.1.2.6.3.1.1.2.0 Integer 14 \
> .1.2.6.1.4.1.2.6.3.1.1.2.0 OctetString $SELECTION_NAME \
> .1.2.6.1.4.1.2.6.3.1.1.2.0 OctetString "Object status is" \
> .1.2.6.1.4.1.2.6.3.1.1.2.0 OctetString $STATUS
>
> where $HOSTNAME is the sender, $SELECTION_NAME is whose status to change
> and $STATUS is Up, Down, etc. (I don't recommend using this on things
> Netview
> is already managing.)
>
> This is the sort of thing that the APM does, using MLM, to set status based on
> mib variables, as opposed to incoming traps. Now, when you go to do this sort
> of management, you run into issues of how to unset the things, and what the
> status
> is when the map first starts up, etc. Because you are basically dealing with
> MAP
> objects.
>
> I think I have a better idea, and I'm going to try it out on the next few
> cutomers
> I work with who want quick&dirty solutions. I think the answer is Collections,
> and
> the Ruleset editor, and the field query/set capability in V5. I'll define a
> Collection
> where "isHappy" = FALSE. When the "I'm Sad" event comes in for a node, I'll
> set
> that field to False for that node using the Ruleset. Collections will
> automatically put
> that node in the Collection. When the correspnding "I'm Happy" event comes in,
> the Ruleset will set the field back to True. It will automatically be removed
> from the
> collection.
>
> The baby-step approach would be to have one field, one collection, and never
> do anything automatically to take nodes out of the collection. If it's in that
> collection,
> you are supposed to go in there and check on it (like Monitor..Events..Current
> Events
> to see what has come in for this device). Then I would have a little app that
> issues
> an snmptrap that the ruleset would process to change that field and get the
> node
> out of the collection. The more advanced configuration would require a
> collection
> for every variable that you are thresholding, and the rearm trap would take it
> out.
> For unsolicited traps, such as those sent by Stratus, you would want to be
> sure
> to
> pair up the bad/good events so you could automatically reset the field.
>
> Most of my customers don't have a staff of crack C programmers available for
> Netview customization. I'm hoping these functions are simple enough for most
> of them to use. I believe in the 80/20 rule: 80% of what you want for 20% of
> the
> effort is a good deal. Maybe some customers out there are already using this
> method
> and can tell us if there are any pitfalls. Because I know... it is always
> more
> complicated
> than you think it is going to be!
>
> Cordially,
>
> Leslie Clark
> IBM Global Services - Network & Systems Management - Detroit
>
> - - - - - - - - - - - Original Note - - - - - - -- - - - - -
> Is there anyone who has a Stratus machine that they have sending alerts
> to NetView? Comtek provides a Stratus MIB for NetView that supports a
> very limited set of events. What we are trying to do is have every
> Stratus process (currently 200+), report to NetView. If a process
> abends, we would like an alert sent to the NetView log, and the
> corresponding icon representing that specific process will turn red. I
> am having a tough time finding anyone who has done this, or a consultant
> who has the skill set to make this happen. I spent 3 months going
> rounds with IBM and they had no one in their organization who was
> available to do this.
>
> Thank you in advance.
|
