Planning an Azure Monitor Alerts strategy

Azure users know first-hand how Microsoft has steadily expanded its public cloud services. Customers have gained the flexibility to take on broader and deeper use cases across more workloads, but they must also transition from traditional systems monitoring strategies to keep control of their architecture.

Responsibility for monitoring and managing Azure services, partly by Microsoft and partly by customers, can present as chaotic and balkanized. Into the fray, Microsoft has created a range of tooling to address IT needs. Azure Monitor, Application Insights, Activity Logs, Diagnostics, Network Watcher, Metrics, Policy, Security Center and others provide data back to system administrators, but that list itself presents even more challenges. Azure Monitor Alerts aims to centralize those alerts to create improved visibility and reduce alert fatigue.  

Azure experts spoke with MSDW and shared recommendations on how to put these alerts to good use.

Metric alerts vs. log alerts

Before users begin planning an alert strategy, it's important to understand the types of alerts and what an organization needs to alert on. Steve Hunter, a senior consultant at Avanade explained the two main categories of alerts:

Metric alerts evaluate time-series data and trigger notifications when a defined criterium is met.  These alerts can be as simple as a single metric or as complex as a combination of multi-dimensional metrics from various sources.  Metric alerts are beneficial when conditions of a healthy system are understood and can be codified.  For example, if CPU utilization of a system exceeds 70% there is likely, or soon to be, an impact on performance.  Metric-based monitors are essential but they require past issues to determine healthy thresholds.  This is a continual evolution, when new issues appear new monitors are added – but this creates the potential for alert noise if monitors are not carefully designed.

By contrast: