5.1 Specifying an Event

You specify the event conditions, event notification, and actions for individual elements by using the Event Request Properties window.

You can compose your own event request, targeting a specific machine for a specific set of information. More conveniently, you can use a predefined request. These requests save you the trouble of composing requests for individual machines.

The product is shipped with a number of predefined event requests that can accommodate many of your network management needs. You can choose one of these requests, modify it for a specific need, or build your own request.

5.2 Scheduling Requests Based on Events

Starting with version 2.3, you can start or stop requests as the result of an event. For example, a ping request may send ICMP packets to a device at regular intervals and generate an event if there is no response. If a device goes down for an extended time and the request continues to launch at the same intervals, a significant number of reports would be generated if no action is taken.

Under such conditions, it would be helpful to stop the event request and put the device in a pending state. This would reduce unnecessary management of network traffic.

With event-based requests, you can:

• Stop the current request
• Start another event request
• Carry out the event request on a different proxy agent using the alternate proxy field

You can combine these options or use them independently.

Use the Properties sheet for an event request to define a schedule (see Figure 5-1).

Figure 5-1

Use this screen together with the Request Builder (as demonstrated in examples that follow) to specify details of how SunNet Manager should handle your request.

5.3 Retrieving Single Attributes

Starting with version 2.3 of the product, you can use an event request to retrieve a single attribute or a subset of attributes. Previously, an event would generate a report containing information about non-requested, as well as requested, attributes in a group.

Here is an example of the type of new report you can generate:

Event Report

Mon March 4 16:58:00 1996 [yercaud]: Event: snmp-mibII.system
sysUpTime=26:14:24:68 (Greater Than 00:00:00:00 Priority Low)

The report shows the requested attribute, sysUpTime. Previously it would also have included non-requested information such as sysDescr, sysObjectID, sysContact, sysName, sysLocation, and sysServices. You can see the type of report previously generated by specifying false on the keyword get-requested-attributes-only in the snm.conf file.

5.3.1 Sending an Event Request Through the Console Requests Menu

1. Click SELECT on the glyph that represents the target element.

2. Press MENU on the Requests button in the control area of the Console and release MENU over Send Request.

   The window shown in Figure 5-2 appears. The Request Action field is automatically set to Send Request.

Figure 5-2

3. Click SELECT on the Request Type you want to send (event, in this example). Press MENU on the Request Name abbreviated menu button. You receive the menu shown in Figure 5-3.

Figure 5-3

4. Choose a predefined request from the Request Name menu.

5. If you need to create your own request, do the following:

   a. Click SELECT on an agent in the Agent Schema scrolling list b. Click SELECT on a group name in the Group scrolling list.

   c. Choose NEW_REQUEST from the Request Name pull-down menu.

6. Click SELECT on the Apply button.

   You receive a Data Request Properties window, as shown in Figure 5-4.

7. Examine the window and make any changes you want.

Figure 5-4

1. On the left side of the request window, modify or fill in the report characteristics fields.

2. On the right side of the request window, select the attributes on which you want the agent to send data, and how you want to view the data.

3. Press MENU on the Attribute menu button and release MENU over the attribute you want.

4. Click SELECT on Apply to add the attribute to your request. After selecting and applying attributes and their viewing options, click SELECT on the Start button on the lower left side of the window to send the event request to the agent.

For a description of the fields in the Event Request template, refer to "Part2: Reference."

5.3.1.1 Using Event Requests to Monitor Critical Nodes

Use the Event Request Properties window to specify conditions that define an event and the type of notification you want to receive. You can compose your own event request or, more conveniently, use a predefined request. Predefined requests included with the current product are summarized in Table 5-1.

Table 5-1

Request Name	Agent Name	Group Name	Attributes Supported	Event to be Reported
when Disk is Full	diskinfo	diskSpace	capacity	disk file system is full
If System Reboot	hostperf	data	uptime	if system reboots
when Printer Error	lpstat	status	statusCode	line printer error
when System is not Reachable	ping	reach	reachable	system not reachable

The examples that follow show how to send event requests.

5.3.2 Sending Predefined Event Requests through the Glyph Menu

5.3.2.1 Example: Monitoring Node Availability with Ping

To be informed immediately if any of your critical nodes goes down, use an event request with the ping agent. For convenience, you can use the predefined event request "when System is not Reachable" and specify the default (blinking glyph).

Here are the steps:

1. Display the glyph menu by pressing the MENU button over the glyph representing the target device.

2. Select the predefined event request from this menu as shown in Figure 5-5.

Figure 5-5

Using this method, the predefined request, "when System is not Reachable," does not take advantage of the "decay" feature. The default is for the glyph to blink when an event occurs, as indicated on the Properties sheet in Figure 5-6.

Figure 5-6

To change the default, use the Request Builder, as explained below.

Using Request Builder Use the "decay" feature to cause the device glyph to turn blue (the default color) or to the color you have customized, to alert you when a device has been unreachable at any time since you last cleared an event for it.

Here are the steps:

1. Select the target router and access Request Builder by pulling down the Console Requests menu, as shown in Figure 5-7.

Figure 5-7

2. Select the agent (ping), attribute group (reach), request type (Event Request), and then "when System is not Reachable" -- the name of the predefined event request to use as a starting point for specifying the new event request.

3. Click SELECT on the Apply button to display the Properties sheet.

4. Create a new event request to take advantage of the "decay" feature by:

a. pressing MENU on the Glyph Effect button and releasing MENU over the Color By Priority option. See Figure 5-8

Figure 5-8

b. clicking SELECT on Apply to add the attribute to your request

c. clicking SELECT on the Start button to send the event request to the agent.

5.3.2.2 Example: Using sysUpTime to Monitor SNMP Device

The Ping agent can only determine if a device is available when it polls the device. However, between polls, you may want to be notified if routers have gone down momentarily and then become available again. Use the SNMP sysUpTime attribute to check for this on devices that support Simple Network Management Protocol (SNMP).

1. Build an event request by pressing MENU over the target element

2. Select Send Request to invoke the Request Builder window, as shown in Figure 5-9.

3. Select Event Request, the snmp-mibII agent, and the system group.

Figure 5-9 system

4. Click SELECT on the Apply button to access the Event Request Properties sheet, Figure 5-10.

Figure 5-10

In Figure 5-10, the following values have been set in the event request fields.

• Attribute: sysUpTime
• Relation: Decreased by More Than
• Threshold1: 1. An event is generated when the value of sysUpTime decreases by more than.001 seconds. If the system is up less time than on the previous poll, the system went down between polls. sysUpTime measures time, in hundredths of a second, since the last system restart.
• Interval: 600 seconds (ten minutes)
• Count: 0 (to continue indefinitely)
• On Completion: Save Request (to prevent the request from being deleted if you stop it).
• Priority: High
• Glyph Effect. Glyph will blink to indicate a new event.

5. To implement these selections, click SELECT on the Apply button. The attribute name will then appear in the window at the upper right.

6. Click SELECT on the Start button to launch the request.

5.3.2.3 Example: Using ifOperStatus to Monitor Router Interfaces

Use the SNMP ifOperStatus attribute to monitor the availability of router interfaces.

1. Select the target router,

2. To access the Request Builder, select Send Request from the glyph popup menu or the Console Requests pulldown menu.

3. Select Event Request, the snmp agent, and the ifStatus group, as shown in Figure 5-11.

Figure 5-11 ifStatus

4. Click SELECT on the Apply button to access the Event Request Properties sheet shown in Figure 5-12.

5. Click SELECT on Start to send the request.

Figure 5-12 ifOperStatus

A partial list of values entered in the Event Request Fields are shown below:

Attribute: IfOperStatus

Relation: Not Equal to

Threshold1: 1. The condition that defines a critical event is when the interface is not up. The interface is not up if ifOperStatus has a value other than 1.

Key: If this field is blank, an event is generated if any of the router's interfaces are not up. To test for a particular interface, enter the ifIndex number for that router in the Key field.

5.3.2.4 Generating a Report on Router Interface Status

To generate a one-time report to check the status of all interfaces on a router:

1. Click MENU on the target glyph.

2. Click SELECT on Quick Dump >> snmp >> ifStatus.

   This Quick Dump returns the status of all interfaces.

5.3.3 Example: Monitoring Network Traffic Load Using Request Builder

Periodic data reporting can help you determine thresholds in capacity utilization rates or traffic levels where problems occur. You can use these threshold levels to define event requests that tell you when these conditions occur.

In the example below, the traffic agent is used to generate an event report when there is an unusually high level of activity between any two nodes on the network. In this case, the particular threshold may have been determined by previous sampling of traffic levels on this network.

This event request is targeted at the Ethernet bus in each of the network's subnets. To generate the request:

1. Select the Ethernet bus glyph in a subnet view.

2. Invoke the Request Builder by selecting the Console's Requests >> Send Request option.

3. Select Event Request type, the traffic agent, and the BetweenIP group, as shown in Figure 5-13.

Figure 5-13 traffic

4. Click SELECT on the Apply button to invoke the Event Request Properties window as shown in Figure 5-14.

Figure 5-14 traffic

5. Click SELECT on the Start button to launch this request.

All fields in the Event Request Properties sheet are described in Chapter 15, "Requests Management."

The fields in this example have been completed as follows:

• Attribute: Set to "pkts".
• Relation1: Set to Greater Than.
• Threshold1: Set to 400. In observing the network, you may have noticed that if more than 400 packets are sent between two nodes, it creates an abnormally high rate of network activity. "Greater Than 400," then, defines the condition for generating an event notification.

• Glyph Effect: Set to Color by Priority. This allows you to take advantage of the "decay" feature, to indicate that this condition has occurred at some time since you last cleared an event. You can customize the color of the glyph. You need not use blue.
• Mail To: You can specify your e-mail address in this field. Any e-mail message generated by this event would contain the IP addresses of the two nodes whose packet activity exceeded 400.
• Interval: This value is set to 60 so the agent polls every minute to compare the result with the specified threshold value.
• Count: This value is left at 0 (the default) so that the event request will continue indefinitely.

After launching this request for the gateway node in one subnet, you can copy it from the subview of that node and paste it into the subview of a gateway node on each additional Ethernet subnet you want to monitor. Copying the request to the subview of an element launches a clone of that event request targeted at the node where the request has been copied.

5.3.3.1 Alternative Ways to View the Properties Sheet for Event Requests

1. Double-click on the target glyph.

2. Click SELECT on the glyph for the request

3. Click SELECT on the Props button in the Console's control area.

4. Invoke Requests >> Requests Summary from the Console's control area.

5. In the Requests Summary window, find and click SELECT on your request,

6. Click SELECT on the Props button in the Requests Summary window.

   In that window, the Select and Sort menus can be very useful in finding your request.

5.3.3.2 Example: Managing Log Files Using Predefined Request

You can use event requests to help you manage the management station, itself. In this example, an event request is defined to generate an alarm when the file system where the Console log files are mounted (/var), is more than 90% full,.

1. Click SELECT the glyph representing your management station.

2. invoke the Request Builder through the Requests >> Send Request option.

3. As shown in Figure 5-15, select the diskinfo agent and Event Request in the Request Builder.

Figure 5-15

4. Click SELECT the "Apply" button, to get the Event Request Properties sheet in Figure 5-16.

Figure 5-16

5. Enter the appropriate data in each field.

6. Click SELECT on Define to launch the request.

Each field on the Properties sheet is described in Chapter 15, "Requests Management."

Selected fields in the example above are defined as follows:

Interval: specifies a polling interval of 15 minutes.

Count: 0. The request will continue until an operator stops it.

For event reports, the Interval and Count fields simply specify when the agent is to send a report. A report is forwarded to the Console system only if it has been determined that an event has occurred. For agents that are shipped with SunNet Manager, the value reported for an attribute is the value noted at the reporting interval. Thus, it is possible for event conditions to occur between reporting intervals which will not generate an event report.

If a count is specified and a stop date and time are specified, the earlier of the two takes precedence. For example, if a count of 100 is specified and a stop date of 9/13 is specified and a stop time of 12:30 am is specified, the request will stop if 100 occurs before the stop date and time. If the stop date and time occur before the count is reached, the request will stop at the specified stop date and time.

Send Once: If the Send Once field is off (no check mark appears in the accompanying box), an event report will be sent for every event occurrence. If the Send Once field is on (a check mark appears in the accompanying box), it means that after the first event report is received by the Console, the request is killed. To specify Send Once, click SELECT on the box to display a check mark.

Key: /var--in this example. For the diskinfo agent, Key specifies the relevant disk partition -- for example, the file system that would be indicated in the "Mounted On" column in a df command output. In this example, the log files are situated in a separate partition.

On Completion: Save Request. The request will not be deleted if we stop it.

Attribute: in this example "capacity" designates the percentage of total capacity used. The condition defining the event is capacity Greater Than 90.

Glyph Effect: Color by Priority. If the event condition is met, the glyph, will turn red (or, starting in version 2.3, to a color you select).

By default, an event's glyph effect options remain in effect for 10 seconds beyond the reporting interval. If another event does not occur within this time, the Console cancels the glyph effect. You can increase the 10-second glyph effect overlap time in the Console Properties window. See the description of the Event Effect Overlap Time setting in "Part 2: Reference."

Start Date: 06/30/96. Start the request on this date.

Stop Date: 06/30/96. Do not run the request beyond this date.

Start time: 3:00 p.m. Start the request at this time.

Stop time: 3:15 p.m. Do not run the request beyond this time.

When you specify a start date and time and click Start, the request status is listed as "scheduled" in the request summary window.

5.3.3.3 Available Predefined Requests

Predefined requests available (and the agents listed in the Agent Schema list in a Request Builder window) for a given machine depend on the agents that have been checked off as present in the Properties window for that machine. A machine which does not have SunNet Manager on it, that the IP Discover tool adds to your database, has the hostperf and ping agents checked off. Information is available from a machine without agents through SunNet Manage's proxy feature, just as if the hostperf and ping agents were on that machine. A machine with agents installed that the IP Discover tool adds to your database, has the agents checked off that are actually present.

5.3.3.4 Automatically Opening an Icon

You can choose to have a Console window that is closed to an icon open automatically when an event or trap is received. You specify this in the Console's Properties window, available by clicking SELECT in the Props button in the Console's control area. See the description of the Open on Event or Trap setting in "Part2: Reference."

5.4 Detecting the Presence of an Event

This section describes how you can use the Alarm Reports or Event/Trap Reports windows to monitor events. You obtain these from the View menu in the Console's control area (View >> Alarm Reports or View >> Event/Trap Reports). You can use either of these windows for all elements in a view or for a specific element. An alternative, and perhaps easier, way to detect an event for a specific element is to observe the visual effect of an event as it shows in a glyph.

If an event occurs, a glyph can blink, dim, change color, or remain unchanged. You choose the effect you want in the Properties window at the time you make an event request. SunNet Manager has a "decay" feature that allows you to detect that a condition that caused an event report occurred and that the condition no longer exists. For example, a file server might exceed a threshold you have set for a certain number of NFS transactions, then fall below that threshold. To take advantage of the "decay" feature, you must specify Color by Priority as your Glyph Effect.

See the example, "Sending Predefined Event Requests through the Glyph Menu" on page 5-8 for instructions on specifying a request to take advantage of the "decay" feature.

5.5 Checking the Cause of an Event

When an event occurs, a report is returned to the Console that indicates the cause of the event. The Console gives you two ways to view an event report:

• The Event/Traps Reports window, described in this section.
• The Alarms Summary window (available in the View >> Alarm Reports window). This window displays error, event, and trap reports and is described in the Section on "Viewing Alarm Reports" later in this Manual.

To check the cause of an event in the Event/Trap Reports window, perform the following steps:

1. Press MENU over the View button, and Release MENU over Event/Trap Reports. (See Figure 5-17.)

Figure 5-17

2. To examine event and trap reports for a particular system, type in the device name after the Device prompt and press Return.

   To see entries for all elements again, press Ctrl-U to clear the Device line and press Return.

   An alternative way to obtain an element-specific event or trap report is to click SELECT on the glyph in the Console window, then invoke View >> Event/Trap Reports.

3. To save the event reports to a file, click SELECT on the Save button.

   A pop-up Save window appears, where you can enter the path and file name where the Event/Trap Reports are to be stored.

4. To browse through entries in the log:

• Press SELECT on the slider and drag the slider to the left or right.
• Click SELECT to the left or right of the slider.
• Click SELECT on either end of the slider bar.
• Enter the number of a report on the Report line and press Return.

5.5.1 Event/Trap Reports Window

Event/Trap Reports entries are time-stamped and show values for all attributes in the specified agent group. The attribute and value that caused the event are flagged with the relational operator and threshold values shown in parentheses to the right.

By default, a maximum of 1000 event reports are displayed in the Event/Trap Reports window. You can change the maximum number in the Console Properties window. To view or change this setting (or any other event- or trap-related setting), click SELECT on Props in the Console's control area, then select Miscellaneous in the Category pulldown menu. See the description of the Maximum Event Reports setting in "Part 2: Reference."

5.6 Changing a Glyph State Back to Normal

A glyph may change its state when an event or a trap is received for the element that is represented by the glyph. For example, if you have specified an event for an element and the notification is "Blink Glyph", the element's glyph state changes from "normal" to "blinking" when the event occurs. Once you have been alerted to the event, you may want to change the state of a glyph back to "normal." This is done using the Glyph State option of the Glyph menu for the element.

5.7 Glyph Pending State

Starting with version 2.3 of SunNet Manager, you can also put a glyph to pending state. You might want to use pending state when a device has been down for an extended period and events continue to be logged against it, or when you know that someone is repairing the device and you do not want new events or traps against the device to have any effect.

When you click Pending On, the glyph goes to pending state, and the color of the object is dimmed. All outstanding events and traps on the device are cleared and the object is "frozen." New events and traps will not change the appearance of the glyph state or propagate the effect of a trap or event to the parent object. If a parent object is in pending state, a change in the state of the children will not affect the parent.

When you click Pending Off, pending state is turned off, and the object is an end node or device, its glyph state is recalculated based on any outstanding alarms. If there are none, the glyph state is set to normal. If the glyph object is a parent inheriting from its children, its state is recalculated appropriately.

When a pending device is moved to normal state, all outstanding alarms are cleared. If the glyph object is a parent, the state of the children are set to normal, also.

To change the state of a glyph, follow the steps below:

1. Press MENU over the glyph whose state you want to change.

2. Release MENU over Glyph State and drag right to the desired glyph state. See Figure 5-18.

Figure 5-18

5.8 Propagation of Glyph States

Whenever a glyph state is changed as a result of an event or a trap, the glyph state is propagated through the view hierarchy. If a glyph is contained in more than one view, its state is propagated through its multiple view hierarchies. When the Console is closed to an icon, glyph state changes reflected in the Home view cause the Console icon to display question marks. These effects are not true for pending state.

When you change the state of a glyph, the new glyph state is propagated as though an event had occurred to change the glyph state. For example, if you change the glyph state of an element from "normal" to "blinking," the glyph state "blinking" propagates as if an event had occurred.

If you have multiple glyph states propagating into a single view and you change the glyph state for the view to "normal," the glyph states of the elements contained in the view are also reset to "normal." For example, if you

change the glyph state of a view from "blinking" to "normal," this clears the effects of the event that caused the glyph state to change to "blinking." This allows you to clear multiple events by resetting the glyph state of a view.

You can also choose to have errors that are received from agents cause a change in the glyph state of an element. By default, this is not enabled. See the description of the Errors category of the Console Properties window in "Part 2: Reference."

5.9 Changing the Propagation of Glyph State Changes

By default, glyph state changes caused by events or traps are propagated through the view hierarchy, except for glyphs in pending state. You can disable glyph state propagation in several ways.

To disable glyph state propagation for a particular view:

1. Press MENU over the glyph that represents the view.

2. Release MENU over Properties to open the Properties window for the view. (SeeFigure 5-19.)

Figure 5-19

3. In the Properties window, press MENU over the Glyph State abbreviated menu button in the top portion of the window.

4. Release MENU over the Not Inherited option.

5. Click SELECT on the Apply button.To disable glyph state propagation for all views in the database:

1. Click SELECT on the Props button in the Console window.

2. In the Console Properties window, press MENU over the Category abbreviated menu button to open the categories menu.

3. Release MENU over Events and Traps. (See Figure 5-20.)

Figure 5-20

4. In the Events and Traps categories window, click SELECT in the box next to the Propagate Event Effect setting to toggle the check mark off. (See the Figure below.)

Figure 5-21

5. Click SELECT on the Apply button.

To disable propagation of glyph states caused by traps:

1. Open the Events and Traps category settings in the Console Properties window, as described in the previous steps.

2. Click SELECT in the box next to the Traps Propagate Effect setting to toggle the check mark off.

3. Click SELECT on the Apply button.