Condividi tramite


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:

  1. Creare una nuova app per la logica.

  2. Usare il modello "Monitoraggio di Azure - Gestore avvisi metriche". Questo modello ha un trigger di richiesta HTTP con lo schema appropriato definito.

    Screenshot che mostra due pulsanti, App per la logica vuota e Monitoraggio di Azure - Gestore avvisi metriche.

  3. 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.

Passaggi successivi