Setting up alerts for Azure resources is essential for effective cloud management. In a digital landscape where organizations depend on cloud services for scalability and reliability, proactive monitoring is key. Azure alerts provide real-time notifications, helping to quickly identify and resolve potential issues. Here are some key reasons why setting up these alerts is important:

  • Minimize Downtime: Alerts help in promptly addressing issues, enhancing system reliability.
  • Optimize Resource Management: Notifications about anomalies, like usage spikes, allow for informed decision-making.
  • Improve Operational Efficiency: Ensures compliance with service-level agreements and maintains a seamless user experience.
  • Foster Resilience: Supports a culture of continuous improvement and resilience in cloud operations.

The problem with setting up all these alerts is that if you have a lot of resources, that could leave you with many alerts for just one resource, let alone all your other resources that you’ll need to create and tune alerts for. Even in smaller environments, this could leave you with 100s of alerts. What is an engineer to do?

Introducing Azure Monitor Baseline Alerts (AMBA)

AMBA provides Azure Monitor metric, log, activity, and service health alerts for a variety of resources with baseline thresholds recommended by Microsoft. They break out their practices into 3 distinct sections including Azure Resources, Patterns/Scenarios, and Visualizations.

The Azure Resources section provides a breakdown of different resources and recommended alerts that can be deployed as an Azure Policy, ARM template, or Bicep.

The Patterns/Scenarios can deploy alerts in bulk that can follow specific patterns such as Artificial Intelligence, Azure Landing Zones, or even more specialized workloads such as Azure Virtual Desktop. While the documentation shows information for a bunch of solutions, the three most complete at the time of writing are the Azure Landing Zone, Azure Virtual Desktop, and Azure VMware Solution.

The Visualizations section provides documentation on utilization tools such as Azure Managed Grafana and Azure Workbooks. Of course you can use your own desired visualization tools with AMBA.

Deploying Patterns

For the purposes of this blog post, we’ll be focusing on AMBA Patterns/Scenarios as that’s probably the most common scenario. Let’s dive a little deeper into the Azure Landing Zone pattern! Don’t worry though as the core concepts will be the same for any of the other patterns.

First things first, we gotta get our pre-requisites in order. Make sure you have a Microsoft Entra ID Tenant. Next, deploy an ALZ Management group hierarchy following the Azure landing zone design areas and conceptual architecture documentation. Create a subscription specifically for deploying alerts through policies. To manage access, set up a Deployment Identity with Owner permissions to the pseudo root management group. If you prefer manual deployment, install and configure Bicep, and don’t forget to register the necessary Azure resource providers (Microsoft.AlertsManagement and Microsoft.Insights) on all relevant subscriptions. Lastly, if you want to monitor virtual machines, enable VM Insights for the specific machines you wish to monitor.

Once the pre-requisites are taken care of, there’s a few ways to go about deploying AMBA to your environment.

Method 1: Deploy via the Azure Portal. This method is certainly the easiest as everything is presented right through the Portal. You are even able to edit the template and parameters.

Method 2: Deploy with Azure CLI. This is going to involve setting up your template and parameters file and doing an az deployment mg create command.

Method 3: Deploy with Azure PowerShell. This is exactly the same as Deploy with Azure CLI, except using the Az PowerShell module.

Method 4: Deploy with GitHub Actions or Azure DevOps Pipelines or your favorite CI/CD tool. This is very similar to Methods 2 and 3, except using Azure CLI on an agent/runner.

Method 5: Because you can deploy these policies/initiatives using templates and parameter files, you can also setup the Azure Policy with Bicep or other IaC toolings.

Don’t expect alerts to be created immediately! Azure Policies can take up to 24 hours to run. If the environment is a greenfield, then policies will create the alert rules, action groups, etc. for those new resources. However, if the environment is a brownfield and you already have pre-existing resources, then the policies will mark the resources as non-compliant. This can be fixed in the portal or the Start-AMBA-ALZ-Remediation.ps1 script can be ran.

Clean Up on Aisle 5

As part of a resource’s lifecycle, the resource may be deleted over time. If developing Azure resources with IaC such as Bicep or Terraform and using AMBA alerts, it is likely you won’t have those alerts as part of the IaC. If a resource is deleted, the alert will still exist in the Azure Monitor service. To clean up these alerts, you can use the AMBA clean up documentation. Important to note that the cleanup script should be thoroughly tested in a non-production environment before running in production. It is provided “AS IS” by Microsoft

The Start-AMBA-ALZ-Maintenance script has the capabilities to:

cleanItems Parameter

Description

Amba-Alz

Remove ALL resources deployed by the AMBA-ALZ pattern (alerts, policy assignments, policy initiatives, policy definitions, and policy assignment role assignments)

Deployments

Remove ONLY the deployment entries of AMBA-ALZ happening at the pseudo root management group level

NotificationAssets

Remove ONLY the notification assets (AGs and APRs) deployed by AMBA-ALZ

OldNotificationAssets

Remove ONLY the notification assets (AGs and APRs) deployed by AMBA-ALZ version older than 2024-03-01

Alerts

Remove ONLY alerts deployed by the AMBA-ALZ pattern

PolicyAssignments

Remove ONLY policy assignments and role assignment created by the AMBA-ALZ deployment

PolicyDefinitions

Remove ONLY policy definitions and policy initiatives created by the AMBA-ALZ deployment

OrphanedAlerts

Remove ONLY orphaned alerts deployed by the AMBA-ALZ pattern

The parameter `-pseudoRootManagementGroup` is a required string that specifies the name of the pseudo root management group where the AMBA-ALZ pattern was deployed.

There is also support for the `-WhatIf` parameter to see what would be happen without making any changes as well as a `-Confirm` parameter which can be set to `$true` or `$false`, where `$false` will not prompt for confirmation.

Execute the script without asking for confirmation before taking the configured action: `./Start-AMBA-ALZ-Maintenance.ps1 -pseudoRootManagementGroup $pseudoRootManagementGroup -cleanItems Amba-Alz -Confirm:$false`

Privacy

If privacy is a concern, you’ll be happy to hear that there is a way to disable telemetry tracking using a parameter called telemetryOptOut. An example provided is in the alzArm.json file, you can find:

"telemetryOptOut": {
    "type": "string",
    "defaultValue": "No",
    "allowedValues": [
       "Yes",
       "No"
    ],
    "metadata": {
        "description": "The customer usage identifier used for telemetry purposes. The default value of False enables telemetry. The value of True disables telemetry."
    }
}

More details can be found in AMBA’s disable telemetry tracking page.

Conclusion

Utilizing AMBA is truly a time saving endeavor that can get you started down the right path of properly monitoring your Azure infrastructure. By simplifying the alert creation process by providing predefined templates and best practices, AMBA makes it easier and faster to set up alerts compared to traditional methods, in the Portal or even with IaC. Adopting a disciplined approach to AMBA management can significantly contribute to the robustness and resilience of your cloud operations if your goal is to stick with Microsoft’s Azure Monitor capabilities. Additional resources regarding AMBA can be found in their very thorough documentation here.

If AMBA isn’t your cup of tea and you’re interested in other monitoring solutions, we have additional blog posts such as: