< Previous  | TOC | Index | Next  >

Events, policies, and notifications

The Cluster Management Console monitors clusters, generates events, and responds to events by sending notifications or performing an action. Cluster problems or changes in cluster configuration or state can cause the management server to generate an event and initiate a response.

The Cluster Management Console enables you to create and configure notification policies. The management server uses policies to determine how it responds to an event.

The event-response process occurs in the following three steps:

• The management server generates events when it receives cluster status updates that indicate problems or issues of sufficient severity.
• The management server evaluates the events against the conditions specified in all policies.
• For each policy condition that is met, the management server performs the response specified in the policy.

The management server can respond to events by sending SNMP traps, by sending e-mails or by running custom scripts.

  Note   Ensure that you place all custom scripts in the $data_dir/CustomScripts folder.

You must be a management server user with administrator privilege to create notification policies. Management server administrators can also view, edit, or delete their own policies or those created by other administrators. All configured policies are in effect at all times regardless of the administrator that created them.

You must specify the following conditions in a policy configuration:

• Object type condition

  Specifies the type of cluster objects to which the policy applies. The available object types are:

  • cluster
  • service group
  • service groups and associated resources and systems
  • system
  • resource

    ---

      Note   Notification policies for all object types may not work properly if the management server database contains duplicate cluster names.

    ---

• Filter condition

  Specifies the object filters. It is based on the object type you have selected. The available filter conditions are:

  • All objects
  • A list of objects that you specify
  • A list of operating systems that you specify, if the object type is system
  • A list of resource types that you specify, if the object type is resource
• Event condition

  Specifies the events to which the policy applies. The possible events vary by cluster object. If you do not specify an event condition, the policy applies to all events. The following table lists all events that the management server can monitor:

   

  Cluster events	Cluster faulted  Cluster exited  Cluster joined
  System events	System exited  System joined  System faulted  System in jeopardy  System out of jeopardy
  Resource events	Resource faulted   Resource monitor timed out   Resource offline ineffective   Resource in administrator wait   Resource restarting   Resource offline   Resource state unknown  Resource online  Resource flags none
  Service group events	Group offline   Group concurrency violation   Group partial online   Initiated group offline   Group online   Group fault   Initiated group online

• Severity condition

  Specifies the event severities to which the policy applies. The available severities of an SNMP event are:

  • Critical
  • Error
  • Warning
  • Information.

    If you do not specify an event severity, the policy applies to events of all severities.

Notifications are recorded in a log, which is stored in the management server database. You can view a table of log entries for notification events. Each log entry is a response to an event generated by the management server.

 To navigate to the event log entries

1. On the main tab bar, click Notification.
2. On the secondary tab bar, click Logs.

   The Notification Logs table contains the log entries.

You can configure a policy to send SMTP e-mails or SNMP traps to specified recipients, such as your personal e-mail account or an SNMP console. You can also configure a policy to run a custom script each time a qualifying event occurs.

  Note   The management server monitors events generated only by the cluster objects that it manages. You cannot write policies for remote management servers.