This problem is probably as old as there are monitoring tools on the market. “How can I exclude legitimately deallocated VMs from alerting” is a question that I’ve heard many times.

Where most monitoring tools such as System Center Operations Manager have tooling around the concept of maintenance mode where all alerts are suppressed for a duration of time; Azure Monitor has no provisions at this point.

This problem is probably as old as there are monitoring tools on the market. “How can I exclude legitimately deallocated VMs from alerting” is a question that I’ve heard many times.

Where most monitoring tools such as System Center Operations Manager have tooling around the concept of maintenance mode where all alerts are suppressed for a duration of time; Azure Monitor has no provisions at this point.

This problem is probably as old as there are monitoring tools on the market. “How can I exclude legitimately deallocated VMs from alerting” is a question that I’ve heard many times.

Where most monitoring tools such as System Center Operations Manager have tooling around the concept of maintenance mode where all alerts are suppressed for a duration of time; Azure Monitor has no provisions at this point.

I’ve had a question today coming from a colleague that has no prior experience in System Center Operations Manager (SCOM). He wanted to know how data flows from connected agents (regardless of Windows or Linux) to Log Analytics and subsequently to Azure Security Center.

Every once in a while you might need to create an alert which runs a Log Analytics or Application Insights query. When designing the alert you need to define some attributes: the query, the time period, the frequency and the threshold.

A customer of mine had the following rule configured:

It was his expectation that this rule would be triggered when in the last five minutes at some point more that 200 requests/s were being made to the App Service. Unfortunately this is not the case. The rule will sum the number of requests for the last five minutes and if that number is > 200 the rule will trigger.

The Microsoft Monitoring Agent is able to send data to more than one workspace at the same time. Unfortunately only a single workspace at a time can be configured through the Azure Portal.

You can either manually access the agents and configure it yourself through the Control Panel or use some kind of automation. The following PowerShell DSC configuration which can be used with Azure Automation DSC and/or PowerShell DSC downloads the appropriate agent, installs it and configures workspaces defined in the document:

Security is top of mind for most Azure customers. To have peace of mind when it comes to security for assets running on Azure, Microsoft continuously works to improve on the security recommendations Azure Security Center provides:

It just has become easier to manage Azure Security Center at scale. While not all aspects of Azure Security Center can be automated yet Microsoft just released updated Swagger definitions for working with Azure Security Center. This includes an updated documentation where you can directly try requests to the API against your tenants you have access to.

In a time before cross-resource queries were possible the Application Insights Connector would copy data from Application Insights to a Log Analytics workspace. With the emergence of cross-resource queries the duplication of data is not required anymore as queries can be sent to both (or even more) entities at the same time in real time.