Configurer les alertes Resource Health à l’aide de modèles Resource Manager
Cet article vous montre comment créer par programmation des alertes de journal d’activité Resource Health en utilisant des modèles Azure Resource Manager et Azure PowerShell.
Azure Resource Health vous tient informé de l’état d’intégrité actuel et précédent de vos ressources Azure. Les alertes Azure Resource Health peuvent vous signaler quasiment en temps réel tout changement de l’état d’intégrité des ressources. La création par programmation d’alertes Resource Health permet aux utilisateurs de créer et personnaliser leurs alertes en bloc.
Remarque
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.
Prérequis
Pour suivre les instructions de cette page, vous devez configurer quelques éléments au préalable :
- Installez le module Azure PowerShell.
- Créez ou réutilisez un groupe d’actions configuré pour la notification.
Instructions
Utilisez PowerShell pour vous connecter à Azure avec votre compte et sélectionnez l’abonnement avec lequel vous souhaitez interagir.
Login-AzAccount Select-AzSubscription -Subscription <subscriptionId>Remarque
La commande
Get-AzSubscriptionvous permet de répertorier les abonnements auxquels vous avez accès.Recherchez et enregistrez l’ID Azure Resource Manager complet associé à votre groupe d’actions.
(Get-AzActionGroup -ResourceGroupName <resourceGroup> -Name <actionGroup>).IdCréez et enregistrez un modèle Resource Manager en tant que resourcehealthalert.json pour les alertes Resource Health. Consultez Options de modèle Resource Manager pour les alertes Resource Health.
Créez un déploiement Azure Resource Manager en tirant parti de ce modèle.
New-AzResourceGroupDeployment -Name ExampleDeployment -ResourceGroupName <resourceGroup> -TemplateFile <path\to\resourcehealthalert.json>Vous êtes invité à taper le nom de l’alerte ainsi que l’ID de la ressource du groupe d’actions copié plus tôt :
Supply values for the following parameters: (Type !? for Help.) activityLogAlertName: <Alert Name> actionGroupResourceId: /subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/microsoft.insights/actionGroups/<actionGroup>Si le processus s’est déroulé correctement, vous recevez une confirmation dans PowerShell.
DeploymentName : ExampleDeployment ResourceGroupName : <resourceGroup> ProvisioningState : Succeeded Timestamp : 11/8/2017 2:32:00 AM Mode : Incremental TemplateLink : Parameters : Name Type Value =============== ========= ========== activityLogAlertName String <Alert Name> activityLogAlertEnabled Bool True actionGroupResourceId String /... Outputs : DeploymentDebugLogLevel :
Si vous prévoyez d’automatiser entièrement ce processus, modifiez simplement le modèle Resource Manager afin qu’il ne demande pas d’entrer les valeurs à l’étape 5.
Options de modèle Resource Manager pour les alertes Resource Health
Vous pouvez utiliser ce modèle simple comme base pour créer vos alertes Resource Health. Ce modèle fonctionne comme écrit et vous inscrit pour recevoir les alertes pour tous les nouveaux événements d’intégrité des ressources qui se déclenchent sur l’ensemble des ressources d’un abonnement.
Remarque
À la fin de cet article, nous avons également inclus un modèle d’alerte plus complexe qui présente un rapport signal/bruit pour les alertes Resource Health plus élevé que ce modèle.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"activityLogAlertName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Activity log alert."
}
},
"actionGroupResourceId": {
"type": "string",
"metadata": {
"description": "Resource Id for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlertName')]",
"location": "Global",
"properties": {
"enabled": true,
"scopes": [
"[subscription().id]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "ResourceHealth"
},
{
"field": "status",
"equals": "Active"
}
]
},
"actions": {
"actionGroups":
[
{
"actionGroupId": "[parameters('actionGroupResourceId')]"
}
]
}
}
}
]
}
Toutefois, une alerte avec une large étendue comme celle-ci n’est généralement pas recommandée. Dans la section suivante, vous découvrez comment réduire l’étendue de cette alerte pour vous concentrer sur les événements qui vous intéressent.
Paramétrage de l’étendue d’alerte
Les alertes Resource Health peuvent être configurées pour superviser les événements selon trois étendues différentes :
- Niveau d'abonnement
- Niveau du groupe de ressources
- Au niveau de la ressource
Ce modèle d’alerte est configuré au niveau de l’abonnement, mais si vous préférez configurer l’alerte pour recevoir uniquement les notifications ayant trait à des ressources spécifiques, ou aux ressources d’un groupe de ressources donné, il vous suffit de modifier la section scopes dans ce modèle.
Pour une étendue au niveau d’un groupe de ressources, la section scopes doit se présenter de la façon suivante :
"scopes": [
"/subscriptions/<subscription id>/resourcegroups/<resource group>"
],
Pour une étendue au niveau d’une ressource, la section scopes doit se présenter de la façon suivante :
"scopes": [
"/subscriptions/<subscription id>/resourcegroups/<resource group>/providers/<resource>"
],
Par exemple : "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/myRG/providers/microsoft.compute/virtualmachines/myVm"
Remarque
Pour obtenir cette chaîne, accédez au Portail Azure et recherchez l’URL lors de l’affichage de votre ressource Azure.
Paramétrage des types de ressources qui vous alertent
Les alertes au niveau de l’abonnement ou du groupe de ressources peuvent provenir de différents types de ressources. Si vous souhaitez limiter les alertes afin qu’elles proviennent uniquement d’un sous-ensemble spécifique de types de ressources, vous pouvez le configurer dans la section condition du modèle de la manière suivante :
"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "resourceType",
"equals": "MICROSOFT.COMPUTE/VIRTUALMACHINES",
"containsAny": null
},
{
"field": "resourceType",
"equals": "MICROSOFT.STORAGE/STORAGEACCOUNTS",
"containsAny": null
},
...
]
}
]
},
Ici, nous utilisons le wrapper anyOf pour mettre l’alerte Resource Health en correspondance avec les conditions que nous avons spécifiées, afin d’activer les alertes ciblant des types de ressources spécifiques.
Paramétrage des événements Resource Health qui vous alertent
Quand des ressources rencontrent un événement d’intégrité, elles peuvent passer par une série de phases représentant l’état de l’événement d’intégrité : Active, In Progress, Updated et Resolved.
Si vous souhaitez recevoir une notification uniquement quand une ressource n’est plus intègre, configurez l’alerte pour être averti uniquement quand status a la valeur Active. Toutefois, si vous voulez également être informé aux autres phases, vous pouvez les ajouter comme ceci :
"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "status",
"equals": "Active"
},
{
"field": "status",
"equals": "In Progress"
},
{
"field": "status",
"equals": "Resolved"
},
{
"field": "status",
"equals": "Updated"
}
]
}
]
}
Pour recevoir des notifications correspondant aux quatre phases des événements d’intégrité, vous pouvez supprimer la totalité de cette condition pour recevoir l’alerte, quelle que soit la valeur de la propriété status.
Remarque
Chaque section « anyOf » ne doit contenir qu’une seule valeur de type de champ.
Paramétrage des alertes Resource Health pour éviter les événements « Unknown »
Azure Resource Health peut signaler l’intégrité actuelle de vos ressources en les monitorant en continu à l’aide d’exécuteurs de tests. Les états d’intégrité pertinents signalés sont les suivants : Available, Unavailable et Degraded. Toutefois, dans les cas où l’exécuteur et la ressource Azure ne peuvent pas communiquer, un état d’intégrité Unknown est signalé pour la ressource, ce qui est considéré comme un événement d’intégrité « Actif ».
Cependant, quand une ressource signale Unknown, la raison probable est que son état d’intégrité n’a pas changé depuis le dernier rapport exact. Si vous souhaitez supprimer les alertes sur des événements Unknown, vous pouvez spécifier cette logique dans le modèle :
"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "properties.currentHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field": "properties.currentHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field": "properties.currentHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field": "properties.previousHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field": "properties.previousHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field": "properties.previousHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
]
},
Dans cet exemple, nous recevons une notification uniquement pour les événements dont l’état d’intégrité actuel et précédent n’est pas Unknown. Ce changement peut s’avérer utile si vos alertes sont envoyées directement vers votre téléphone mobile ou votre e-mail.
Il est possible que les propriétés currentHealthStatus et previousHealthStatus soient nulles pour certains événements. Par exemple, quand un événement mis à jour se produit, il est probable que l’état d’intégrité de la ressource n’a pas changé depuis le dernier rapport, seules d’autres informations d’événement sont disponibles (par exemple, la cause). Par conséquent, l’utilisation de la clause dans cet exemple peut entraîner l’absence du déclenchement de certaines alertes, car les valeurs properties.currentHealthStatus et properties.previousHealthStatus sont définies sur une valeur nulle.
Ajustement de l’alerte pour éviter les événements initiés par les utilisateurs
Les événements Resource Health peuvent être déclenchés par des événements lancés par la plateforme ou par l’utilisateur. Il est parfois préférable d’envoyer une notification uniquement quand l’événement d’intégrité est déclenché par la plateforme Azure.
La configuration de votre alerte pour filtrer ces types d’événements est simple :
"condition": {
"allOf": [
...,
{
"field": "properties.cause",
"equals": "PlatformInitiated",
"containsAny": null
}
]
}
Il est possible que le champ de cause ait une valeur nulle dans certains événements. Autrement dit, une transition de l’intégrité a lieu (par exemple, de disponible à non disponible) et l’événement est journalisé immédiatement pour empêcher les retards de notification. Par conséquent, l’utilisation de la clause dans cet exemple peut empêcher le déclenchement d’une alerte, car la propriété properties.cause sera définie sur une valeur nulle.
Modèle d’alerte Resource Health complet
Voici un exemple de modèle configuré en utilisant les ajustements décrits dans la section précédente pour maximiser le ratio signal/bruit. N’oubliez pas les mises en garde indiquées ci-dessus qui précisent que les propriétés currentHealthStatus, previousHealthStatus et clause peuvent avoir une valeur nulle dans certains événements.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"activityLogAlertName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Activity log alert."
}
},
"actionGroupResourceId": {
"type": "string",
"metadata": {
"description": "Resource Id for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlertName')]",
"location": "Global",
"properties": {
"enabled": true,
"scopes": [
"[subscription().id]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "ResourceHealth",
"containsAny": null
},
{
"anyOf": [
{
"field": "properties.currentHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field": "properties.currentHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field": "properties.currentHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field": "properties.previousHealthStatus",
"equals": "Available",
"containsAny": null
},
{
"field": "properties.previousHealthStatus",
"equals": "Unavailable",
"containsAny": null
},
{
"field": "properties.previousHealthStatus",
"equals": "Degraded",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field": "properties.cause",
"equals": "PlatformInitiated",
"containsAny": null
}
]
},
{
"anyOf": [
{
"field": "status",
"equals": "Active",
"containsAny": null
},
{
"field": "status",
"equals": "Resolved",
"containsAny": null
},
{
"field": "status",
"equals": "In Progress",
"containsAny": null
},
{
"field": "status",
"equals": "Updated",
"containsAny": null
}
]
}
]
},
"actions": {
"actionGroups": [
{
"actionGroupId": "[parameters('actionGroupResourceId')]"
}
]
}
}
}
]
}
Toutefois, vous savez mieux que quiconque les configurations les plus appropriées pour vous. Utilisez donc les outils présentés dans cette documentation pour créer votre propre personnalisation.
Étapes suivantes
En savoir plus sur Resource Health :
- Vue d’ensemble d’Azure Resource Health
- Types de ressource et contrôles d’intégrité disponibles par le biais d’Azure Resource Health
Créer des alertes Service Health :