The Iguana X IguanaX notification system is designed to make it simple to integrate into whatever whichever notification system is appropriate for your organization. For instance, generating notifications from Iguana in applications like Slack, Microsoft Teams, ServiceNow, etc. or simply sending an email alert.
This way, the platform is future proofed and flexible to deal with changing requirements for best practices with regards to how to raise production issues.
Iguana X IguanaX does this by checking the notification rules every 60 seconds and invoking a notifier notifications component if a notification rule is triggered. This notifier notifications component can be configured to send to any appropriate destination.
i.e. Condition triggered → Generates log → Notifier Component → Calls Slack.
...
Configuring Notifications:
Choose a Notifier Component:
You can use any component you wish to send notifications. For example, you can modify the Email Sender, Slack Notifier Adapter, or /wiki/spaces/CSHC/pages/2843410461 to use as your Notifier component.
Create Notification Rules:
Notification rules are created by specifying four criteria:
...
Click Edit to add/modify notification rules.
Expand | ||
---|---|---|
| ||
Type | Example | Description |
Wildcard | * | Apply to all components. |
#dev* | Apply to components containing #dev followed by 0 or more characters | |
OR | #prod #dev | Apply to components which contain either #prod or #dev tags. |
AND | “#prod #dev“ | Apply to components which contain both #prod and #dev tags. |
Negation | -#prod | Apply to all components without the #prod tag. |
“#prod -#dev” | Apply to all components with the #prod tag AND without #dev. |
Expand | ||
---|---|---|
| ||
Conditions are the notification rule criteria. If a condition is met, a log is generated and sent to the notifier component. There are four types of conditions used to trigger notifications:
The Log Contains rule is the most flexible type of notification rule as you can leverage default logs generated by Iguana or custom log messages invoked from the Translator (see Custom Logging). The pattern can use strings (ex. component stopped) or regex patterns. To use regex, simply enclose the expression in slash characters /<regex>/. |
Expand | ||
---|---|---|
| ||
You can mark a notification rule as low, medium or high based on the criticality of the alert. This value can be mapped to any external incident tracking system of your choice. |
Expand | ||
---|---|---|
| ||
You can set a limit to the number of log triggers generated to control the number of notifications sent within a 1 hour period. The default is set to 6 notifications per hour, the maximum can be set to 60 notifications per hour. |
When a notification rule is triggered a log message is generated for the set notifier component. The log message is a JSON object containing the notification details such as component guid, the criteria (condition triggered), the threshold set and priority rating.
Code Block | ||
---|---|---|
| ||
[{"component":"Custom_ByvlKqIG5aLpSZ","criteria":"error_count","priority":"low","threshold":"1"}] |
Test your Notification Rules:
After creating a notification rule, it can be quickly tested by using the provided testing links.
Use the click here link to have Iguana check your notification rules.
Click on the logs link to view the log created by your notification rules.
Note: you can test all conditions expect for the “Log Contains” conditions as this is only triggered on newly generated logs. You can test this out by interacting with your components directly.
...
| |
Notification rules can be applied to one or more components using either simple pattern matching expressions or regular expressions to match component Tags. See https://interfaceware.atlassian.net/wiki/spaces/IXB/pages/2883551240/Using+the+Notifications for tips on setting up notification rules and creating matching rules. |
Here you will see the list of your Notification Rules. For detailed instructions on setting up the rules and the 4 conditions, visit Using Notifications.