| Solstice Enterprise Manager 4.1 Customizing Guide |
|
Nerve Center Overview
Solstice Enterprise Manager (Solstice EM) provides the MIS support and applications that enable you to detect conditions in a network and take action in response. Collectively, the MIS functionality and related tools are referred to as Solstice EM's Nerve Center.
This chapter describes the following topics:
- Section 14.1 Nerve Center Components
- Section 14.2 Nerve Center Documentation
- Section 14.3 Nerve Center Operation
14.1 Nerve Center Components
The Nerve Center is comprised of the following parts:
- Request facilities in the Solstice EM MIS that handle the sending and receiving of requests and generate request-driven polling.
- Request Condition Language (RCL)--A script language that allows you to express what you want to do to monitor and perform threshold-checking in your network. You use this language in the Design Advanced Requests to build sets of instructions called "conditions." Conditions are the building blocks of request templates.
- A set of applications that allows you to create, save, and debug request templates, and launch and monitor requests. This includes:
- The Design Advanced Requests, which allows you to create request templates that are the basis of requests.
- The Requests tool, which allows you to launch requests against specific network elements. Requests tool also lists running requests and allows you to stop or examine them.
- Facilities in the Design Advanced Requests (and via the em_ncimport and em_ncexport command-line utilities) that allow you to export request templates and their components to ASCII file for easy replication of request components from one MIS to another.
- The em_debug utility, which provides facilities for debugging of request templates.
- A Nerve Center Interface Library that provides programmers the means to write applications to create, launch, and retrieve information from requests. Some of the Nerve Center functions can be done using Simple Requests (see Chapter 15). The Nerve Center Interface Library is described in the "Nerve Center Interface Library" chapter in the API Syntax.
14.2 Nerve Center Documentation
Information on Nerve Center components can be found in the following places in the Solstice EM documentation:
- This chapter describes the Nerve Center request terminology and operation.
- Chapter 15 Requesting Data in Solstice EM," provides step-by-step guidance on building and debugging request templates using the Design Advanced Requests, RCL, em_debug, and Simple Request.
- Chapter 17 Building Templates for SunNet Manager Event Requests," describes building and using request templates with SunNet Manager RPC agents.
- Chapter 18 Building Advanced Requests," describes the features and usage of the Design Advanced Requests application.
- Chapter 20 Request Condition Language," describes the components of the Request Condition Language used to build Nerve Center request templates.
- Chapter 22 RCL Functions," describes the built-in functions that can be used in building RCL conditions.
- The Requests tool is described in Chapter 4 of Managing Your Network.
- The Nerve Center interface library is described in the API Syntax.
- The request templates shipped with Solstice EM are described in Chapter 4 of Managing Your Network.
14.3 Nerve Center Operation
14.3.1 How a Request Gets Information
A request can get information in the following ways:
- It can poll for the attributes referred to in the conditions to be tested from its current state. The Nerve Center sets the values of the attributes before it "awakens" a request.
- It can subscribe for event notifications. The Nerve Center sets the values of variables related to the notification before it "awakens" the request.
- It can use a combination of (1) and (2). If a state uses both subscription and polling, its conditions can tell which of them "woke" the request by checking the value of $messType, described in Chapter 20.
14.3.1.1 Where and When a Request's Notifications Arise
An event that "awakens" a request can arise in either of two ways:
- A notification initiated by an agent
Agents originate notifications on their own. A request can subscribe to particular notifications. That is, it can ask the Nerve Center to pass it certain notifications. For example, a request might ask to receive all authentication-failure SNMP traps. A request for a specific managed object might ask to receive notifications that concern that object. After it has subscribed, the request has nothing to do but wait until a notification arrives. The subscription specifies whether the request will receive:
- After a request subscribes to a notification, it receives all such notifications, whenever they arrive, regardless of the request's current state.
- Requests can also use CMIS filters to select which notifications they want to receive.
- A response to a poll
Some information is provided by agents only on request from management stations, that is, when polled.
- A condition can refer to attributes of a managed object. Every reference to an attribute in a condition is interpreted as an implicit request to poll for that attribute. When a request goes through a transition and arrives at a state, it initiates periodic polls for the values of all the attributes it needs.
- For each state, the template specifies a periodic poll rate. The poll rate specifies the delay until the first poll and the interval between successive polls.
- When a request goes through a transition, in effect it sends the following request to the Nerve Center:
- "Cancel any previous poll requests I made. Set a timer to go off every <n> seconds from now and every <n> seconds thereafter. (The number of seconds is the poll rate for the request's current state.) Whenever that much time has elapsed, poll to get me the values of the following attributes. When you have obtained values for all these attributes, wake me."
The list of conditions for a poll contains all attributes mentioned in any of the conditions leading from the current state and also all attributes mentioned in any of the `actions' that accompany transitions from the current state. Actions are operations performed after the transition occurs from one state to another. Every poll of an attribute results in a CMIS GET request internally. RCL provides a system variable call poll. This variable must be set to the right object FDN before the polling occurs. This variable value is used by the FDR for the CMIS GET request. Then several attributes can be specified in a condition for a state or a set of conditions for a state. All of the attributes must refer to the same object to get the valid poll results for all of the attributes.
A state must be awakened by retrieving information from the MIS. Otherwise, a request sleeps in that state indefinitely. A condition as simple as the "jump" condition ($x=map; true;), supplied with Solstice EM, is sufficient to awaken a state. In this case, the value of the map attribute is accessed.
14.3.1.2 When Information From Managed Objects can Arrive
Event-related information from managed objects are of two types:
- Messages in response to a poll arrive according to the schedule set by the current state's poll rate.
- The Nerve Center notifies the request when it has assembled the values for all the requested attributes. A message in response to a poll arrives no sooner than the number of seconds specified in the poll rate, but possibly later.
- Notifications that come from an agent arrive at unpredictable times.
- After a request has subscribed for certain types of event, it receives notification of all events that match its subscription. They are forwarded at once, regardless of the state the request is in. What the request does with them, or whether it even looks at them, depends on the conditions the request tests in its current state. The RCL offers the following functions that allow you to subscribe to events.
14.3.2 Variables and Attributes in a Request
All requests built from the same template use the same names for variables and attributes. Values associated with these names are specific to an individual request. Any of the conditions that the template uses can refer to those names.
When a template is created, the Design Advanced Requests tool automatically scans the definitions of all the conditions mentioned in the template for references to variables and attributes. A template represents the definition, and a request is a running instance of a template.
14.3.2.1 Attributes
When a condition contains the name of an attribute, the Nerve Center automatically looks up the name in the Solstice EM MIS's MetaData Repository (MDR). Provided the attribute occurs only once in the MDR, using its name is sufficient to identify it. If the same attribute name occurs in different places in the MDR, the name can be qualified by including the name of the GDMO document in which it is declared. Refer to Section 14.3.5 Specifying the Objects to be Polled" for more information.
An ampersand precedes an attribute (or variable) name if you need to pass the address (rather than the value) of the attribute to an RCL function, such as defined() or extract(), as shown in the following code example.
CODE EXAMPLE 14-1
Attributes
14.3.2.2 System Variables
Certain names have standard meanings. If a condition refers to one of those names, the Nerve Center supplies the appropriate information. For example, if a condition needs to retrieve the time that a notification arrived, it can use the system variable $eventTime. If it needs to retrieve the message type of the current notification, it can use $messType. See Chapter 20 for a list of system variables and a list of the possible values of the $messType variable.
14.3.2.3 User Variables
Any condition can create a variable by using the name of the variable to the left of an equal (=) sign. The name of a variable must begin with the dollar sign ($). (The dollar sign distinguishes the names of variables from the names of attributes, because attribute names do not start with $.) For example, if you want the variable $count to be the number of consecutive times that confirmation of object X has been missing, some initial condition should contain a statement such as $count = 0; And some other condition should contain $count = $count+1; Using the name $count is sufficient to declare it.
A variable must first be assigned a value before it can be compared to another variable or attribute. For example, a condition that has the statement sysUpTime <$ last_sys_up_time; should not be called if the variable $last_sys_up_time has not yet been assigned a value.
All the variables mentioned in a request template share a common name space. That is, any condition used in a request can see or set any of the request's variables. However, no request has access to variables in another request.
14.3.2.4 How Notifications and Poll Responses are Delivered
When a notification arrives, the Nerve Center sets the values of all the system variables involved in a request. Similarly, when a poll response arrives, the Nerve Center sets the values of all the relevant system variables and attributes.
At the point when a request starts testing its conditions, the Nerve Center has already set the values of variables or attributes it needs. However, if the request uses both subscription and polling, it should check the $messType system variable to determine which type of event "woke" it. Following a notification or poll response, the values of attributes are those from the previous notification or poll response, if there was one.
14.3.3 Where and When a Condition is Evaluated
A condition is evaluated independently for each managed object that is the target of a request when the request is in a state that tests the condition, and when
- A poll response arrives, or
- An event notification arrives.
A notification to which the request subscribes can arrive at any time. A response from a poll cannot arrive until:
- The state's poll interval has expired, and
- The Nerve Center has returned the response from the poll.
14.3.4 Action at a Transition
The following subsections describe actions you can specify in your request templates.
14.3.4.1 Supported Actions
To invoke actions at a transition, you must select one or more of the actions from the Solstice EM list of supported actions. The types of supported actions are summarized in the following table.
You can specify any combination of the supported actions to occur in a transition.
Note – A condition can be invoked as an action. Indeed, conditions are a much more powerful way of defining actions than the use of UNIX commands or mail. This permits the power of RCL, together with its access to the variables defined within an individual request, to be combined in writing individualized actions.
14.3.4.2 Logging an Event
A log object (described in Chapter 5) stores selected event records. Each log object has a discriminator construct: a proposition that the MIS uses to decide whether to send a notification to the log or ignore it. In effect, each log object can adopt its own criteria for receiving notifications.
The Request Condition Language (RCL) (see Chapter 20) provides alarm logging functions (alarm(), alarmOi(), alarmStr(), and sendEvent()) to send notifications that can be logged to the log object alarmLog or a user defined Log Object. Log records written as a result of the alarm logging functions meet the criteria of the default discriminator construct. The alarm(), alarmOi(), and alarmStr() functions generate only nerveCenterAlarms. The sendEvent() function can be used to send other kinds of notifications (such as internetAlarms or communicationsAlarms). The events that are logged to a particular log depend upon the discriminator construct for that log. By default, Nerve Center Alarms are automatically logged into the Alarm Log.
14.3.4.3 Forwarding an SNMP Trap
The predefined condition called InternetTrap invokes the SendTrap function to send a trap notification to the host identified by the user-defined variable $Host. The condition uses the system variables $eventType and $eventInfo, which are set automatically upon receipt of an incoming trap. The definition assumes that $Host has previously been assigned the appropriate value, for example during the transition from the ground state.
14.3.5 Specifying the Objects to be Polled
You can write templates that specify a particular managed device as the target of the request. That request template would only be useful for managing that particular device. In most cases you will not want to write a new template for each target object. Typically, you define a template that can be used to manage objects of the same type -- for example, a certain type of router manageable via SNMP. The same template can then be launched against all the devices that share the same management characteristics (for example, routers that support the same SNMP MIB).
Using the $pollfdn system variable in templates helps you to define templates that can be targeted at different objects of the same type. In the following example the objective is to create a template that can extract the attributes under the snmp-mibII system group, such as sysDescr.
When a user launches a request template against a device selected in the Network Views, Nerve Center places all of the managed objects configured for the device into the system variable $pollFdnSet. "Managed objects" are internal representations in the MIS of the agent capabilities supported by the device. If Network Discovery was configured to search for RPC-based SunNet Manager agents when populating the MIS, devices that have both SNMP and RPC agents are configured in the MIS to indicate this. Fully distinguished names (FDNs) pointing to these managed objects in the MIS are thus loaded into the $pollFdnSet variable when a user launches requests against such a device.
Nerve Center uses another system variable ($pollfdn) to hold the target of the request. When a request is launched, Nerve Center initially sets $pollfdn to the first FDN in $pollFdnSet. However, the first agent name in $pollFdnSet may not be the appropriate agent to support this particular request. In designing a Nerve Center template, a typical task that should be performed in the template's initialization is to check $pollFdnSet to determine if the device is configured with the agent capability appropriate for the request, and, if so, to set $pollfdn to the appropriate object from those contained in $pollFdnSet.
The IsSnmpSystemUp template shipped with Solstice EM, for example, must be targeted at a device that supports SNMP, and $pollfdn needs to be set to point to the cmipsnmpProxyAgent object, which represents the SNMP agent system. Thus, the SetInternetSystem condition searches through the FDNs contained in the $pollFdnSet for the target device to find a match on "cmipsnmp". If no match is found, then the request knows the device is not configured appropriately for this template.
If SetInternetSystem does find a match on "cmipsnmp", it uses the RCL AppendRdn() function to set the target for the poll to the SNMP RFC 1213 internetSystem group object "contained" under the default cmipsnmpProxyAgent, which represents the agent system: $pollfdn = appendRdn($dn,"/internetSystemId=NULL");.
For example, the router bigguy is an SNMP agent system. A request launched against the bigguy has its $pollfdn set to the cmipsnmpProxyAgent /systemId=name:"gatoloco"/internetClassId={1 3 6 1 4 1 42 2 2 2 9 2 4]/cmipsnmpProxyAgentId="bigguy".
The cmipsnmpProxyAgent is the object in the MIS that represents the agent on the system being managed. The various attribute groups or tables accessible via the SNMP agent are represented by objects "contained" in the cmipsnmpProxyAgent object. Before it can establish polls for the object of interest, the request needs to append to the ObjectInstance a further specification of the object it wishes to poll.
In a Fully Distinguished Name (FDN) of the form /<naming-attribute>=<value>/<naming-attribute>=<value>/<naming-attribute>=<value> each <naming-attribute>=<value> designation is called a Relative Distinguished Name (RDN), and each RDN designates an object, which is said to be "contained in" the object designated by the RDN to its left in the path. The initial slash at the left represents the local root of the Management Information Tree (MIT). In the example above, the cmipsnmpProxyAgent for bigguy is contained in the MIS on the system gatoloco. Containment relationships are reflected in the path to the object specified in the FDN.
To set the $pollfdn to point to the snmp-mibII system group, the template must concatenate the Relative Distinguished Name (RDN) for the object of interest, which in this case is system. The SetInternetSystem sample condition, for example, resets the value of $pollfdn to point to the snmp-mibII system group object as shown in the following code example.
The appended RDN is a string that specifies the <naming-attribute>=<value> pair for the system group. The affect of this appendRdn operation on our request launched against the router bigguy is to change the value of $pollfdn to the following:
/systemId=name:"gatoloco"/internetClassId={1 3 6 1 4 1 42 2 2 2 9 2 4]/ cmipsnmpProxyAgentId="bigguy"/InternetSystemId=NULL14.3.6 Alarm Logging and the Alarm Service
The RCL alarm-logging functions (alarm(), alarmStr(), and alarmOi()) allow you to generate a nerveCenterAlarm which is, by default, logged to the AlarmLog. Alarms logged to the alarm log can be viewed and cleared in the Alarms application.
The AlarmLog is also, by default, monitored by the Alarm Service. The Alarm Service is a module in the MIS that controls the fault status color in the Network Views. Fault status is an attribute of topology nodes, which are represented by icons in the Network Views. Each topology node has an attribute topoNodeMOSet, which points to a set of managed object instances (MOIs), representing the agents configured for the particular device.
The Alarm Service associates an alarm posted to the AlarmLog with a topology node if and only if that alarm is posted against one of the managed objects in the topoNodeMOSet for that topology node. The Alarm Service tracks the perceivedSeverity values of the alarms that are posted against each topology node. The highest perceivedSeverity value of uncleared alarms determines the fault status of the device. Thus, if a critical alarm is logged against router bigguy, the router icon, by default, turns red. If several minor alarms are then posted against bigguy, these do not cause the router icon to turn cyan unless the critical alarm has been cleared. Requests can clear previous alarms they have posted against a device by posting an alarm with a severity of cleared. For example:
$info = StrToAsn("EM-NC-ASN1.NerveCenterAlarmInfo","{1,5,\"Device is up\",3,1}");alarmOi($save_pollfdn,$info);Note that, in the above example, the probableCause value (the first value in the set of ASN.1 values making up the alarm) has been set to 1 in the clear alarm -- the same probableCause value used in the critical alarm. For an alarm to clear a previous alarm, it is necessary that the probableCause value of the clear alarm match the probableCause value of the alarm being cleared. If the alarm() or alarmStr() functions were used to log nerveCenterAlarms, the probableCause is automatically set to a value that matches the severity of the alarm. For this reason, only the alarmOi() function can be used to log alarms that clear previous alarms.
The alarm() and alarmStr() functions posts a nerveCenterAlarm against the managed object that the $pollfdn variable points to at the time when the alarm-logging function is called. If you have reset the $pollfdn variable to point to an object other than one of those comprised in $pollFdnSet in your request, you can use the alarmOi() function, which enables you to specify the managed object against which the alarm is to be posted.
For example, if you reset $pollfdn to point to the internetSystem group under the cmipsnmpProxyAgent object, you can retain the original pointer to the cmipsnmpProxyAgent in a variable $snmpfdn, and then post an alarm using that variable:
|
Sun Microsystems, Inc. Copyright information. All rights reserved. |
Doc Set | Contents | Previous | Next | Index |