Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article vous montre comment créer des alertes de journal d’activité d’intégrité des ressources à l’aide de modèles Azure Resource Manager et d’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 :
- Vous devez installer le module Azure PowerShell.
- Vous devez créer ou réutiliser un groupe d’actions configuré pour vous avertir.
Les 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 Azure Resource Manager pour les alertes d'Azure Resource Health sous
resourcehealthalert.json(voir les détails)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 tout fonctionne correctement, vous obtenez 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 :
Remarque
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 tel quel et vous permet de recevoir des alertes pour tous les événements de santé des ressources nouvellement activés pour toutes les ressources d'un abonnement.
Remarque
En bas de cet article, nous avons inclus un modèle d’alerte plus complexe qui devrait augmenter le rapport signal/bruit pour les alertes Resource Health par rapport à 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')]"
}
]
}
}
}
]
}
Cependant, une alerte aussi large que celle-ci n’est pas recommandée. Découvrez comment nous pouvons réduire la portée de cette alerte pour nous concentrer sur les événements qui nous 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
Le modèle d’alerte est configuré au niveau de l’abonnement, mais si vous souhaitez configurer votre alerte pour vous avertir uniquement de certaines ressources ou des ressources au sein d’un certain groupe de ressources, vous devez simplement modifier la scopes section du modèle indiqué.
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.
Ajuster les 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 de santé pertinents sont les suivants : « Disponible », « Indisponible » et « Dégradé ». Toutefois, dans les cas où l’exécuteur de série de tests 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é « Active ».
Toutefois, lorsqu'une ressource indique « Inconnu », il est probable que son état de santé soit le même depuis le dernier rapport exact. Si vous souhaitez supprimer les alertes sur des événements « Unknown », spécifiez 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 ne notifions que les événements pour lesquels l'état de santé actuel et précédent n'indique pas « Inconnu ». 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 null dans certains événements. Par exemple, lorsqu’un événement Mis à jour se produit, il est probable que l’état d’intégrité de la ressource soit le même depuis le dernier rapport. Seules les autres informations sur l'événement sont disponibles (par exemple, la cause). Par conséquent, l’utilisation de cette clause peut entraîner la non-déclenchement d’alertes, car les valeurs properties.currentHealthStatus et properties.previousHealthStatus sont définies sur null.
Ajustement de l’alerte pour éviter les événements initiés par les utilisateurs
Les événements Resource Health sont déclenchés par les événements initiés par la plateforme et les événements initiés par l’utilisateur. Il peut être judicieux d’envoyer une notification uniquement lorsque la plateforme Azure provoque l’événement de santé.
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 soit nul 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 cette clause peut empêcher le déclenchement d’une alerte, car la valeur de la propriété properties.cause est définie sur null.
Modèle d’alerte Resource Health complet
Lorsque vous utilisez les différents réglages décrits dans la section précédente, voici un exemple de modèle configuré pour maximiser le rapport signal/bruit. Gardez à l'esprit les avertissements indiquant que les valeurs des propriétés *currentHealthStatus*, *previousHealthStatus* et *cause* peuvent être nulles 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 :