Templates
AutoAction templates, partially completed policy forms for a triggering condition, are available whenever you create a new AutoAction. The sections in the AutoAction template can be edited based on your preferences.
Note
Refer to AutoAction's limitations.
Template Sections
Policy name, description, and status
The Policy Name is mandatory. Specify a name that reflects the AutoActions' purpose.
The Description is optional. However, you can describe AutoAction's purpose.
The Active check box is automatically selected. Uncheck the box to deactivate the Action. You need not enable the action upon creation. You can always enable it later.
Trigger Conditions
In the Trigger conditions, a Metric, Operator, and Value define a rule, which defines the condition for the AutoAction. You must define at least one trigger condition.
Item | Description |
|---|---|
Metric | Refer to Supported Cluster Metrics for a list and definition of available Metrics. |
Operator | Operators: >, >=, ==, <, and <=. |
Value | Value: any valid numeric value. The default value is 0; If you leave it empty, the AutoAction is triggered constantly. |
Type | Specify the application type for AutoAction. The Type options are:
|
State | Specify the state when the AutoAction condition should be triggered. The State options are: new, new_saving, submitted, accepted, scheduled, allocated, allocatedSaving, launched, running, finishing, finished, killed, failed, undefined, newAny, allocatedAny, pending, and * (all). |
Join Conditions | Specify any of these join conditions: SAME, AND, OR. |
Refine Scope | Click the down arrow For the User and Projects option, you must specify if it affects All, Only, or Except. For example, if you choose User and select:
For Only and Except options, you need to do the following based on the scope that you have selected.
For the Time option, you must specify if it is always or daily. If you select the daily option, you must specify the timezone, start time, and end time during the day. |
Actions | Click the down arrow
|
Multiple rule types are evaluated in conjunction with each other using:
Or, And, or Same
Or and And work as you would expect. See Same Logical Operator for the definition of Same and its implementation.
This template has the Ruleset defined as needed to fulfill the template type, for example, Rogue Contention In Queues (allocated memory). The template highlights the fields you can or should change. You can't delete/add any of the rule types or add/delete rules. You can change the metric, comparison, type, and state if available by using the pull-down menus. If you change the Metric, Type, or State , the template does not perform the selected task, for example, Rogue Contention In Queues (allocated memory). The default value for the metric comparison is 0. You must change the value. Otherwise, the AutoAction constantly triggers. Multiple rule types are Same'd together. See Same Logical Operator for its definition and implementation
The Ruleset initially lists the type of rules available, User, Queue, Cluster, App, or EXPERT RULE. Click the rule type you want to define. Below Add Queue is selected with the options to add rules for metric, type , and state. These options, and only these options, are available for every rule type except the Expert Rule template, which is a text box. You must define at least one rule for each of the rule type selected.
In the example below, Metric and Type are selected for the Queue rule type. You use the pull-down menus to select metric, the comparison operator, type, or state. See above for further information. A second rule, Apps has been added. When multiple rules are selected, you must choose how they are evaluated in conjunction with each other. The default is the Same operator, but you may select Or or And. See Same Logical Operator for the definition of Same and its implementation. Or and And work as you would expect. You can choose up to two rules, e.g., user & user, expert rule & queue, etc.
Click Close to delete a rule type and click trash (
) to delete a specific rule. If you close the rule before saving the AutoActions, your settings are lost.
Options
Define the scope (User, Queue, Cluster, and Application Name), the period in which the AutoAction acts on a violation (Time), and how long/short the violation must occur before the AutoAction takes action (Sustained).
When you select an option, its default is All, except Time which defaults to always, and Sustained Violation , which defaults to none.
When using Create from Template the required option is already checked and uses the default. Any changes you make may cause AutoAction to not perform as expected.
Check the box next to the option's name to select it.
You can narrow the scope of User, Queue, Cluster, and Application Name by using Only or Except. Only applies the rule to only those apps specified, while Except applies them to all but those specified. Use the Transform to specify the names using a regular expression. The following example uses the Application Name in the Except mode with MyApp. You can add more apps by clicking Add Application. Since no regular expression is specified, this option applies to all apps except MyApp. Create from Template defaults to All.
The Time sets the time range and zone during which the AutoAction can be triggered. The AutoAction remains active but doesn't trigger outside the specified time range. The default start and end times are when you define AutoAction with the time zone set to America/Los Angeles. If you don't change the default time, AutoAction can be triggered for only one minute daily. Enter the time directly or click on the clock (
) in the time box. Time is entered in 24-hour time. The end time must be later than the start time.Sustained violation specifies a time violation must occur before the AutoAction is triggered. This allows time for the violator to self-correct and decreases the false positives The default is zero. In other words, all AutoActions are immediately triggered upon the violation, and the specified action is carried out. You can select the minimum or maximum mode. In both cases, the AutoAction must be continually violated.
Minimum sustained mode triggers the action only if this violation was continuously detected for at least the specified period. This suppresses the triggering of violation actions for “on-offs” and metric spikes. These are normal in multi-tenant cluster environments and can return to normal operation independently. If a violation stops before the minimum period, the clock is reset for that app. For instance, if the minimum time is one hour and the app violates the AutoAction for 58 minutes and then returns to normal – no action is taken, and the period for that app resets to 0.
Maximum sustained mode triggers the action only if this violation is continuously detected for less than the specified period. This suppresses the triggering of violations for long-running apps and triggers on AutoAction rule scope on ad hoc short-lived user apps.
Actions
Defines the actions to take when the AutoAction is triggered.
Build Rule and Create from Template, exception for Impala query, you can specify the following actions: Send an email, HTTP Post, Post to Slack, Move App to Queue, and Kill App. Use Build Rule to enter an Expert Action. See Expert Mode for information on defining an action in JSON. You can't kill a Hive, Impala, or Workflow app.
You can choose one or more actions. Check the box to choose that action. If you choose no actions, the UI records the violation and saves the data for the cluster view. The following are all the possible actions; in Create from Template , only actions valid for the template are available.
For Send Email , you must enter at least one recipient. Add more recipients by clicking Add Recipient. You can also specify to include the app owner by selecting the Include Owner radio button.
Note
If you need to send an email notification to the owner of the application who is an LDAP user, configure the additional LDAP properties.
For HTTP post you must enter at least one URL. You can add more URLs by clicking Add URL.
Post to Slack Unravel provides integration with SlackApp allowing you to post information to one or more Slack channels and users. To use this feature, you need a Slack:
Webhook URL: The incoming webhook URL configured in Slack for the channel or user. You can post to multiple webhooks.
Token: The OAuth access token for the SlackApp.
See Slack's Incoming Webhooks for further information on creating/obtaining the above.
Move app to queue or Kill App. You must enter a queue to move the App to.
Warning
The Move App and Kill App are mutually exclusive. If you select both, the Kill App takes precedence, and Move App is ignored. For these to be executed, the scope must:
Have directly caused the rule violation, and Have allocated resources; that is, the app is in allocated or running states. Move App is a non-destructive action that shouldn't affect the cluster performance and its availability to the user; however, we suggest using it cautiously.
Kill App is a destructive action. It can affect the cluster performance and its availability to the users. This option is primarily to kill rogue apps causing contention of cluster resources.
Use Build Rule to enter an action using JSON. See Expert Rules for examples.