Préparer les applications logiques et les runbooks pour la migration des règles d’alerte classiques
Notes
Comme précédemment annoncé, les alertes classiques dans Azure Monitor sont mises hors service pour les utilisateurs du cloud public, avec une utilisation limitée jusqu’au 31 mai 2021. Les alertes classiques pour le cloud Azure Government et Microsoft Azure géré par 21Vianet seront mises hors service le 29 février 2024.
Si vous choisissez de migrer volontairement vos règles d’alerte classiques vers de nouvelles règles d’alerte, n’oubliez pas qu’il existe certaines différences entre les deux systèmes. Cet article décrit ces différences et explique comment préparer la modification.
Modifications d'API
Les API qui créent et gèrent les règles d’alerte classiques (microsoft.insights/alertrules) diffèrent des API qui créent et gèrent les nouvelles alertes de métrique (microsoft.insights/metricalerts). Si vous créez et gérez actuellement des règles d’alerte classiques par programmation, mettez à jour vos scripts de déploiement pour utiliser les nouvelles API.
Le tableau suivant référence les interfaces de programmation pour les alertes classiques et les nouvelles alertes :
| Type de script de déploiement | Alertes classiques | Nouvelles alertes de métrique |
|---|---|---|
| API REST | microsoft.insights/alertrules | microsoft.insights/metricalerts |
| Azure CLI | az monitor alert |
az monitor metrics alert |
| PowerShell | Référence | Référence |
| Modèle Azure Resource Manager | Pour les alertes classiques | Pour les nouvelles alertes de métrique |
Modifications de charge utile de notification
Le format de charge utile de notification est légèrement différent pour les règles d’alerte classiques et les nouvelles alertes de métrique. Si vous avez des règles d’alerte classiques avec des actions webhook, logic app ou runbook, vous devez mettre à jour les cibles pour accepter le nouveau format de charge utile.
Utilisez le tableau suivant pour mapper les champs de charge utile de webhook du format classique vers le nouveau format :
| Type de point de terminaison de notification | Alertes classiques | Nouvelles alertes de métrique |
|---|---|---|
| L’alerte a-t-elle été activée ou résolue ? | statut | data.status |
| Informations contextuelles sur l’alerte | context | data.context |
| Date et heure auxquelles l’alerte a été activée ou résolue | context.timestamp | data.context.timestamp |
| ID de la règle d’alerte | context.id | data.context.id |
| Nom de la règle d’alerte | context.name | data.context.name |
| Description de la règle d’alerte | context.description | data.context.description |
| Condition de règle d’alerte | context.condition | data.context.condition |
| Nom de métrique | context.condition.metricName | data.context.condition.allOf[0].metricName |
| Agrégation de temps (agrégation de la métrique sur la fenêtre d’évaluation) | context.condition.timeAggregation | context.condition.timeAggregation |
| Période d’évaluation | context.condition.windowSize | data.context.condition.windowSize |
| Opérateur (comparaison entre la valeur de métrique agrégée et le seuil) | context.condition.operator | data.context.condition.operator |
| Seuil | context.condition.threshold | data.context.condition.allOf[0].threshold |
| Valeur de métrique | context.condition.metricValue | data.context.condition.allOf[0].metricValue |
| Identifiant d’abonnement | context.subscriptionId | data.context.subscriptionId |
| Groupe de ressources de la ressource affectée | context.resourceGroup | data.context.resourceGroup |
| Nom de la ressource affectée | context.resourceName | data.context.resourceName |
| Type de la ressource affectée | context.resourceType | data.context.resourceType |
| ID de ressource de la ressource affectée | context.resourceId | data.context.resourceId |
| Lien direct vers la page de résumé de la ressource sur le Portail | context.portalLink | data.context.portalLink |
| Champs de charge utile personnalisée à transmettre à l’application logique ou au webhook | properties | data.properties |
Les charges utiles sont similaires, comme vous pouvez le voir. La section suivante propose :
- Des détails sur la modification des applications logiques pour utiliser le nouveau format.
- Un exemple de runbook qui analyse la charge utile de notification pour les nouvelles alertes.
Modifier une application logique pour recevoir une notification d’alerte métrique
Si vous utilisez des applications logiques avec les alertes classiques, vous devez modifier votre code d’application logique pour analyser la charge utile des nouvelles alertes de métrique. Procédez comme suit :
Créez une application logique.
Utilisez le modèle « Azure Monitor - Metrics Alert Handler ». Ce modèle comporte un déclencheur de requête HTTP avec le schéma approprié défini.
Ajoutez une action pour héberger votre logique de traitement.
Utiliser un runbook d’automatisation qui reçoit une notification d’alerte de métrique
L’exemple suivant fournit le code PowerShell à utiliser dans votre runbook. Ce code peut analyser les charges utiles pour les règles d’alerte de métrique classiques et les nouvelles règles d’alerte de métrique.
## Example PowerShell code to use in a runbook to handle parsing of both classic and new metric alerts.
[OutputType("PSAzureOperationResponse")]
param
(
[Parameter (Mandatory=$false)]
[object] $WebhookData
)
$ErrorActionPreference = "stop"
if ($WebhookData)
{
# Get the data object from WebhookData.
$WebhookBody = (ConvertFrom-Json -InputObject $WebhookData.RequestBody)
# Determine whether the alert triggering the runbook is a classic metric alert or a new metric alert (depends on the payload schema).
$schemaId = $WebhookBody.schemaId
Write-Verbose "schemaId: $schemaId" -Verbose
if ($schemaId -eq "AzureMonitorMetricAlert") {
# This is the new metric alert schema.
$AlertContext = [object] ($WebhookBody.data).context
$status = ($WebhookBody.data).status
# Parse fields related to alert rule condition.
$metricName = $AlertContext.condition.allOf[0].metricName
$metricValue = $AlertContext.condition.allOf[0].metricValue
$threshold = $AlertContext.condition.allOf[0].threshold
$timeAggregation = $AlertContext.condition.allOf[0].timeAggregation
}
elseif ($schemaId -eq $null) {
# This is the classic metric alert schema.
$AlertContext = [object] $WebhookBody.context
$status = $WebhookBody.status
# Parse fields related to alert rule condition.
$metricName = $AlertContext.condition.metricName
$metricValue = $AlertContext.condition.metricValue
$threshold = $AlertContext.condition.threshold
$timeAggregation = $AlertContext.condition.timeAggregation
}
else {
# The schema is neither a classic metric alert nor a new metric alert.
Write-Error "The alert data schema - $schemaId - is not supported."
}
# Parse fields related to resource affected.
$ResourceName = $AlertContext.resourceName
$ResourceType = $AlertContext.resourceType
$ResourceGroupName = $AlertContext.resourceGroupName
$ResourceId = $AlertContext.resourceId
$SubId = $AlertContext.subscriptionId
## Your logic to handle the alert here.
}
else {
# Error
Write-Error "This runbook is meant to be started from an Azure alert webhook only."
}
Pour obtenir un exemple complet de runbook qui arrête une machine virtuelle lorsqu’une alerte est déclenchée, consultez la Azure Automation documenation.
Intégration des partenaires par le biais de webhooks
La plupart de nos partenaires qui s’intègrent avec les alertes classiques prennent déjà en charge les nouvelles alertes de métrique. Les intégrations connues qui fonctionnent déjà avec les nouvelles alertes de métrique sont les suivantes :
Si vous utilisez une intégration des partenaires qui n’est pas répertoriée ici, vérifiez auprès d’eux qu’ils utilisent les nouvelles alertes de métrique.