Scale action groups and suppress notifications for Azure alerts

In Azure Monitor, defining what to monitor while configuring alerts can be challenging. Customers need to be capable of defining when actions and notifications should trigger for their alerts, and more importantly, when they shouldn’t. The action rules feature for Azure Monitor, available in preview, allows you to define actions for your alerts at scale, and allows you to suppress alerts for scenarios such as maintenance windows.

Let’s take a closer look at how action rules (preview) can help you in your monitoring setup!

Defining actions at scale

Previously you could define what action groups trigger for your alerts while defining an alert rule. However, the actions that get triggered, whether it is an email that is sent or a ticket created in a ticketing tool, are usually associated with resource on which the alert is generated rather than the individual alert rule.

For example, for all alerts generated on the virtual machine contosoVM, I would typically want the following.

◈ The same email address to be notified (e.g. contosoITteam@contoso.com)

◈ Tickets to be created in the same ITSM tool

While you could define a single action group such as contosoAG and associate it with each and every alert rule authored on contosoVM, wouldn’t it be easier if you could easily associate contosoAG for every alert generated on contosoVM, without any additional configuration?

That’s precisely what action rules (preview) allow you to do. They allow you to define an action group to trigger for all alerts generated on the defined scope, this could be a subscription, resource group, or resource so that you no longer have to define them for individual alert rules!

Suppressing notifications for your alerts

There are often many scenarios where it would be useful to suppress the notifications generated by your alerts. This could be a planned maintenance window or even the suppression of notifications during non-business hours. You could possibly do this by disabling each and every alert rule individually, with complicated logic that accounts for time windows and recurrence patterns or you can get all of this out of the box by using action rules (preview).

Working on the same principle as before, action rules (preview) also allow you to define the suppression of actions and notifications for all alerts generated on a defined scope, which could be a subscription, resource group, or resource, while the underlying alert rules would continue to monitor. Furthermore, you have the capability to configure both the period as well as recurrence for the suppression, all out of the box! With this you could easily setup notification suppression based on your business requirements, which could be anything from suppression for all weekends such as a maintenance window, to suppression between 5pm – 9am everyday or normal business hours.

Filters for more flexibility

While you can easily define action rules (preview) to either author actions at scale or suppress them, action rules come with additional knobs and levers in the form of filters that allow you to fine tune what specific subset of your alerts the action rule acts on.

For example, going back to the example of suppressing notifications during non-business hours. Perhaps you might still want to receive notifications if there is an alert with severity zero or one, while the rest are suppressed. In such a scenario, I can define a severity filter as part of my action rule, which defines that the rule does not apply to alerts with severity of zero or one, and thus only applies to rules with severity of two, three or four.

Similarly, there are additional filters that provide even more granular definitions from the description of the alert to string matching within the alert’s payload

Continue reading

Create alerts to proactively monitor your data factory pipelines

Data integration is complex and helps organizations combine data and business processes in hybrid data environments. The increase in volume, variety, and velocity of data has led to delays in monitoring and reacting to issues. Organizations want to reduce the risk of data integration activity failures and the impact it cause to other downstream processes. Manual approaches to monitoring data integration projects are inefficient and time consuming. As a result, organizations want to have automated processes to monitor and manage data integration projects to remove inefficiencies and catch issues before they affect the entire system. Organizations can now improve operational productivity by creating alerts on data integration events (success/failure) and proactively monitor with Azure Data Factory.

To get started, simply navigate to the Monitor tab in your data factory, select Alerts & Metrics, and then select New Alert Rule.

Select the target data factory metric for which you want to be alerted.

Then, configure the alert logic. You can specify various filters such as activity name, pipeline name, activity type, and failure type for the raised alerts. You can also specify the alert logic conditions and the evaluation criteria.

Finally, configure how you want to be alerted. Different mechanisms such email, SMS, voice, and push notifications are supported.

Creating alerts will ensure 24/7 monitoring of your data integration projects and make sure that you are notified of issues before they potentially corrupt your data or affect downstream processes. This helps your organizations to be more agile and increase confidence in your overall data integration processes. This ultimately results in increasing overall productivity in your organizations, and guarantee that you deliver on your SLAs.

Continue reading

Exciting advances in Azure Alerts – From better alert management to Smart Groups

We are excited to announce preview of three new features in Azure Monitor that let you enumerate alerts at scale across log, metric or activity log alerts, filter alerts across subscriptions, manage alert states, look at alert instance specific details, and troubleshoot issues faster using SmartGroups that automatically group related alerts. These features continue to enhance the unified alerts configuration experience announced earlier this year. We look forward to your feedback to refine the functionality further.

The new alert enumeration experience and API allows observing alerts across Azure deployments. Alerts across multiple subscriptions can be queried and pivoted on severity, signal types, resource type, and more allowing a performant and easy summary-to-drill down experience. The new enumeration experience also supports multi-select filtering on any relevant dimension, allowing for example, looking up alerts across a set of resource groups or specific resource types.

Alert state management provides users a way to change the state of the alert to reflect the current situation of the issue in their environment. Currently three alert states are supported – New, Acknowledged, and Closed.

Alert states are separate from the monitoring condition, which is updated by the underlying monitoring service that detected the issue. Monitoring condition supports two values – fired and resolved.

The history of both monitor condition and alert state changes, as well as the details of the event such as target resource uri, alert rule, monitor condition, and link to query for log alerts, are captured in the payload of the alert to aid in triaging and auditing.

Smart Groups are system generated alerts that encapsulate many related alerts to reduce alert noise and help in mitigating events faster. These Smart Groups are automatically created using machine learning algorithms looking for similarity and co-occurrence patterns among alerts originating from a monitor service (e.g. LA or Platform). Smart Groups have the same properties as an individual alert such as user defined states or history. For an operator, smart groups significantly reduce the number of alerts to analyze by focusing on only a handful of groups. For example, if % CPU on several virtual machines in a subscription simultaneously spikes leading to many individual alerts, and if such alerts have occurred together anytime in the past, these alerts will likely be grouped into a single Smart Group, suggesting a potential common root cause. This technology has gone through extensive testing against hyperscale Azure services with very good results.

Continue reading