Understanding Azure Resource Health for Log Alerts

Azure Resource Health is Azure Monitor feature to track the overall health of different Azure services. It is particularly handy for PaaS and SaaS type of services as those usually get at most metrics and diagnostic logs that you can use to monitor them. The feature is on by default and it is supported by many resource types. For each resource type there are certain checks that are made on intervals and if any of those checks fails resource health will mark the resource as unavailable. These changes in the resource health are logged as Azure Activity log events. In order to monitor for these changes you can use Resource Health alerts which underneath are alerts monitoring for activity log events scoped to Resource Health category events. Recently Azure Monitor introduced support for resource health on Log Alerts. Log alerts use Kusto query language to monitor based on data from Log Analytics workspace. Due to the rich Kusto query language capabilities there is the possibility of providing incorrect query and saving the alert rule without knowing that it will stop working. This is where Resource Health for Log alerts comes in as it will signal you that there is something wrong with your alert rule. There are of course other checks made related to permissions and networking that will also be signal by Resource Health for your Log Alerts. So enabling Resource Health alerts to notify you on problems with your Log Alerts is something you should do in your environment. The purpose of the blog post is to show you how resource health works and hopefully to enable resource health alerts for your Log Alerts. Overall I would strongly advise you to enable it for all supported resources as it does not introduce additional cost.

Continue reading “Understanding Azure Resource Health for Log Alerts”

Azure Log Alert scoped to resource that sends logs to more than one Log Analytics workspace

When you configure diagnostic settings you have the option to configure more than one thus send the logs and metrics to multiple Log Analytics workspaces. At t he same time Log Alert v2 allows you to scope your alerts not only to Log Analytics workspace but also to a specific resource or resource group. When the scope is a resource that is not the Log Analytics workspace or resource group than the Log Alert automatically finds to which workspace the logs are send and uses the data from there. But what happens if you are sending the logs and metrics to more than one Log Analytics workspace?

Continue reading “Azure Log Alert scoped to resource that sends logs to more than one Log Analytics workspace”

Azure Monitor Workspace, Managed Prometheus and Prometheus Alerts via Bicep

Recently Azure Monitor team has introduced Azure Monitor workspace. This is a new resource that is described as "Azure Monitor workspaces will eventually contain all metric data collected by Azure Monitor. Currently, the only data hosted by an Azure Monitor workspace is Prometheus metrics.". So basically this new resource is a store for metrics and in future will also support Azure resource metrics. This is similar to Azure Log Analytics workspace which is store for logs. Of course Azure Log Analytics can also store metrics but Azure Monitor workspace is optimized for the structure of metrics data. We are yet to see full picture of this initiative. Currently Azure Monitor workspace is known also as Azure Monitor managed service for Prometheus (Managed Prometheus). The full documentation on this new feature/service you can find here. As a long time user and expert on Azure Monitor and Log Analytics I wanted to try this feature and test its capabilities. My knowledge on Prometheus and Grafana is very little so I always like to challenge myself with such exercises. This new feature has 3 distinct scenarios:

  • Using Prometheus and Grafana only – you do not have to use Log Analytics and Container Insights
  • Using Prometheus and Grafana along with Log Analytics and Container Insights
  • Use your own Prometheus server and send data to Azure Monitor workspace and visualize it in Grafana. You can use Log Analytics and Container Insights as additional monitoring as well.
Continue reading “Azure Monitor Workspace, Managed Prometheus and Prometheus Alerts via Bicep”

Enable Defender for Cloud Auto provisioning agents via Bicep

Often I see questions around how I can the auto provisioning agents capabilities (now renamed to Settings & monitoring) in Defender for Cloud via API.

Defender for Cloud Settings and Monitoring
Continue reading “Enable Defender for Cloud Auto provisioning agents via Bicep”

Azure Monitor Log Alert V2

Log Alerts have been available in Log Analytics for quite some time. Initially they were available via legacy Log Alert API that was specific for Log Analytics. In order to make Log Alert more native to Azure a new Log Alert API was available. With a few minor features like (custom webhook payload) that API was direct translate from the legacy one offering the same features. Now Azure Monitor team is introducing a new Log Alert that is named Log Alert V2. That new alert is using the same API but with new version. So if you use the API version 2018-04-16 to create Log Alert you are creating v1 and if you use version 2021-08-01 you are creating v2. Log Alert v2 will be generally available probably very soon as I have received e-mail notification containing the following information:

  • any API version like 2021-02-01-preview will be deprecated and replaced by version 2021-08-01
  • billing for Log Alert v2 will start from 30th of November.

This for me signals that before 30th of November or several weeks after the service will be generally available. I am not aware of specific information just the official e-mail notification leads me to these conclusions. The Log Alert v2 has been in preview for a couple of months which I have been testing and providing feedback.

Continue reading “Azure Monitor Log Alert V2”