Azure Monitor introduces Dynamic Thresholds also for Log Search Rules, revolutionizing how you set up log and monitor search alerts. Say goodbye to manual threshold tuning and hello to intelligent, adaptable monitoring.

Here’s why dynamic thresholds are a game-changer:

Automatic Calibration: Dynamic thresholds calculate the right alert levels for you. They adjust as your system evolves, ensuring timely alerts without false positives.
Smart Learning: Dynamic thresholds analyzing historical data, learning patterns and trends. They adapt to your application’s unique behavior, whether it’s daily spikes or weekly lulls.
Alerting At Scale: Create a single rule for any multi dimensions alert. Dynamic thresholds define different alert threshold band for every dimension combination.
Effortless Setup: Just enable dynamic thresholds, no need to have a specific knowledge of the data to setup alert thresholds.

Dynamic thresholds empower you to stay proactive, minimize downtime, and keep your systems running smoothly.

Use Cases

Here you can find use cases for dynamic threshold:

Use Case: Monitoring CPU Behavior in Virtual Machines

Background: Users can now calculate guest VM metrics using the Perf table in Log Analytics, enabling the creation of a single alert rule for all your VMs across different regions using dimensions. Previously, customers could only set up dynamic threshold metric alerts for host CPU usage.

Goal Statement: The primary goal of this use case is to monitor the CPU behavior within virtual machines (VMs) and detect irregular patterns that may indicate performance issues.

Scenario definitions:

Problem Identification:

The team wants to ensure optimal performance and identify any CPU-related issues promptly.

Use Case Description:

The CPU utilization data is being collected from each VM.
The system using the model analyses the CPU behavior over time, looking for deviations from the expected pattern.
Deviations may include sudden spikes, prolonged high usage, or unexpected drops in CPU utilization.

Trigger:

Azure monitor triggers a log search alert once the CPU is higher than the regular patterns, which means that the alert is out of the upper boundaries.

Benefits:

Early detection of CPU-related problems helps prevent performance degradation.
Proactive monitoring ensures efficient resource utilization.
Improved system stability and responsiveness.
In Perf table there is an option to monitor other “Counter Value” instead of CPU. Examples can be found here.

ARM template example: {
“$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“parameters”: {
“scheduledqueryrules_PerfDemoRule_name”: {
“defaultValue”: “PerfDemoRule”,
“type”: “String”
},
“workspaces_PerfDemoWorkspace_externalid”: {
“defaultValue”: “/subscriptions/XXXX-XXXX-XXXX-XXXX/resourceGroups/XXXX/providers/Microsoft.OperationalInsights/workspaces/PerfDemoWorkspace”,
“type”: “String”
}
},
“variables”: {},
“resources”: [
{
“type”: “microsoft.insights/scheduledqueryrules”,
“apiVersion”: “2024-01-01-preview”,
“name”: “[parameters(‘scheduledqueryrules_PerfDemoRule_name’)]”,
“location”: “eastus2”,
“properties”: {
“displayName”: “[parameters(‘scheduledqueryrules_PerfDemoRule_name’)]”,
“severity”: 3,
“enabled”: true,
“evaluationFrequency”: “PT5M”,
“scopes”: [
“[parameters(‘workspaces_PerfDemoWorkspace_externalid’)]”
],
“targetResourceTypes”: [
“Microsoft.Compute/virtualMachines”
],
“windowSize”: “PT5M”,
“criteria”: {
“allOf”: [
{
“query”: “Perf | where CounterName == “Available MBytes” and InstanceName == “_Total” | project TimeGenerated, CounterValue, Computer,_ResourceIdn”,
“timeAggregation”: “Average”,
“metricMeasureColumn”: “CounterValue”,
“dimensions”: [],
“resourceIdColumn”: “_ResourceId”,
“operator”: “GreaterThan”,
“alertSensitivity”: “High”,
“criterionType”: “DynamicThresholdCriterion”,
“failingPeriods”: {
“numberOfEvaluationPeriods”: 1,
“minFailingPeriodsToAlert”: 1
}
}
]
},
“autoMitigate”: false
}
}
]
}

Use Case: Monitor Behavior Network in Application Insight Virtual Machines

Goal Statement: The primary goal of this use case is to monitor the network write behavior within virtual machines (VMs) and detect irregular patterns that may indicate performance issues or anomalies.

Scenario Definitions:

Problem Identification:

The team aims to ensure optimal performance and promptly identify any network write-related issues within their VMs.

Use Case Description:

The system periodically collects network write data from each VM using dynamic thresholds models.
The models analyze the network write behavior over time, specifically looking for deviations from the expected pattern.
Deviations may include sudden spikes, prolonged high usage, or unexpected drops in network write activity.

Trigger:

Azure monitor triggers a log search alert when network write behavior exceeds the regular patterns, indicating that the alert is beyond the upper boundaries.

Benefits:

Early detection of network write-related problems helps prevent performance degradation.
Proactive monitoring ensures efficient resource utilization.
Improved system stability and responsiveness.

ARM template example:  

{
“$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“parameters”: {
“scheduledqueryrules_LogSearch1ActionGroup_name”: {
“defaultValue”: “LogSearch1ActionGroup”,
“type”: “String”
},
“components_ACME_Portal_externalid”: {
“defaultValue”: “/subscriptions/XXXX-XXXX-XXXX-XXXX/resourceGroups/XXXX-XXXX/microsoft.insights/components/ACME-Portal”,
“type”: “String”
}
},
“variables”: {},
“resources”: [
{
“type”: “microsoft.insights/scheduledqueryrules”,
“apiVersion”: “2024-01-01-preview”,
“name”: “[parameters(‘scheduledqueryrules_LogSearch1ActionGroup_name’)]”,
“location”: “eastus”,
“properties”: {
“displayName”: “[parameters(‘scheduledqueryrules_LogSearch1ActionGroup_name’)]”,
“severity”: 3,
“enabled”: true,
“evaluationFrequency”: “PT5M”,
“scopes”: [
“[parameters(‘components_ACME_Portal_externalid’)]”
],
“targetResourceTypes”: [
“microsoft.insights/components”
],
“windowSize”: “PT30M”,
“criteria”: {
“allOf”: [
{
“query”: “InsightsMetrics| where Origin == “vm.azm.ms”| where Namespace == “Network” and Name == “WriteBytesPerSecond”| extend NetworkInterface=tostring(todynamic(Tags)[“vm.azm.ms/networkDeviceId”])|summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, NetworkInterface,

“timeAggregation”: “Average”,
“metricMeasureColumn”: “AggregatedValue”,
“dimensions”:[
{
“name”: “Computer”,
“operator”: “Include”,
“values”: “[[parameters(‘computersToInclude’)]”
},
{
“name”: “NetworkInterface”,
“operator”: “Include”,
“values”: “[[parameters(‘networkInterfacesToInclude’)]”
}
],
“operator”: “GreaterThan”,
“alertSensitivity”: “High”,
“criterionType”: “DynamicThresholdCriterion”,
“resourceIdColumn”: “_ResourceId”,
“failingPeriods”: {
“numberOfEvaluationPeriods”: 1,
“minFailingPeriodsToAlert”: 1
}
}
]
},
“autoMitigate”: false
}
}
]
}

How to create Dynamic Threshold ARM template

You can easily change a log search rule (with a static threshold) template to be a dynamic one by making the following changes:

In the “allOf” condition:

Addition of “criterionType”: “DynamicThresholdCriterion”
Addition of “alertSensitivity”.
Removal of “threshold” parameter.

Update api-version in template to be “2024-01-01-preview”

Summary

In the world of monitoring and alerting, precision matters. Enter Dynamic Thresholds—a game-changer for Log Search Rules. Here’s why they’re essential:

Anomaly Detection:

Dynamic thresholds rely on advanced algorithms to calculate expected performance ranges based on historical data.
They identify anomalies—sudden spikes, drops, or irregular patterns—that warrant attention.

Efficiency Boost:

No more manual threshold tuning. Dynamic thresholds adapt automatically.
Scale alerts across hundreds of dimension combinations series with a single rule.

Stay Ahead:

Early detection prevents performance degradation.
Proactively manage resource utilization for improved stability and responsiveness.

Dynamic thresholds empower you to be proactive, responsive, and precise.

​Microsoft Tech Community – Latest Blogs –Read More 

Hi,

I have a sharepoint choice-column for selecting a country based on the iso-code (US,BE,NL,ES,…..)

I used json column formatting to display the countryflag :

​Hi,I have a sharepoint choice-column for selecting a country based on the iso-code (US,BE,NL,ES,…..) I used json column formatting to display the countryflag :{“$schema”: “https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json”,”elmType”: “div”,”children”: [{“elmType”: “img”,”attributes”: {“src”: “=(‘https://flagcdn.com/w20/’ + toLowerCase(@currentField) + ‘.png’)”}},{“elmType”: “span”,”txtContent”: “@currentField”}]} Problem :when I edit the column : flags are shown.when display in view mode : the flags are not shown, only the two digitcode !! When i look at the source code, something very strange : there are two “src”-parameter in the img-tag ! <img src=”” data-untrusted-src=”https://flagcdn.com/w20/es.png”> Any help will be appreciated         Read More

​<img src="