Frends offers monitoring rules which inspect the execution of a set of Processes as a whole and focuses on the data being processed instead on the technical success of the Process.
This means that instead of trying to figure out if a Process has been successful in for example delivering orders to their destination inside a single Process, you can gather up all the orders from a set period of time and see if enough have been delivered.
You create rules to check for given Promoted variable values in the database during a time interval, e.g. if the count of "OrderId" variable values ever goes under 100 within an hour, or if there are any instances of a "PROC-e234-ERROR" variable promoted.
You define rules per Environment. So, in order to create a new monitoring rule, go to the Monitoring rules view, and choose Create new. The editor will open, which will allow you to define the rule in more detail.
Examples
Alert if number of orders is less than expected
The following configuration shows a common rule of sending an alert if not as many orders have been processed as you would have expected:
 |
 |
Things to note:
You can define the rule to be active only on selected days and between selected times. Make sure to set the time zone correctly in this case.
Alert if step takes longer than expected
This is a rule for alerting if something has happened, in this case a Process step taking longer than expected:
Things to note:
The filter on variable values means that only those instances with a value greater than expected will be counted. NOTE: when using greater or less than operators in the filter, make sure the actual promoted value is numeric!
As any instance not filtered away is an error, we want to send an alert if there are 1 or more instances.
The time interval is set to 5 minutes, so any errors will be sent without too much delay. In this case, e.g. an error reported at 12:34 would get alerted at 12:50 by default (wait one full time interval i.e. 5 minutes + 10 minutes, see below).
Rule processing
The rules are processed by the message processing service periodically, once per minute. The processor will generate the value series for the individual rule, which is then used to check if the rule is met or an alert should be sent.
The rules can have a max time interval of 24 hours. The time intervals always start from the start of the hour or day.
NOTE: The daily interval also means that you need to align your time intervals accordingly. If you have e.g. a time interval of 10 hours, it will be only evaluated every day at 10:00 and 20:00, meaning any values for the time period from 20:01 to 0:00 will not be monitored. Therefore, make sure your time intervals nicely fit full hours / days. E.g. use time intervals like 5 minutes, 10 minutes or 1 hours.
The monitoring rule series are generated and checked when a one full rule interval (e.g. 1 hour) with an additional 10 minute delay by default. This delay is there to make sure all Process log messages and promoted variables for the time interval, to the data store, so the generated series are valid, and no false alerts are sent. You can change the default limits from the messaging service config file, by changing the MonitoringRuleAlertProcessingDelay value.
Rules are also only evaluated starting from the time the rule was originally created. Therefore, right after creating a rule, you may need to wait a while before you get any alerts shown.
Delivering alerts with email
Monitoring rule alerts can be delivered to multiple email addresses via SMTP. The receiving email addresses are configured per Environment. Email recipients are added as a comma separated string in the monitoring rule view.
If an alert for a rule has already been sent there will by default be a one hour waiting period before new alerts are sent for the same rule. This is to prevent excessive spamming of email inboxes.
You can configure the SMTP server and other settings during deployment in the deploymentSettings.json file. The settings are passed from there to the messaging service config file.
The alert emails are sent with the alert@frendsapp.com sender address. You can configure this from the messaging service config file by setting the appSetting AlertEmailSenderAddress.
Triggering Processes from a rule
In Frends 5.4 you can trigger one or more Processes when a Monitoring rule alerts.
To make a Process triggerable you need to flip the "Use for Monitoring Rules" switch in a Manual Trigger:
After this, in the Process you now have access to the triggered Monitoring rule info from #trigger.data.monitoringRule:
The data in #trigger.data.monitoringRule refers to the Monitoring rule which triggered this Process.
So what data can I get?
#trigger.data.monitoringRule is an object which contains:
string[] | #trigger.data.monitoringRule.emailRecipients | A list with all the email recipients |
string | #trigger.data.monitoringRule.error | The error message why the Monitoring rule alerted |
string | #trigger.data.monitoringRule.expectedValue | The Monitoring rules' expected value |
string | #trigger.data.monitoringRule.name | The Monitoring rules' name |
new []<{ string processGuid, string agentGroupName }> | #trigger.data.monitoringRule.triggeredProcesses | A list of triggered Processes |
string | #trigger.data.monitoringRule.variableName | The promoted variables' name |
Editing the Monitoring rule to trigger the Process
Edit your Monitoring rule at Triggered Processes and type in the name of the Process you want to be triggered. Save changes and that should be it.
