Designing and Managing Behavior Models
-
Behavior Models and Their Components - Constructing Behavior Models - How the Pieces Fit Together -
Let's first review how you define which managed nodes a behavior model will monitor and manage. As Nodes, Property Groups, and Properties shows, each node belongs to a property group, and that property group contains properties.
Nodes, Property Groups, and Properties
Any set of nodes that share a unique property can be managed as a set of devices. (The nodes need not be members of the same property group.) In the figure above, the tcp property might be that unique property.
For a node to be pollable, the principal requirements are that:
Relationship Between Node and Poll shows the definition of a poll that has been designed to work with the node shown in Nodes, Property Groups, and Properties.
Relationship Between Node and Poll
As you can see, the node's property group, Mib-II, contains a property tcp that matches the poll's property and the base object used in the poll's poll condition. Once this poll is enabled, the poll TcpMedRetrans will poll the node, unless there is no alarm that the poll can affect or the node is suppressed. (If the node is suppressed, no polling will occur because the poll is marked suppressible.)
If TcpMedRetrans polls the node, receives a response to its query, and that response satisfies the poll condition, the poll will fire a trigger. If an alarm has been defined whose first transition is tcpRetransMed (the poll's trigger) and that alarm is enabled has the property tcp, a new instance of that alarm will be instantiated to monitor the node. Because the alarm is instantiated using the trigger's Node and Subobject, the key attributes of the trigger and alarm will match, and the first transition will be effected.
Once an alarm instance has been instantiated and has gone through one transition, the transitions that can be effected from its current state determine which triggers affect the alarm. For example consider the following alarm, TcpRetransMon.
When this alarm is first instantiated and the tcpRetransMed transition is made, the alarm transitions to the tcpMedRtrans state, so two transitions are pending: tcpRetransNorm and tcpRetransHigh. If NerveCenter sees a trigger with one of those names, and the trigger's Node and Subobject match those of the transition, the transition occurs.
This section presents an overview of the set of steps you would need to perform to create a behavior model that monitors node interfaces. The possible interface conditions are link up and link down.
The values you use to create LinkUp are shown in the table below.
Values Needed to Create LinkUp
Attribute | Value |
---|---|
The definition for LinkDown is the same as the definition of LinkUp except for the name of the mask and Generic SNMP trap number (LinkDown=2).
Once this alarm is enabled, the behavior model will become functional.
The IfLinkUpDown alarm contains the property ifEntry, which is in the property group CheckLink. Even though a trap mask filters all traps sent to NerveCenter, the IfLinkUpDown alarm will only become instantiated when the SNMP agent sending the trap belongs to a node in the CheckLink property group.
Here's how the behavior model might interact with one port on a workstation that belongs to the property group:
Constructing Behavior Models | NerveCenter Support for SNMP v3 |
29 July 2003 |