-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
update README with new template variables
- Loading branch information
Showing
1 changed file
with
12 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -388,7 +388,15 @@ This factory returns an instance of `AlertInstance`. The alert instance class ha | |
|
||
There needs to be a way to map alert context into action parameters. For this, we started off by adding template support. Any string within the `params` of an alert saved object's `actions` will be processed as a template and can inject context or state values. | ||
|
||
When an alert instance executes, the first argument is the `group` of actions to execute and the second is the context the alert exposes to templates. We iterate through each action params attributes recursively and render templates if they are a string. Templates have access to the `context` (provided by second argument of `.scheduleActions(...)` on an alert instance) and the alert instance's `state` (provided by the most recent `replaceState` call on an alert instance) as well as `alertId` and `alertInstanceId`. | ||
When an alert instance executes, the first argument is the `group` of actions to execute and the second is the context the alert exposes to templates. We iterate through each action params attributes recursively and render templates if they are a string. Templates have access to the following "variables": | ||
|
||
- `context` - provided by second argument of `.scheduleActions(...)` on an alert instance | ||
- `state` - the alert instance's `state` provided by the most recent `replaceState` call on an alert instance | ||
- `alertId` - the id of the alert | ||
- `alertInstanceId` - the alert instance id | ||
- `alertName` - the name of the alert | ||
- `spaceId` - the id of the space the alert exists in | ||
- `tags` - the tags set in the alert | ||
|
||
## Examples | ||
|
||
|
@@ -410,6 +418,7 @@ Below is an example of an alert that takes advantage of templating: | |
{ | ||
... | ||
id: "123", | ||
name: "cpu alert", | ||
actions: [ | ||
{ | ||
"group": "default", | ||
|
@@ -418,7 +427,7 @@ Below is an example of an alert that takes advantage of templating: | |
"from": "[email protected]", | ||
"to": ["[email protected]"], | ||
"subject": "A notification about {{context.server}}" | ||
"body": "The server {{context.server}} has a CPU usage of {{state.cpuUsage}}%. This message for {{alertInstanceId}} was created by the alert {{alertId}}." | ||
"body": "The server {{context.server}} has a CPU usage of {{state.cpuUsage}}%. This message for {{alertInstanceId}} was created by the alert {{alertId}} {{alertName}}." | ||
} | ||
} | ||
] | ||
|
@@ -432,7 +441,7 @@ The templating system will take the alert and alert type as described above and | |
"from": "[email protected]", | ||
"to": ["[email protected]"], | ||
"subject": "A notification about server_1" | ||
"body": "The server server_1 has a CPU usage of 80%. This message for server_1 was created by the alert 123" | ||
"body": "The server server_1 has a CPU usage of 80%. This message for server_1 was created by the alert 123 cpu alert" | ||
} | ||
``` | ||
|
||
|