Configure monitoring in VM insights guest health using data collection rules (preview)

• 10/15/2020
• 10 minutes to read
• • b

VM insights guest health allows you to view the health of a virtual machine as defined by a set of performance measurements that are sampled at regular intervals. This article describes how you can modify default monitoring across multiple virtual machines using data collection rules.

Monitors

The health state of a virtual machine is determined by the rollup of health from each of its monitors. There are two types of monitors in VM insights guest health as shown in the following table.

The set of monitors used by VM insights guest health and their configuration can't be directly changed. You can create overrides though which modify the behavior of the default configuration. Overrides are defined in data collection rules. You can create multiple data collection rules each containing multiple overrides to achieve your required monitoring configuration.

Monitor properties

The following table describes the properties that can be configured on each monitor.

Default configuration

The following table lists the default configuration for each monitor. This default configuration can't be directly changed, but you can define overrides that will modify the monitor configuration for certain virtual machines.

Overrides

An override changes one ore more properties of a monitor. For example, an override could disable a monitor that's enabled by default, define warning criteria for the monitor, or modify the monitor's critical threshold.

Overrides are defined in a Data Collection Rule (DCR). You can create multiple DCRs with different sets of overrides and apply them to multiple virtual machines. You apply a DCR to a virtual machine by creating an association as described in Configure data collection for the Azure Monitor agent (preview).

Multiple overrides

A single monitor may have multiple overrides. If the overrides define different properties, then the resulting configuration is a combination of all the overrides.

For example, the memory|available monitor does not specify a warning threshold or enable alerting by default. Consider the following overrides applied to this monitor:

• Override 1 defines alertConfiguration.isEnabled property value as true
• Override 2 defines monitorConfiguration.warningCondition with with a threshold condition of < 250.

The resulting configuration would be a monitor that goes into a warning health state when less than 250Mb of memory is available and creates Severity 2 alert and also goes into critical health state when less than 100Mb of available memory is available and creates alert Severity 1 (or changes existing alert from severity 2 to 1 if it already existed).

If two overrides define the same property on the same monitor, one value will take precedence. Overrides will be applied based on their scope, from the most general to the most specific. This means that the most specific overrides will have the greatest chance of being applied. The specific order is as follows:

1. Global
2. Subscription
3. Resource group
4. Virtual machine.

If multiple overrides at the same scope level define the same property on the same monitor, then they are applied in the order they appear in the DCR. If the overrides are in different DCRs, then they are applied in alphabetical order of the DCR resource IDs.

Data collection rule configuration

The JSON elements in the data collection rule that define overrides are described in the following sections. A complete example is provided in Sample data collection rule.

extensions structure

Guest health is implemented as an extension to the Azure Monitor agent, so overrides are defined in the extensions element of the data collection rule.

"extensions": [
    {
        "name": "Microsoft-VMInsights-Health",
        "streams": [
            "Microsoft-HealthStateChange"
        ],
        "extensionName": "HealthExtension",
        "extensionSettings": {   }
    }
]

extensionSettings element

Contains settings for the extension.

"extensionSettings": {
    "schemaVersion": "1.0",
    "contentVersion": "",
    "healthRuleOverrides": [ ]
}

healthRulesOverrides element

Contains one or more healthRuleOverride elements that each define an override.

"healthRuleOverrides": [
    {
        "scopes": [ ],
        "monitors": [ ],
        "monitorConfiguration": { },
        "alertConfiguration": {  },
        "isEnabled": true|false
    }
]

scopes element

Each overrides has one or more scopes the define which virtual machines the override should be applied to. The scope can be a subscription, resource group, or a single virtual machine. Even if the override is in a DCR associated to a particular virtual machine, it's only applied to that virtual machine if the virtual machine is within one of the scopes of the override. This allows you to broadly associate a smaller number of DCRs to a set of VMs but provide granular control over the assignment of each override within the DCR itself. You may want to create small set of DCRs and association those to a set of virtual machines using policy while specifying health monitor overrides for different subsets of those virtual machines using scopes element.

The following table shows examples of different scopes.

monitors element

List of one or more strings that define which monitors in health hierarchy will receive this override. Each element can be a monitor name or type name that matches one or more monitors that will receive this override.

"monitors": [
    "<monitor name>"
 ],

The following table lists the current available monitor names.

alertConfiguration element

Specifies whether an alert should be created from the monitor.

"alertConfiguration": {
    "isEnabled": true|false
}

monitorConfiguration element

Applies only to unit monitors. Defines the configuration for the monitor including health states and how they are calculated.

Parameters define the algorithm to calculate the metric value to compare against thresholds. Instead of acting on one sample of data from underlying metric, the monitor evaluates several metric samples received within window from evaluation time and lookbackSec ago. All samples received within that timeframe are considered and if count of samples is greater than maxSamples, older samples above maxSamples are ignored.

In case there are less samples in lookback interval than minSamples, monitor will switch in to Unknown health state indicating there isn’t enough data to make informed decision about health of underlying metrics. If greater number of samples then minSamples is available, an aggregation function specified by evaluationType parameter us run over the set to calculate a single value.

"monitorConfiguration": {
        "evaluationType" : "<type-of-evaluation>",
        "lookbackSecs": <lookback-number-of-seconds>,
        "evaluationFrequencySecs": <evaluation-frequency-number-of-seconds>,
        "minSamples": <minimum-samples>,
        "maxSamples": <maximum-samples>,
        "warningCondition": {  },
        "criticalCondition": {  }
    }
}

warningCondition element

Defines threshold and comparison logic for the warning condition. If this element isn't included, then the monitor will never switch to the warning health state.

"warningCondition": {
    "isEnabled": true|false,
    "operator": "<comparison-operator>",
    "threshold": <threshold-value>
},

criticalCondition element

Defines threshold and comparison logic for the critical condition. If this element isn't included, then the monitor will never switch to the critical health state.

"criticalCondition": {
    "isEnabled": true|false,
    "operator": "<comparison-operator>",
    "threshold": <threshold-value>
},

Sample data collection rule

For a sample data collection rule enabling guest monitoring, see Enable a virtual machine using Resource Manager template.

Next steps

• Read more about data collection rules.