Configuring email subscriptions

Use the Notifications tab in System Management to subscribe to email notifications, or to change or remove an existing subscription.

The labels ALL, PARTIAL or NONE indicate whether that user is subscribed to all possible types of messages, only some messages, or no messages.

You must have Control permissions for the System Management interface in order to add or edit subscriptions. Learn more about these permissions in User Access Levels.

Adding an email subscription

• Type the email address in the email field, and click Add.
• The displayed check boxes indicate the type of message that the user is subscribed to. By default, all check boxes are selected.
  • Unexpected change in instance/component status (that changes the system status)
  • Manual maintenance mode
  • Manual failover begin & complete
  • Manual component stop/start/restart
  • (VHT Callback version 8.11.2 or later) License file expiration
• If this user does not want to receive a certain type of message, clear the corresponding check box.
• Click OK.

Changing or removing an email subscription

• Click the email address or Edit button .
• The four displayed check boxes indicate the type of message that the user is subscribed to.
  • Unexpected change in instance/component status (that changes the system status)
  • Manual maintenance mode
  • Manual failover begin & complete
  • Manual component stop/start/restart
  • (VHT Callback version 8.11.2 or later) License file expiration
• Select or clear the appropriate check boxes and click Update.
• To remove this email address, click Remove user and Yes to confirm.

Note:

Email changes must be saved (or canceled) before another email can be edited.

Email format

The general format of an email notification message contains two parts.

The upper part of the message contains:

• E-mail Title - VHT Notification: Components started successfully for example
• System Status - Operational for example
• Action - Requested action (Component Started for example)
• Triggered By - Name of the user requesting the action (not used in Lost Heartbeat messages)
• From - IP address of the node requesting the action (not used in Lost Heartbeat messages)
• Time Initiated (UTC) - UTC time the request was sent
• Time Completed (UTC) - UTC time the request completed

The lower part of the message contains:

• Affected node and its mode
• Resulting condition
• List of affected components (and their status)

Refer to the following sections for example email notification messages.

Email message conditions

When properly configured, System Management sends email messages in the following scenarios:

• Maintenance mode entered or exited
• Manual failovers
• Manual component state changes
• Unexpected change in instance or component status that changes the system status
• Unexpected loss of connection of a component to the network
• License file is about to or has already expired

Maintenance mode entered or exited in Standalone systems:

• Any time the core instance successfully enters or exits Maintenance mode within the configured timeout period, an email stating VHT Notification: Successfully entered/exited maintenance mode is sent. This email also shows the resulting condition of the core.
• Any time the core instance fails to completely enter or exit Maintenance mode within the configured timeout period, an email stating VHT Notification: Failed to enter/exit maintenance mode is sent. This email also shows the resulting condition of the core.

Maintenance mode entered or exited in High Availability systems:

• Any time the selected core instance successfully enters Maintenance mode AND the other core instance enters Standalone mode within the configured timeout period, an email stating VHT Notification: Successfully entered maintenance mode is sent. This email also shows the resulting condition of both cores.
• Any time the selected core instance successfully enters Maintenance mode while the other core instance is already in Maintenance mode within the configured timeout period, an email stating VHT Notification: Successfully entered maintenance mode is sent. This email also shows the the resulting condition of both cores.
• Any time the selected core instances fail to successfully enter Maintenance mode OR the other core instances fail to successfully enter Standalone mode (from Backup mode) within the configured timeout period, an email stating VHT Notification: Failed to enter maintenance mode is sent. This email also shows the resulting condition of both cores.
• Any time the selected core instance fails to successfully enter Maintenance mode AND the other core instance is already in Maintenance mode within the configured timeout period, an email stating VHT Notification: Failed to enter maintenance mode is sent. This email also shows the resulting condition of both cores.

Manual failovers

In High Availability systems, manual failovers (using Make Primary option) trigger email notification based on the following criteria:

• Any time the Backup core instance successfully enters Primary mode AND the previous Primary core instance successfully enters Backup mode within the configured timeout period, an email stating VHT Notification: Successfully completed manual failover is sent. This email also shows the resulting condition of both cores.
• Any time the Backup core instance fails to successfully enter Primary mode OR the previous Primary core instance fails to successfully enter Backup mode within the configured timeout period, an email stating VHT Notification: Failed to complete manual failover is sent. This email also shows the resulting condition of both cores.

Manual component state changes

Manual component state changes (from Started to Stopped or Stopped to Restarted for example) trigger email notification based on the following criteria:

• Any time all component state changes initiated in the same action successfully complete within the configured timeout period, an email stating VHT Notification: Components stopped/started/etc. successfully is sent. This email also shows the resulting condition of the core containing the component.
• Any time one or more of the requested component state changes initiated in the same action fail to complete within the specified timeout period, an email stating VHT Notification: Components failed to stop/start/etc. successfully is sent. This email also shows the resulting condition of all instances containing the components.

Unexpected change in instance/component status

Examples of unexpected state changes:

• Component failures and recoveries that cause system state to change to or from Started state
• Instance failures and recoveries that cause system state to change to or from Started state
• Loss and recovery of connection to an instance to the network

Depending on the constantly changing timing issues within any system, email notifications are occasionally not sent or duplicated. Consult the System Management application to verify current system conditions.

Unexpected instance and component state change

• Any time an unexpected component state change causes the system state to change to or from Started, an email is generated.
• Any time an unexpected instance state changes cause the system state to change to or from Started, an email is generated.

These emails also show the resulting condition of the system.

Unexpected loss of connection to an instance

The unexpected loss of connection of an instance to the network triggers email notification based on the following criteria:

• In Standalone systems, any time any instance loses connection to the network, an email stating VHT Notification: Lost connection to instance is sent.
• In High Availability systems, any time a non-core instance loses connection to the network, an email stating VHT Notification: Lost connection to instance is sent. This email also shows the resulting condition of the instance.
• In High Availability systems, any time the core instance in Primary mode loses connection to the network, two emails are sent:
  • The first email is sent immediately, and states that the Primary core instance has failed, and the backup is transitioning to Standalone mode.
• In High Availability systems, any time the core instance in Standalone mode fails, an email stating that connection to the Standalone core instance has failed is sent. This email also shows the resulting condition of both cores.
• In High Availability systems, any time the core instance in Backup mode loses connection to the network, an email stating that connection to the Backup core instance has failed and the Primary core has switched to Standalone is sent.

Unexpected loss of connection to a component

Any time a network unexpectedly loses connection to a component (no component heartbeat is received), the network generates a Lost Heartbeat message. This email also shows the resulting condition of the system.

License file expiration

Depending on how the Configuration > System Settings > Notifications and Alerts > Email Notification Frequency - License Expired and Days Between Emails - License Expiring variables are set, email notification messages are sent prior to or after the current license file expires. The general format of expired, or about to, license file email notification messages contain:

• Email Title - VHT Notification: License file expires in number_of_days days OR License file has expired.
• License File - Name of license file
• Warning - License file is about to expire OR License file has expired
• Time Initiated (UTC) - UTC time the request was sent.
• Explanation text - Your license file will expire in number_of_days days, Callback and other features will stop functioning on UTC time. A new, valid license file is needed to continue functioning when the current license file expires.OR
• Your license file expired on UTC time. Callback and other features are not functioning. A new, valid license file is needed to start the functions again.

Refer to Licensing user interface alerts and email notifications for more information about these variables and how they are set.