Event Actions Editor
Event Actions Editor
What is it?
The new Event Actions Editor (EAE) is a visual tool designed to replace the current text-based editing system for defining actions which run in response to event conditions. It provides a structured interface for composing event actions via event policies, script definitions, action targets, escalation policies and more.
Features
Drag and drop ordering
Numeric ordering is no longer displayed, and policies can be dragged and dropped via the yellow vertical grip to the left of each policy. Upon save, policies and nested policies will be re-keyed numerically in steps of 10 based on the order defined in the EAE.
Policy names
Policies can have a COMMENT field which the new EAE uses specifically for the "Name" of the policy. If not present the visually displayed name will be the full IF conditional, which can be harder to read than a short descriptive name.
Condition syntax, suggestions, and autocomplete
The condition editor is not a normal input field and contains some code-editor-like functionality. Certain operators and names ("node", "event") are syntax highlighted for clarity. This can be expanded upon in the future.
The EAE also presents auto-completeable suggestions for common attribute of node. and event. These can be expanded upon easily, and can be dynamic (such as any tags defined in other actions).
To assist the user, when the expression =~ is typed, this will autocomplete to =~ qr{} to encourage the user to use this style of regex.
When the Condition field is empty and gains focus, the dropdown of top level suggestions (event, node) will be presented.
Policy nesting / converting to nested
By default a top level policy contains a list of actions, however policies can be nested to 1 level of depth. Nested policies are identical to top level policies except they can only contain actions (not further nested policies), meaning they can be named, reordered and validated.
A top level policy containing actions can be converted into a nested policy by clicking "Convert to nested". This create a nested policy for each existing action, with a condition of "event.any" and containing just that action.
Action composition
Actions are composed by adding a new action of the chosen type. Many action types have parameters which can be changed (such as the chosen script, or the tag to apply). These can be edited inline or deleted, with a clear indication of the order in which these actions will run.
Validation
Policies can be invalid for a number of reasons such as:
Condition is empty, or contains invalid syntax (syntax checking functionality is basic at the moment)
A policy action contains invalid parameters.
A policy contains invalid nested policies.
These validation errors are clearly indicated inline, and validation messages (if present) can be expanded at the top of the policy:
Escalation Policies
Condition editing
Escalation conditions are based on priority comparison, time frame, and days of the week. These are set visually within the Escalation section of the EAE:
Delayed action composition
Escalation "delayed actions" (or escalation step threshold) are defined similarly to standard policy actions, but grouped by the delay:
Validation
Similar to standard policies, any actions with validation errors are clearly indicated and shown as validation messages against the escalation policy itself.
Scripts, Message, Syslog, NMISSyslog and Log targets
Argument suggestions and multiple arguments in scripts
As script arguments can contain event. and node. tokens which will be replaced, autocompletion is enabled for these fields.
New arguments are added on new lines when hitting enter, and empty lines can be deleted with backspace.
Validation and uniqueness
Each of these sections will also show validation messages for any invalid fields.
As these entries often relate back to policy actions (a script must exist to be chosen as a script action), if a script, message or log target (or escalation policy) is deleted or renamed then any policies containing a reference to that item will be invalidated.
The names of these items must also be unique:
Global validation
The configuration can not be saved if any components are invalid.
If, for example, a policy contains an invalid action, then this will also be indicated against the tab for that section, and the save button will be disabled:
File loading errors
As the user has previously been editing the configuration file manually, it's possible that the file contains invalid syntax, structure or content. In this scenario a best effort is made to direct the user to the source of the issue:
More commonly there can be typos in action names. In this case the configuration will load, but will show invalid actions which can be cleared up:
Contextual help
The “Help” sidebar has been incorporated into the new editor in order to show help based on context and user action. This help is also “sticky” positioned so as to be always in the viewport if the user has to scroll many policies.
Each section of the editor (Policy, Escalation etc.) will show help specific to that section at the top:
Each action type can also be selected, which will show help content contextual to the action type:
Help is also shown based on the context of the condition editor, for event. and node. attribute information and regular expressions: