Global Attribute Editing

Every managed object in an agent has attributes. Attributes are pieces of information that define the object's behavior. Examples of attributes are alarm limits, alarm actions, refresh intervals, history logging parameters, module schedule and security access control parameters.

The objects are self-describing, meaning that each object defines which attributes it makes available for editing. Therefore, an object may have none or all of the aforementioned attributes. When the Attribute Editor is launched for an object, the WebPortal asks the object for its attribute information, and provides a user interface to modify the attribute values.

Launching the Attribute Editor

The Attribute Editor can be launched from several different places. For a domain, the Edit button on the Domain Bar will launch the Attribute Editor. The Actions button will launch a special Attribute Editor that can be used to configure alarm actions for the domain.

For a topology object, the Attribute Editor can be launched from the Domain View's Context Popup Menus. For some topology objects, there may also be an entry labeled Alarm Actions... in the popup menu that will launch a special Attribute Editor that can be used to configure alarm actions for the object.

For a host, the Attribute Editor can be launched from the Edit button on the Host Bar.

For a module, the Attribute Editor can be launched from the Host View's Context Popup Menus.

For module properties, the Attribute Editor can be launched from the Module Properties View's Context Popup Menus.

The Attribute Editor

An example of an Attribute Editor is shown in Figure 20.

Figure 20 - The Attribute Editor

At the top of the Attribute Editor, the Location and Object labels indicate which object's attributes are being edited, and where the object is located. The Type label indicates the object's type.

An object's attributes are categorized into Attribute Groups which appear as separate sections in the Attribute Editor. Each section is labeled with blue text and is separated from the other sections with a horizontal line.

A list of the available sections appears near the top of the Attribute Editor. Each entry in the list is a link to the top of the section within the Attribute Editor.

The last section shown is labeled Apply To. This section enables the WebPortal's Global Attribute Editing feature. See the documentation on the Apply To section for more information.

Following the Apply To section there are several buttons. Click the button labeled Apply to apply the attribute changes to the object. The button labeled Reset will reset the form to the original values. The Print button, available only for Netscape, will print the contents of the page. For Internet Explorer, right click on the page and select Print from the popup menu. The Cancel button will close the window and cancel the attribute editing, and the Help button will launch this page in a browser window.

A description of the more common Attribute Groups and the attributes they typically contain is described below.

The Alarms Section

The Alarms section will appear in the Attribute Editor for any object that can trigger an alarm. It will contain details about the specific Alarm Rule that the object uses to determine if and when an alarm should be triggered.

The most common Alarm Rule is rCompare, which defines simple thresholds for the object's value. When the value crosses any of these thresholds, an alarm is triggered. The rCompare rule also supports alarms when the value equals a threshold value, does not equal a threshold value, or matches a regular expression pattern.

A typical Alarms section employing the rCompare rule is shown in Figure 21.

Figure 21 - The Alarms Section

The name of the rule and details about the rule and its parameters are displayed. If any alarm rule parameters are editable, they can be modified in this section.

This section may also contain an option to define an Alarm Window. This is a time interval during which alarms can occur for this object. At times outside of the specified Alarm Window, no alarms will be triggered from this object. See the documentation on Time Window Expression Syntax for more information.

The Actions Section

When an alarm is triggered, the agent can take immediate action either to send a notification about the problem, or to take a corrective action. These actions can be defined in the Actions section, shown below.

Figure 22 - The Actions Section

Specific actions can be defined for each alarm state, for when the alarm condition closes, or for any change in the alarm status of the object.

The actions defined here must follow the following rules:

1. The entered value up to the first space must be an executable file located in directory <ESDIR>/bin on the agent, normally /var/opt/SUNWsymon/bin. 
2. The executable file must be owned by user root. 
3. Arguments can be passed to the action by separating them with spaces.

The Refresh Section

The period at which the agent accumulates data for an object is often configurable in the Attribute Editor's Refresh section. A typical Refresh section is shown below:

Figure 23 - The Refresh Section

The value for the Refresh Interval is usually expressed as a simple regular polling interval in seconds. However, more advanced refresh intervals can be specified here, using the Time Expression Syntax.

Note that the refresh interval only defines the agent's polling interval, and does not affect the polling interval of the user interface. For the Sun Management Center Console the user interface polling interval is fixed. For the WebPortal, the polling interval can be configured in the Continuous Update Windows.

The History Section

The historical values for an object can be recorded by changing the options in the Attribute Editor's History section. A typical History section is shown below:

Figure 24 - The History Section

The historical values can be stored in three forms:

1. A circular logfile on the agent host's filesystem
2. A flat logfile on the agent host's filesystem
3. In the agent's memory

The agent has only one circular logfile for history logging, called history.log, located in directory <ESDIR>/log, usually /var/opt/SUNWsymon/log. This file can only hold 1000 entries, at which time the file wraps and starts overwriting the oldest entries. Note also that all objects in the agent that have circular file history logging enabled will share the same file.

The Flat File logging option contains an option to specify a separate filename for the data, however, more than one object's historical data can share the specified file. This file will be created in <ESDIR>/log, usually /var/opt/SUNWsymon/log, and will have the extension .history even if not specified in the Attribute Editor. Note that this file will not wrap, and will continue to grow in size, so caution should be used when specifying this option.

History logged to memory will be automatically retrieved when a Graph is launched for the object in the Sun Management Center console. The number of data points stored in memory can be configured here.

The Sample Interval defines how often the data is logged, either to a file or to memory. The value is usually expressed as a simple regular polling interval in seconds. However, more advanced sample intervals can be specified here, using the Time Expression Syntax.

The Security Section

Managed objects in Sun Management Center are subject to security access control. The access control for some objects can be modified in the Attribute Editor's Security Section. A typical Security section is shown below:

Figure 25 - The Security Section

There are three different access levels for an object, namely Administrator, Operator, and General. The specific users, groups, and SNMP communities that have each of these three access levels can be configured.

The General access level is required to simply read information about an object. The Operator access level is required for less drastic write operations, such as enabling and disabling modules. The Administrator access level is the highest level. With this access level permission for all write operations will be granted.

The Security section is available for domains, topology groups, hosts, and modules. Objects within a module are subject to the access control settings for the parent module.

However, the modules within a host are not subject to the access control settings of the host. If you need to modify the access control for an entire host, including its modules, the settings should be applied to each of the host's modules as well.

The Schedule Section

The Schedule normally appears for a module. It can be used to automatically enable and disable the module at specific times. A typical Schedule section is shown below:

Figure 26 - The Schedule Section

To set a module schedule, use the Time Window Expression Syntax.

The AlarmAction Section

The AlarmAction section applies only to domains, topology groups, and topology objects. It will appear when the Attribute Editor is launched from the Alarm Actions... entry in the Context Popup Menu, or from the Actions button on the Domain Bar.

Unlike the alarm actions defined in the Actions section, alarm actions defined here apply to the topology objects and/or groups in the server, rather than objects within the agents. These alarm actions are triggered by the server when it detects that an agent is down, or that a host is down.

A typical AlarmAction section for a topology group is shown below:

Figure 27 - The AlarmAction Section for a Topology Group or Domain

The actions defined here must follow the same rules as the actions defined in the Actions section. Separate actions can be taken when an agent is down (host cannot be reached using SNMP) or when the host is down (host cannot be reached using ping).

For a group, the actions will be triggered when any one of the objects within the group is unreachable, unless the object has been configured to exclude group actions. A typical AlarmAction section for a topology object is shown below:

Figure 28 - The AlarmAction Section for a Topology Object

The object can be configured to exclude group actions by unchecking the checkboxes. If the object is not configured to exclude group actions, and actions are defined both for the object and its parent group, both actions will be triggered.

The Apply To Section

The Apply To section enables all attribute changes to be applied Globally. For each type of object whose attributes can be edited, the Apply To section enables the changes to be applied to other similar objects on the same host and even on other hosts.

Global Attribute Editing for Domains

Figure 29 displays the Apply To section for an Attribute Editor launched on a Domain.

Figure 29 - The Apply To Section for a Domain

The Current Domain is the domain from which the Attribute Editor is launched. By default, the changes will always be applied to the Current Domain. A list of all additional domains in the server will also be shown. Attribute changes will also be applied to any selected domains in this list.

Global Attribute Editing for Groups

Figure 30 displays the Apply To section for an Attribute Editor launched on a Topology Group.

Figure 30 - The Apply To Section for a Group

The Current Group is the group from which the Attribute Editor is launched. By default, the changes will always be applied to the Current Group. A list of all additional groups in any of the server's domains will also be shown. Attribute changes will also be applied to any selected groups in this list.

Global Attribute Editing for Topology Objects

Figure 31 displays the Apply To section for an Attribute Editor launched on a Topology Object.

Figure 31 - The Apply To Section for a Topology Object

The Current Object is the object from which the Attribute Editor is launched. By default, the changes will always be applied to the Current Object. A list of all additional objects in the same group will also be shown. Attribute changes will also be applied to any selected objects in this list.

Global Attribute Editing for Hosts

Figure 32 displays the Apply To section for an Attribute Editor launched on a Host.

Figure 32 - The Apply To Section for a Host

The Current Host is the host from which the Attribute Editor is launched. By default, the changes will always be applied to the Current Host. Any number of additional hosts can be specified in the Additional Hosts textfield, simply by typing in a list of host names separated by spaces or commas. Also, a picklist of the server's Domains can be used to apply the changes to all hosts in the selected domain.

TIP: If any of the hosts specified in the Additional Hosts textfield are not using the default SNMP port (161), add the text ":<port>" after the hostname, where <port> is the port number of the agent on the host.

Global Attribute Editing for Modules

Figure 33 displays the Apply To section for an Attribute Editor launched on a Module.

Figure 33 - The Apply To Section for a Module

The attribute changes by default will be applied to the Current Module on the Current Host. Additional hosts can be specified in the Additional Hosts textfield, simply by typing in a list of host names separated by spaces or commas. Also, a picklist of the server's Domains can be used to apply the changes to all hosts in the selected domain.

To apply the changes to other modules on the Current Host and also on any other specified hosts, select the other modules in the Additional Modules list.

TIP: If any of the hosts specified in the Additional Hosts textfield are not using the default SNMP port (161), add the text ":<port>" after the hostname, where <port> is the port number of the agent on the host.

Global Attribute Editing for Table Cells

Figure 34 displays the Apply To section for an Attribute Editor launched on a Table Cell.

Figure 34 - The Apply To Section for a Table Cell

The attribute changes by default will be applied to the Current Row of the table on the Current Host. Additional hosts can be specified in the Additional Hosts textfield, simply by typing in a list of host names separated by spaces or commas. Also, a picklist of the server's Domains can be used to apply the changes to all hosts in the selected domain.

To apply the changes to other rows of the table on the Current Host and also on any other specified hosts, select the other rows in the Additional Rows list.

TIP: If any of the hosts specified in the Additional Hosts textfield are not using the default SNMP port (161), add the text ":<port>" after the hostname, where <port> is the port number of the agent on the host.

Global Attribute Editing for Leaf Nodes

The Apply To section for a Leaf Node within a module appears identical to that for a Host in Figure 32. If additional hosts are specified, the attribute changes will be applied to the same Leaf Node on each specified host.

The Attribute Changes Report

After the attribute changes have been applied to all specified objects, the Attribute Changes Report is displayed. A typical report is shown below:

Figure 35 - The Attribute Changes Report

The first table lists the attributes that have been changed, and the new values that have been applied. The second table lists each individual object where the changes have been applied, including the host and port of the agent, and the name of the object. For each object, a message indicates if the attribute change was successful, or if it failed. If the change failed, a reason will be specified.

TIP: To navigate directly to each object where attribute changes were applied, click on the link in the Result column of the table.