Preparare le app per la logica e manuali operativi per la migrazione delle regole di avviso classiche
Nota
Come annunciato in precedenza, gli avvisi classici in Monitoraggio di Azure vengono ritirati per gli utenti del cloud pubblico, anche se ancora in uso limitato fino al 31 maggio 2021. Gli avvisi classici per Azure per enti pubblici cloud e Microsoft Azure gestiti da 21Vianet verranno ritirati il 29 febbraio 2024.
Se si sceglie di eseguire volontariamente la migrazione volontaria delle regole di avviso classiche alle nuove regole di avviso, esistono alcune differenze tra i due sistemi. Questo articolo illustra le differenze e come prepararsi per la modifica.
Modifiche all'API
Le API che creano e gestiscono le regole di avviso classiche (microsoft.insights/alertrules) sono diverse dalle API che creano e gestiscono nuovi avvisi delle metriche (microsoft.insights/metricalerts). Se attualmente si creano e si gestiscono regole di avviso classiche a livello di codice, aggiornare gli script di distribuzione in modo che funzionino con le nuove API.
La tabella seguente è un riferimento alle interfacce a livello di codice sia per gli avvisi classici che per i nuovi avvisi:
| Tipo di script di distribuzione | Avvisi classici | Nuovi avvisi delle metriche |
|---|---|---|
| API REST | microsoft.insights/alertrules | microsoft.insights/metricalerts |
| Interfaccia della riga di comando di Azure | az monitor alert |
az monitor metrics alert |
| PowerShell | Riferimento | Riferimento |
| Modello di Azure Resource Manager | Per gli avvisi classici | Per i nuovi avvisi delle metriche |
Modifiche al payload delle notifiche
Il formato del payload di notifica è leggermente diverso tra le regole di avviso classiche e i nuovi avvisi delle metriche. Se si dispone di regole di avviso classiche con webhook, app per la logica o azioni runbook, è necessario aggiornare le destinazioni per accettare il nuovo formato di payload.
Usare la tabella seguente per eseguire il mapping dei campi del payload del webhook dal formato classico al nuovo formato:
| Tipo di endpoint di notifica | Avvisi classici | Nuovi avvisi delle metriche |
|---|---|---|
| L'avviso è stato attivato o risolto? | Stato | data.status |
| Informazioni contestuali sull'avviso | context | data.context |
| Timestamp in corrispondenza del quale l'avviso è stato attivato o risolto | context.timestamp | data.context.timestamp |
| ID regola di avviso | context.id | data.context.id |
| Nome regola di avviso | context.name | data.context.name |
| Descrizione della regola di avviso | context.description | data.context.description |
| Condizione della regola di avviso | context.condition | data.context.condition |
| Nome metrica | context.condition.metricName | data.context.condition.allOf[0].metricName |
| Aggregazione temporale (modalità di aggregazione della metrica nella finestra di valutazione) | context.condition.timeAggregation | context.condition.timeAggregation |
| Periodo di valutazione | context.condition.windowSize | data.context.condition.windowSize |
| Operatore (confronto tra il valore della metrica aggregata e la soglia) | context.condition.operator | data.context.condition.operator |
| Soglia | context.condition.threshold | data.context.condition.allOf[0].threshold |
| Valore della metrica | context.condition.metricValue | data.context.condition.allOf[0].metricValue |
| ID sottoscrizione | context.subscriptionId | data.context.subscriptionId |
| Gruppo di risorse della risorsa interessata | context.resourceGroup | data.context.resourceGroup |
| Nome della risorsa interessata | context.resourceName | data.context.resourceName |
| Tipo della risorsa interessata | context.resourceType | data.context.resourceType |
| ID risorsa della risorsa interessata | context.resourceId | data.context.resourceId |
| Collegamento diretto alla pagina di riepilogo delle risorse del portale | context.portalLink | data.context.portalLink |
| Campi di payload personalizzati da passare al webhook o all'app per la logica | properties | data.properties |
I payload sono simili, come si può notare. La sezione seguente offre:
- Informazioni dettagliate sulla modifica delle app per la logica in modo che funzionino con il nuovo formato.
- Esempio di runbook che analizza il payload di notifica per i nuovi avvisi.
Modificare un'app per la logica per ricevere una notifica di avviso delle metriche
Se si usano app per la logica con avvisi classici, è necessario modificare il codice dell'app per la logica per analizzare il nuovo payload degli avvisi delle metriche. Seguire questa procedura:
Creare una nuova app per la logica.
Usare il modello "Monitoraggio di Azure - Gestore avvisi metriche". Questo modello ha un trigger di richiesta HTTP con lo schema appropriato definito.
Aggiungere un'azione per ospitare la logica di elaborazione.
Usare un runbook di automazione che riceve una notifica di avviso delle metriche
Nell'esempio seguente viene fornito il codice di PowerShell da usare nel runbook. Questo codice può analizzare i payload per le regole di avviso delle metriche classiche e le nuove regole di avviso delle metriche.
## 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."
}
Per un esempio completo di runbook che arresta una macchina virtuale quando viene attivato un avviso, vedere la Automazione di Azure documenation.
Integrazione dei partner tramite webhook
La maggior parte dei nostri partner che si integrano con avvisi classici supporta già gli avvisi delle metriche più recenti tramite le loro integrazioni. Le integrazioni note che funzionano già con i nuovi avvisi delle metriche includono:
Se si usa un'integrazione partner non elencata qui, verificare con il provider che funzionano con nuovi avvisi delle metriche.