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 at specified time interval say every 3 minutes. 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, which runs every 3 minutes 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. Only if the voilation persists for time more than this duration, an alert will be triggered. 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 Entities, multiple entities can be associated to a single threshold monitor. Serverless360 has capabilities to monitor the following Azure entities on their state, metric or properties
- Service Bus Queues/ Topics/ Topic subscriptio
- Event Hubs
- Logic Apps
- Function Apps
- Storage Queues/ Blobs/ Files
- API Endpoint
Configure threshold values on enitity properties , Serverless360 permits defining an expected state against current state of the associated entities. In this case, the current state not being the expected state is an voilation. It is possible to monitor the entities 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 entities.
Auto Correct State Based Monitors
An Azure entity’s status plays an important role in the business applications built using them. Consider a scenario where a Service Bus Queue expected 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 should manually modify the status of the entity to the expected state.
It will be good to change the status of the entity 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 entity to the configured Expected state if auto correct is enabled.
This auto correct capability is available for the following Azure entities
- 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 entity 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 entity in a Threshold Monitor.
Enabling Auto Correct
Auto correct for an entity can be enabled while associating the entity to a Threshold Monitor. It can also be edited from the monitoring dashboard of the entity. Refer the following illustration to configure auto correct for entities.
Below is the illustration that depicts how to edit auto correct from the monitoring dashboard.
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.