- 18 Dec 2020
- 5 Minutes to read
- Print
- DarkLight
- PDF
Threshold Monitor
- Updated on 18 Dec 2020
- 5 Minutes to read
- Print
- DarkLight
- PDF
When to choose a Threshold Monitor?
Consider an Ecommerce business scenario, where any new orders from the Ecommerce website is being pushed in a Service Bus Queue. There is a Logic App that looks for any new messages in the Service Bus Queue . Whenever a new message is found in the Service Bus Queue the Logic App picks it up for processing. The Service Bus Queue is configured with an Time To Live as 5 minutes. If the Logic App, does not pick up the Service Bus message for processing, the message would get dead lettered once its Time To Live expires. The monitoring requirement here is, to alert the stakeholders whenever the Logic App state is not Enabled or when the Service Bus Queues dead letter count remains greater than '0' for more than 10 minutes. It is also required to alert only when the voilation occurs.
The right choice of Serverless360 monitor to meet the above requirement is the Threshold Monitor. This article would serve as a guide to configure a Threshold Monitor to fulfill the above mentioned monitoring requirement.
Configuring a Threshold Monitor
Configuring a threshold monitor in Serverless360 involves the following steps.
- Create/ Edit a Threshold Monitor, in every Composite Application created, by default a threshold monitor will be present. However you can create as many number of threshold monitors as per your requirement.
- Define the Threshold Monitor, edit the threshold monitor configuration to define voilation tolerance duration, the monitor will tolerate the violation for this duration. Define the number of alerts you would like to recieve in case of voilation, this would prevent spamming. It is also possible to define the days of a week on which you would expect the monitor to execute. Enabling 'Notify On Success' will send out an alert when the voilation recovers.
- Define the Notification Channels, for the threshold monitor to share the alerts. Turn on those notification channels from the list of configured channels through which this threshold monitor is ecpected to send alert on
Below is an illustration that can serve as a guide to configure a threshold monitor.
Associate Resources, multiple resources can be associated to a single threshold monitor. Serverless360 has capabilities to monitor the following Azure resources on their state, metric or properties
- Service Bus Queues/ Topics/ Topic subscriptio
- Relays
- Event Hubs
- Logic Apps
- Function Apps
- Storage Queues/ Blobs/ Files
- API Endpoint
Configure threshold values on resource properties , Serverless360 permits defining an expected state against current state of the associated resources. In this case, the current state not being the expected state is an voilation. It is possible to monitor the resources on the value of their properties and metrics. In this case, the warning threshold and error threshold can be configured to generate an appropriate warning or error monitoring status.
Below is an illustration that can serve as a guide to configure warning and error threshold values on metrics or properties of the associated resources.
Auto Correct State Based Monitors
An Azure resource's status plays an important role in the business applications built using them. Consider a scenario where a Service Bus Queue expected to be in Active state to accept the messages sent to it. This is a pre-requisite for the receivers to process the messages. This keeps the business going.
There could be scenarios when the Queue is not Active due to various reasons. Any such occasion needs to be detected to restore the business. This can be monitored using the Threshold monitors of Serverless360. Whenever there is a violation in the Queue state for a specified violation persistence duration an alert will be sent to the configured Notification Channels. The recipient of the alert was manually modifying the status of the resource to the expected state.
It will be good to change the status of the resource to the Expected state in addition to the alerts sent whenever there is a violation. This can be achieved using the auto correct capability. The monitoring service of Serverless360 will automatically change the status of the resource to the configured Expected state if auto correct is enabled.
This auto correct capability is available for the following Azure resources
- Service Bus Queues
- Service Bus Topics and Topic Subscriptions
- Web Apps
- Logic Apps
- Azure Function Apps
- API Management Service
Maximum Retry Count
The monitoring service of Serverless360 will try to change the status of the monitored resource to the expected state whenever there is a violation. If the state is not changed to the required state, the monitoring service will retry to change the state in the next minute. The maximum number of retries can be configured while enabling auto correct for an resource in a Threshold Monitor.
Enabling Auto Correct
Auto correct for an resource can be enabled while associating the resource to a Threshold Monitor. It can also be edited from the monitoring dashboard of the resource. Refer the following illustration to configure auto correct for resources.
Below is the illustration that depicts how to edit auto correct from the monitoring dashboard.
Alert Settings
Get notified whenever there is an auto correct success or failure, it is required to enable the Alert on auto correct option in the Threshold monitor configuration. If this is not enabled, the down alert for a monitor will have the auto correct status if auto correct has occurred before the number of alerts has reached the maximum alerts per violation limit.
Reset Threshold monitor
Threshold monitors will not trigger any alerts after the specified Notification Count per violation has been reached. This arrangement is to prevent spaming. The monitor should be reset to start sending notifications again, which is usually done after addressing the issue.
Auto-reset Threshold monitor
Threshold monitors can now be configured to auto-reset by specifying the frequency when the monitor can auto-reset after it reaches the specified Notification Count per violation.