Freigeben über


Vorbereiten Ihrer Logik-Apps und Runbooks für die Migration von klassischen Warnungsregeln

Hinweis

Wie zuvor angekündigt werden klassische Warnungen in Azure Monitor für Benutzer der öffentlichen Cloud eingestellt. Bis zum 31. Mai 2021 ist die Verwendung noch eingeschränkt möglich. Klassische Warnungen für die Azure Government-Cloud und Microsoft Azure des Betreibers 21ViaNet werden am 29. Februar 2024 eingestellt.

Wenn Sie sich entscheiden, Ihre klassischen Warnungsregeln zu neuen Warnungsregeln zu migrieren, beachten Sie, dass zwischen den beiden Systemen einige Unterschiede bestehen. In diesem Artikel werden die Unterschiede erläutert, und Sie erfahren, wie Sie sich auf die Änderung vorbereiten können.

API-Änderungen

Die APIs zum Erstellen und Verwalten klassischer Warnungsregeln (microsoft.insights/alertrules) unterscheiden sich von den APIs zum Erstellen und Verwalten der neuen Metrikwarnungen (microsoft.insights/metricalerts). Wenn Sie klassische Warnungsregeln derzeit programmgesteuert erstellen und verwalten, aktualisieren Sie Ihre Bereitstellungsskripts, damit sie mit den neuen APIs funktionieren.

In der folgenden Tabelle sind befehlsorientierte Benutzerschnittstellen für klassische und neue Warnungen aufgeführt:

Typ des Bereitstellungsskripts Klassische Warnungen Neue Metrikwarnungen
REST-API microsoft.insights/alertrules microsoft.insights/metricalerts
Azure-Befehlszeilenschnittstelle az monitor alert az monitor metrics alert
PowerShell Referenz Referenz
Azure Resource Manager-Vorlage Für klassische Warnungen Für neue Metrikwarnungen

Änderungen der Benachrichtigungsnutzlast

Das Format der Benachrichtigungsnutzlast für klassische Warnungsregeln und neue Metrikwarnungen unterscheidet sich geringfügig. Wenn Sie über klassische Warnungsregeln mit Webhook-, Logik-App- oder Runbookaktionen verfügen, müssen Sie die Ziele so aktualisieren, dass sie das neue Nutzdatenformat akzeptieren.

Mithilfe der folgenden Tabelle können Sie die Felder für die Webhooknutzlast im klassischen Format dem neuen Format zuordnen:

Typ des Benachrichtigungsendpunkts Klassische Warnungen Neue Metrikwarnungen
Wurde die Warnung aktiviert oder behoben? status data.status
Kontextinformationen zur Warnung context data.context
Zeitstempel der Aktivierung oder Auflösung der Warnung context.timestamp data.context.timestamp
Warnungsregel-ID context.id data.context.id
Name der Warnungsregel context.name data.context.name
Beschreibung der Warnungsregel context.description data.context.description
Warnungsregelbedingung context.condition data.context.condition
Metrikname context.condition.metricName data.context.condition.allOf[0].metricName
Zeitaggregation (wie die Metrik im Auswertungsfenster aggregiert wird) context.condition.timeAggregation context.condition.timeAggregation
Auswertungszeitraum context.condition.windowSize data.context.condition.windowSize
Operator (Vergleich des aggregierten Metrikwerts mit dem Schwellenwert) context.condition.operator data.context.condition.operator
Schwellenwert context.condition.threshold data.context.condition.allOf[0].threshold
Metrikwert context.condition.metricValue data.context.condition.allOf[0].metricValue
Abonnement-ID context.subscriptionId data.context.subscriptionId
Ressourcengruppe der betroffenen Ressource context.resourceGroup data.context.resourceGroup
Name der betroffenen Ressource context.resourceName data.context.resourceName
Typ der betroffenen Ressource context.resourceType data.context.resourceType
Ressourcen-ID der betroffenen Ressource context.resourceId data.context.resourceId
Direkter Link zur Ressourcenzusammenfassungsseite des Portals context.portalLink data.context.portalLink
Benutzerdefinierte Nutzlastfelder, die an den Webhook oder die Logik-App übergeben werden sollen properties data.properties

Wie Sie sehen, sind die Nutzlasten ähnlich. Der nächste Abschnitt enthält Folgendes:

  • Ausführliche Informationen zum Ändern von Logik-Apps zur Verwendung mit dem neuen Format
  • Ein Runbook-Beispiel, in dem die Benachrichtigungsnutzlast für neue Warnungen analysiert wird

Ändern einer Logik-App zum Empfangen einer Benachrichtigung über eine Metrikwarnung

Wenn Sie Logik-Apps mit klassischen Warnungen verwenden, müssen Sie den Logik-App-Code ändern, damit die neue Metrikwarnungsnutzlast analysiert wird. Folgen Sie diesen Schritten:

  1. Erstellen Sie eine neue Logik-App.

  2. Verwenden Sie die Vorlage „Azure Monitor – Metrics Alert Handler“ (Azure Monitor – Metrikwarnungshandler). Diese Vorlage enthält einen Auslöser HTTP-Anforderung, für den das entsprechende Schema definiert ist.

    Screenshot: Zwei Schaltflächen: „Leere Logik-App“ und „Azure Monitor – Metrics Alert Handler“ (Azure Monitor – Metrikwarnungshandler)

  3. Fügen Sie eine Aktion zum Hosten Ihrer Verarbeitungslogik hinzu.

Verwenden eines Automation-Runbooks, das eine Benachrichtigung über eine Metrikwarnung empfängt

Das folgende Beispiel enthält PowerShell-Code zur Verwendung in Ihrem Runbook. Mit diesem Code können die Nutzlasten sowohl für klassische Metrikwarnungsregeln als auch neue Metrikwarnungsregeln analysiert werden.

## 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."
}

Ein vollständiges Beispiel für ein Runbook, das einen virtuellen Computer beendet, wenn eine Warnung ausgelöst wird, finden Sie in der Dokumentation Azure Automation.

Partnerintegration über Webhooks

Die meisten unserer Partner, die integrierte Lösungen für klassische Warnungen anbieten, unterstützen neuere Metrikwarnungen bereits über ihre Integrationen. Zu den bekannten Integrationen, die bereits mit neuen Metrikwarnungen funktionieren, gehören:

Wenn Sie eine Partnerintegration verwenden, die hier nicht aufgeführt ist, erkundigen Sie sich beim Anbieter, ob diese mit neuen Metrikwarnungen funktioniert.

Nächste Schritte