Konfigurieren von Ressourcenintegritätswarnungen mithilfe von Resource Manager-Vorlagen
In diesem Artikel wird gezeigt, wie Sie mithilfe von Azure Resource Manager-Vorlagen und Azure PowerShell programmgesteuert Resource Health-Aktivitätsprotokollwarnungen erstellen.
Azure Resource Health informiert Sie über den aktuellen und den vergangenen Integritätsstatus Ihrer Azure-Ressourcen. Azure Resource Health-Warnungen können Sie nahezu in Echtzeit informieren, wenn sich der Integritätsstatus dieser Ressourcen ändert. Die programmgesteuerte Erstellung von Resource Health-Warnungen ermöglicht Benutzern das Massenerstellen und -anpassen von Warnungen.
Hinweis
Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.
Voraussetzungen
Damit Sie die Anweisungen auf dieser Seite ausführen können, müssen Sie vorab einige Komponenten einrichten:
- Installieren Sie das Azure PowerShell -Modul.
- Sie können eine Aktionsgruppe erstellen oder wiederverwenden, die so konfiguriert ist, dass Sie benachrichtigt werden.
Anweisungen
Melden Sie sich unter Verwendung von PowerShell und Ihres Kontos bei Azure an, und wählen Sie das gewünschte Abonnement aus.
Login-AzAccount Select-AzSubscription -Subscription <subscriptionId>Hinweis
Sie können mit
Get-AzSubscriptiondie Abonnements auflisten, auf die Sie Zugriff haben.Suchen Sie die vollständige Azure Resource Manager-ID für Ihre Aktionsgruppe, und speichern Sie sie.
(Get-AzActionGroup -ResourceGroupName <resourceGroup> -Name <actionGroup>).IdErstellen und speichern Sie eine Resource Manager-Vorlage für Resource Health-Warnungen unter resourcehealthalert.json. Weitere Informationen finden Sie unter Resource Manager-Vorlagenoptionen für Resource Health-Warnungen.
Erstellen Sie mit dieser Vorlage eine neue Azure Resource Manager-Bereitstellung.
New-AzResourceGroupDeployment -Name ExampleDeployment -ResourceGroupName <resourceGroup> -TemplateFile <path\to\resourcehealthalert.json>Sie werden zur Eingabe des Warnungsnamen und der Ressourcen-ID der Aktionsgruppe aufgefordert, die Sie zuvor kopiert haben:
Supply values for the following parameters: (Type !? for Help.) activityLogAlertName: <Alert Name> actionGroupResourceId: /subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/microsoft.insights/actionGroups/<actionGroup>Wurden alle Schritte erfolgreich ausgeführt, erhalten Sie eine Bestätigung in 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 :
Wenn Sie diesen Prozess vollständig automatisieren möchten, müssen Sie einfach die Resource Manager-Vorlage so bearbeiten, dass in Schritt 5 nicht zur Eingabe der Werte aufgefordert wird.
Resource Manager-Vorlagenoptionen für Resource Health-Warnungen
Sie können diese Basisvorlage als Ausgangspunkt zum Erstellen von Resource Health-Warnungen verwenden. Diese Vorlage funktioniert wie vorliegend, und Sie werden für den Empfang von Warnungen für alle neu aktivierten Ressourcenintegritätsereignisse in allen Ressourcen eines Abonnements registriert.
Hinweis
Am Ende dieses Artikels finden Sie außerdem eine komplexere Warnungsvorlage, die das Signal-Rausch-Verhältnis für Resource Health-Warnungen im Vergleich zu dieser Vorlage erhöht.
{
"$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')]"
}
]
}
}
}
]
}
Eine allgemeine Vorlage wie diese wird im Allgemeinen jedoch nicht empfohlen. Im folgenden Abschnitt erfahren Sie, wie Sie diese Warnung weiter einschränken, um sich auf die für uns relevanten Ereignisse zu konzentrieren.
Anpassen des Warnungsbereichs
Resource Health-Warnungen können so konfiguriert werden, dass sie Ereignisse in drei verschiedenen Bereichen überwachen:
- Abonnementstufe
- Ressourcengruppenebene
- Ressourcenebene
Die Warnungsvorlage wird auf Abonnementebene konfiguriert. Wenn Sie die Warnung jedoch so konfigurieren möchten, dass Sie nur über bestimmte Ressourcen oder Ressourcen in einer bestimmten Ressourcengruppe benachrichtigt werden, müssen Sie lediglich den Abschnitt scopes in dieser Vorlage ändern.
Für einen Bereich auf Ressourcengruppenebene sieht der Abschnitt „scopes“ etwa wie folgt aus:
"scopes": [
"/subscriptions/<subscription id>/resourcegroups/<resource group>"
],
Für einen Bereich auf Ressourcenebene sieht der Abschnitt „scopes“ etwa wie folgt aus:
"scopes": [
"/subscriptions/<subscription id>/resourcegroups/<resource group>/providers/<resource>"
],
Beispiel: "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/myRG/providers/microsoft.compute/virtualmachines/myVm"
Hinweis
Diese Zeichenfolge erhalten Sie, indem Sie Ihre Azure-Ressource im Azure-Portal anzeigen und sich die URL ansehen.
Anpassen der Ressourcentypen, die Sie benachrichtigen
Warnungen auf Abonnement- oder Ressourcengruppenebene enthalten unter Umständen unterschiedliche Ressourcen. Wenn Sie Warnungen auf eine bestimmte Teilmenge von Ressourcentypen beschränken möchten, können Sie dies im Abschnitt condition der Vorlage festlegen. Beispiel:
"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "resourceType",
"equals": "MICROSOFT.COMPUTE/VIRTUALMACHINES",
"containsAny": null
},
{
"field": "resourceType",
"equals": "MICROSOFT.STORAGE/STORAGEACCOUNTS",
"containsAny": null
},
...
]
}
]
},
Hier wird mit dem Wrapper anyOf zugelassen, dass die Ressourcenintegritätswarnung einer der angegebenen Bedingungen entspricht. Dadurch werden Warnungen für bestimmte Ressourcentypen ermöglicht.
Anpassen der Resource Health-Ereignisse, die Sie benachrichtigen
Wenn für Ressourcen ein Integritätsereignis auftritt, können sie eine Reihe von Phasen durchlaufen, die den Status des Integritätsereignisses darstellen: Active, In Progress, Updated und Resolved.
Sie möchten möglicherweise nur benachrichtigt werden, wenn eine Ressource fehlerhaft ist. In diesem Fall sollten Sie Ihre Warnung so konfigurieren, dass Sie nur benachrichtigt werden, wenn für status der Wert Active lautet. Wenn Sie jedoch auch über die anderen Phasen benachrichtigt werden möchten, können Sie diese Details wie folgt hinzufügen:
"condition": {
"allOf": [
...,
{
"anyOf": [
{
"field": "status",
"equals": "Active"
},
{
"field": "status",
"equals": "In Progress"
},
{
"field": "status",
"equals": "Resolved"
},
{
"field": "status",
"equals": "Updated"
}
]
}
]
}
Wenn Sie bei allen vier Phasen der Integritätsereignisse informiert werden möchten, können Sie diese Bedingung vollständig entfernen, und Sie werden unabhängig von der Eigenschaft status benachrichtigt.
Hinweis
Jeder Abschnitt „anyOf“ sollte nur einen Feldtypwert enthalten.
Anpassen der Resource Health-Warnungen, um Ereignisse vom Typ „Unknown“ (Unbekannt) zu vermeiden
Azure Resource Health führt zur Überwachung Ihrer Ressourcen kontinuierlich Testrunner aus und hält Sie so über die aktuelle Integrität Ihrer Ressourcen auf dem Laufenden. Die relevanten gemeldeten Integritätsstatus sind: Available, Unavailable und Degraded. Wenn der Runner und die Azure-Ressource nicht kommunizieren können, wird für die Ressource der Integritätsstatus Unknown gemeldet, und dieser Status wird als Integritätsereignis vom Typ „Active“ (Aktiv) betrachtet.
Wenn für eine Ressource jedoch Unknown gemeldet wird, besteht die Wahrscheinlichkeit, dass sich ihr Integritätsstatus seit dem letzten korrekten Bericht nicht geändert hat. Wenn Sie Warnungen für Ereignisse vom Typ Unknown vermeiden möchten, können Sie die folgende Logik in die Vorlage aufnehmen:
"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
}
]
},
]
},
In diesem Beispiel wird nur bei Ereignissen eine Benachrichtigung gesendet, deren aktueller und vorheriger Integritätsstatus nicht Unknown lautet. Diese Änderung kann eine nützliche Ergänzung sein, wenn Ihre Warnungen direkt an Ihr Mobiltelefon oder Ihre mobile E-Mail gesendet wird.
Bei bestimmten Ereignissen können die Eigenschaften currentHealthStatus und previousHealthStatus den Wert NULL haben. Wenn beispielsweise das Ereignis „Updated“ (Aktualisiert) auftritt, ist es wahrscheinlich, dass sich der Integritätsstatus der Ressource seit dem letzten Bericht nicht geändert hat und nur zusätzliche Ereignisinformationen (z. B. „cause“) verfügbar sind. Daher führt die Verwendung der Klausel in diesem Beispiel u. U. dazu, dass einige Warnungen nicht ausgelöst werden, da die Werte properties.currentHealthStatus und properties.previousHealthStatus auf NULL festgelegt sind.
Anpassen der Warnung, um vom Benutzer initiierte Ereignisse zu vermeiden
Resource Health-Ereignisse können durch Ereignisse ausgelöst werden, die von der Plattform oder vom Benutzer initiiert wurden. Es kann sinnvoll sein, nur eine Benachrichtigung zu senden, wenn das Integritätsereignis von der Azure-Plattform verursacht wird.
Die Warnung kann einfach so konfiguriert werden, dass sie nur nach diesen Ereignistypen filtert:
"condition": {
"allOf": [
...,
{
"field": "properties.cause",
"equals": "PlatformInitiated",
"containsAny": null
}
]
}
Das Feld „cause“ kann bei einigen Ereignissen den Wert NULL haben. Das bedeutet, dass sich der Integritätsstatus ändert (z. B. von „Verfügbar“ in „Nicht verfügbar“) und das Ereignis sofort protokolliert wird, um Verzögerungen von Benachrichtigungen zu vermeiden. Daher kann es sein, dass keine Warnung ausgelöst wird, wenn Sie die Klausel aus diesem Beispiel verwenden, weil der Eigenschaftswert properties.cause auf NULL festgelegt ist.
Abschließen einer Resource Health-Warnungsvorlage
Nachfolgend finden Sie eine Beispielvorlage, die mit den im vorherigen Abschnitt beschriebenen Einstellungen konfiguriert wurde, um das Signal-Rausch-Verhältnis zu maximieren. Denken Sie daran, dass die Eigenschaften currentHealthStatus, previousHealthStatus sowie die Eigenschaftswerte für „cause“ wie weiter oben beschrieben bei einigen Ereignissen den Wert NULL haben können.
{
"$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')]"
}
]
}
}
}
]
}
Sie können jedoch selbst am besten einschätzen, welche Konfigurationen effektiv sind. Nehmen Sie daher mit den in dieser Dokumentation vorgestellten Methoden eigene Anpassungen vor.
Nächste Schritte
Erfahren Sie mehr über Resource Health:
- Übersicht über Azure Resource Health
- Über Azure Resource Health verfügbare Ressourcentypen und Integritätsüberprüfungen
Erstellen von Service Health-Warnungen: