Alert_escalations

New

Define the following variables for each alert escalation:

• Name - A short nickname of the alert escalation. Note: You can have multiple alert escalations with the same name, but be associated with different deployments.
• Description - A more detailed description of the alert escalation's purpose and how to use it.
• Deployment - Select a specific deployment where you will be able to select the alert escalation or make it selectable for all deployments. (Default: -all deployments-) You can create multiple Alert Escalations (with the same name) to create slightly modified escalations that are specifically designed for a particular deployment so that the same ServerTemplate can be used across multiple deployments (e.g. production, QA, development).

Index

An alert escalation defines the action or set of actions to be taken when specified alert conditions are met. Unlike alerts which are specific to a Server, ServerTemplate, or Server Array, Alert Escalations can be designated to a specific Deployment or made available for use across all Deployments.

An alert must be enabled on a server in order for the server to monitor for a condition and call an Alert Escalation. Alert conditions are evaluated every minute. When an alert that is tied to an Alert Escalation is triggered, the actions of the associated escalation will be executed until the alert condition no longer exists or it's disabled. You can also override an Alert Escalation by creating one with the same name in order to override the account-wide escalation with one that is deployment-specific.

Action Buttons

• New - Create a new Alert Escalation.

List of supported actions inside an Alert Escalation:

• send_email - Send email to one or multiple recipients.
• reboot_server - Reboot the server instance generating the alert.
• relaunch_server - Relaunch the server generating the alert (this terminates the current instance and launches a fresh instance).
• run_right_script - Run a RightScript on the server instance generating the alert.
• vote_grow_array - Vote to grow a server array attached to the deployment in which the alerting server is running. (This option will soon be deprecated. Use Voting Tags instead.)
• vote_shrink_array - Vote to shrink a server array attached to the deployment in which the alerting server is running. (This option will soon be deprecated. Use Voting Tags instead.)

Note: The "vote to grow/shrink array" options will soon be deprecated. Autoscaling is now performed using voter tags.

- -

Show

View information about the alert escalation.

Action Buttons

• Clone - Clone the Alert Escalation. A version number will be appended to the name. For example, cloning an escalation named "Test Relaunch" will result in an escalation named "Test Relaunch v1"
• Delete - Delete the Alert Escalation. You will be prompted for confirmation. If you delete an alert escalation that is still being referenced by an alert specification, the alert specification will use the "default" alert escalation when an alert is triggered even though the alert specification still references a deleted alert escalation.

Actions tab

The Actions tab shows a breakdown of the action(s) that will be taken when an alert is triggered and the escalation is executed. Actions will be executed in sequential order until the triggered alert condition no longer exists. At that point, everything is reset. If the same alert is triggered again, the escalation will start to execute its actions from the beginning of its list. When you add actions, you have the ability to repeat the action every 'n' minutes or wait before the next action is executed (escalate after 'n' minutes). For example, you may want to keep sending your SysAdmin email every 10 min and only escalate to the 'scale up' action after 30 min, which would give him 30 min to investigate the deployment before autoscaling can take place.

If you add multiple actions, you can define whether an action should be "added" to the prior action or "replace" the prior action. You cannot change the order of the listed actions. You must simply delete and create new actions.

The supported actions are:

• send_email - Send email to one or multiple recipients.
• reboot_server - Reboot the server generating the alert.
• relaunch_server - Relaunch the server generating the alert (this terminates the current instance and launches a fresh instance).
• run_right_script- Run a RightScript on the server generating the alert.
• vote_grow_array - The server is voting to grow or 'scale-up' by launching additional servers into the server array that's attached to the deployment. It is only a vote; not a trigger to launch servers. Additional servers will not be launched unless enough servers are voting for the 'vote_grow_array' action. The server array's scaling parameters will ultimately determine when to scale (e.g. >51% are voting) and how to scale (e.g. Launch '2' new servers into the array). Note: The array must be active (enabled) in order for any scaling to take place.
• vote_shrink_array - The server is voting to shrink or 'scale-down' by terminating underutilized servers from the array that's attached to the deployment. It is only a vote; not a trigger to terminate servers. Underutilized servers will not be terminated unless enough servers are voting for the 'vote_shrink_array' action. The server array's scaling parameters will ultimately determine when to scale (e.g. >51% are voting) and how to scale (e.g. Terminate '1' server from the array). Note: The array must be active (enabled) in order for any scaling to take place.

Info tab

Under the Info tab, you can edit the description of the escalation or specify which deployment(s) will be able to use the escalation. An alert escalation can be made available only to one specific deployment or to all deployments of your account. (Default: -all deployments-)

Changes tab

The Changes tab shows a history log of all changes to the alert escalation.