Erstellen von Diagnoseeinstellungen im großen Stil mithilfe von Azure Policy und Initiativen

2025-06-05

Um Azure-Ressourcen zu überwachen, müssen Diagnoseeinstellungen für jede Ressource erstellt werden. Wenn Sie über viele Ressourcen verfügen, kann dieser Prozess schwierig zu verwalten sein. Damit Sie Diagnoseeinstellungen leichter im großen Stil erstellen und anwenden können, verwenden Sie Azure Policy, um Diagnoseeinstellungen sowohl für neue als auch für vorhandene Ressourcen automatisch zu generieren.

Jeder Azure-Ressourcentyp verfügt über einen eindeutigen Satz von Kategorien, die in der Diagnoseeinstellung aufgelistet werden. Für jeden Ressourcentyp ist deshalb eine separate Richtliniendefinition erforderlich. Einige Ressourcentypen verfügen über integrierte Richtliniendefinitionen, die Sie ohne Änderungen zuweisen können. Für andere Ressourcentypen können Sie eine benutzerdefinierte Definition erstellen.

Protokollkategoriegruppen

Protokollkategoriengruppen dienen zum Gruppieren ähnlicher Protokolltypen. Kategoriegruppen erleichtern es, in einem einzigen Befehl auf mehrere Protokolle zu verweisen. Eine AllLogs-Kategoriegruppe ist vorhanden, die alle Protokolle enthält. Es gibt auch eine Überwachungskategoriegruppe , die alle Überwachungsprotokolle enthält. Mithilfe einer Kategoriegruppe können Sie eine Richtlinie definieren, die dynamisch aktualisiert wird, wenn einer Gruppe neue Protokollkategorien hinzugefügt werden.

Integrierte Richtliniendefinitionen für Azure Monitor

In der Regel gibt es drei integrierte Richtliniendefinitionen für jeden Ressourcentyp, die den drei Zielen entsprechen, an die die Diagnose gesendet werden soll:

Log Analytics-Arbeitsbereiche
Azure Storage-Konten
Ereignis-Hubs

Weisen Sie die Richtlinien für den Ressourcentyp je nach den benötigten Zielen zu.

Es existieren eine Reihe von integrierten Richtlinien und Initiativen, die auf den Überwachungsprotokoll-Kategoriegruppen basieren, damit Sie Diagnoseeinstellungen mit nur wenigen Schritten anwenden können. Weitere Informationen finden Sie unter "Aktivieren von Diagnoseeinstellungen nach Kategoriegruppe mithilfe integrierter Richtlinien".

Eine vollständige Liste der integrierten Richtlinien für Azure Monitor finden Sie in den integrierten Azure-Richtliniendefinitionen für Azure Monitor.

Benutzerdefinierte Richtliniendefinitionen

Für Ressourcentypen, die über keine integrierte Richtlinie verfügen, müssen Sie eine benutzerdefinierte Richtliniendefinition erstellen. Sie können im Microsoft Azure-Portal eine neue Richtlinie manuell erstellen, indem Sie eine vorhandene integrierte Richtlinie kopieren und dann für Ihren Ressourcentyp ändern. Stattdessen können Sie die Richtlinie auch programmgesteuert mithilfe eines Skripts im PowerShell-Katalog erstellen.

Das Skript Create-AzDiagPolicy erstellt Richtliniendateien für einen bestimmten Ressourcentyp, den Sie mithilfe von PowerShell oder der Azure CLI installieren können. Erstellen Sie mit folgendem Verfahren eine benutzerdefinierte Richtliniendefinition für Diagnoseeinstellungen:

Stellen Sie sicher, dass Azure PowerShell installiert ist.
Installieren Sie das Skript mit dem folgenden Befehl:
```
Install-Script -Name Create-AzDiagPolicy
```
Führen Sie das Skript mit den Parametern aus, die angeben, wohin die Protokolle gesendet werden sollen. Geben Sie bei der Eingabeaufforderung einen Abonnement- und Ressourcentyp an.

Wenn Sie z. B. eine Richtliniendefinition erstellen möchten, die Protkolle an einen Log Analytics-Arbeitsbereich und einen Event Hub sendet, verwenden Sie den folgenden Befehl:
```
Create-AzDiagPolicy.ps1 -ExportLA -ExportEH -ExportDir ".\PolicyFiles"
```
Alternativ können Sie ein Abonnement und einen Ressourcentyp im Befehl angeben. Wenn Sie z. B. eine Richtliniendefinition erstellen möchten, die an einen Log Analytics-Arbeitsbereich und einen Event Hub für Azure SQL Server-Datenbanken sendet, verwenden Sie den folgenden Befehl:
```
Create-AzDiagPolicy.ps1 -SubscriptionID <subscription id> -ResourceType Microsoft.Sql/servers/databases -ExportLA -ExportEH -ExportDir ".\PolicyFiles"
```
Das Skript erstellt separate Ordner für jede Richtliniendefinition. Jeder Ordner enthält drei Dateien mit dem Namen azurepolicy.json, azurepolicy.rules.jsonund azurepolicy.parameters.json. Wenn Sie die Richtlinie manuell im Azure-Portal erstellen möchten, können Sie den Inhaltazurepolicy.jsonkopieren und einfügen, da sie die gesamte Richtliniendefinition enthält. Verwenden Sie die anderen beiden Dateien mit PowerShell oder der Azure CLI, um die Richtliniendefinition über eine Befehlszeile zu erstellen.

In den folgenden Beispielen wird gezeigt, wie die Richtliniendefinition sowohl über PowerShell als auch über die Azure CLI installiert wird. Jedes Beispiel enthält Metadaten, um eine Überwachungskategorie anzugeben, um die neue Richtliniendefinition mit den integrierten Richtliniendefinitionen zu gruppieren.
```
New-AzPolicyDefinition -name "Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace" -policy .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json -parameter .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json -mode All -Metadata '{"category":"Monitoring"}'
```
```
az policy definition create --name 'deploy-diag-setting-sql-database--workspace' --display-name 'Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace'  --rules 'Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json' --params 'Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json' --subscription 'AzureMonitor_Docs' --mode All
```

Initiative

Anstatt für jede Richtliniendefinition eine Zuweisung zu erstellen, ist es eine gängige Strategie, eine Initiative zu erstellen, die die Richtliniendefinitionen umfasst, um Diagnoseeinstellungen für jeden Azure-Dienst zu erstellen. Erstellen Sie abhängig von der Art der Verwaltung Ihrer Umgebung eine Zuweisung zwischen der Initiative und einer Verwaltungsgruppe, einem Abonnement oder einer Ressourcengruppe. Diese Strategie bietet folgende Vorteile:

Erstellen Sie eine einzelne Zuweisung für die Initiative anstelle mehrerer Zuweisungen für jeden Ressourcentyp. Verwenden Sie dieselbe Initiative für mehrere Überwachungsgruppen, Abonnements oder Ressourcengruppen.
Ändern Sie die Initiative, wenn Sie einen neuen Ressourcentyp oder ein neues Ziel hinzufügen müssen. Beispielsweise können die ersten Anforderungen darin bestehen, Daten nur an einen Log Analytics-Arbeitsbereich zu senden, aber später möchten Sie einen Event Hub hinzufügen. Ändern Sie die Initiative, anstatt neue Zuweisungen zu erstellen.

Ausführliche Informationen zum Erstellen einer Initiative finden Sie unter Erstellen und Zuweisen einer Initiativedefinition. Beachten Sie die folgenden Empfehlungen:

Legen Sie "Kategorie auf Überwachung " fest, um sie mit verwandten integrierten und benutzerdefinierten Richtliniendefinitionen zu gruppieren.
Anstatt die Details für den Log Analytics-Arbeitsbereich und den Event Hub für die Richtliniendefinition in der Initiative anzugeben, verwenden Sie einen allgemeinen Initiativparameter. Mit diesem Parameter können Sie auf einfache Weise einen allgemeinen Wert für alle Richtliniendefinitionen angeben und diesen Wert bei Bedarf ändern.

Zuweisung

Weisen Sie die Initiative abhängig vom Umfang ihrer zu überwachenden Ressourcen einer Azure-Verwaltungsgruppe, einem Abonnement oder einer Ressourcengruppe zu. Eine Verwaltungsgruppe ist nützlich für bereichsbezogene Richtlinien, insbesondere wenn Ihre Organisation über mehrere Abonnements verfügt.

Mithilfe von Initiativparametern können Sie den Arbeitsbereich oder andere Details einmal für alle Richtliniendefinitionen in der Initiative angeben.

Wiederherstellung

Die Initiative wird auf jeden virtuellen Computer angewendet, während er erstellt wird. Eine Wartungsaufgabe stellt die Richtliniendefinitionen in der Initiative für vorhandene Ressourcen bereit, sodass Sie Diagnoseeinstellungen für alle Ressourcen erstellen können, die bereits erstellt wurden.

Wenn Sie die Zuweisung mithilfe des Azure-Portals erstellen, können Sie gleichzeitig einen Wartungstask erstellen. Ausführliche Informationen zur Behebung finden Sie unter "Korrigieren nicht kompatibler Ressourcen mit Azure-Richtlinie ".

Problembehandlung

Die Metrikkategorie wird nicht unterstützt.

Beim Bereitstellen einer Diagnoseeinstellung erhalten Sie eine Fehlermeldung, ähnlich wie die Metrikkategorie "xxxx" wird nicht unterstützt. Dieser Fehler wird möglicherweise angezeigt, auch wenn Ihre vorherige Bereitstellung erfolgreich war.

Das Problem tritt auf, wenn Sie eine Resource Manager-Vorlage, die REST-API, die Azure CLI oder Azure PowerShell verwenden. Über das Microsoft Azure-Portal erstellte Diagnoseeinstellungen sind nicht betroffen, da nur die unterstützten Kategorienamen angezeigt werden.

Andere Metrikkategorien als AllMetrics werden nicht unterstützt, mit Ausnahme einer begrenzten Anzahl von Azure-Diensten. Zuvor wurden andere Kategorienamen ignoriert, wenn eine Diagnoseeinstellung bereitgestellt wurde, und sie wurden zu AllMetrics umgeleitet. Ab Februar 2021 wird die angegebene Metrikkategorie überprüft. Diese Änderung führte bei einigen Bereitstellungen zu Fehlern.

Um dieses Problem zu beheben, aktualisieren Sie Ihre Bereitstellungen, um alle metrischen Kategorienamen zu entfernen, die nicht AllMetrics sind. Wenn die Bereitstellung mehrere Kategorien hinzufügt, verwenden Sie nur eine AllMetrics-Kategorie. Wenn das Problem weiterhin besteht, wenden Sie sich an den Azure-Support über das Azure-Portal.

Einstellung wird aufgrund von Nicht-ASCII-Zeichen in resourceID nicht mehr angezeigt

Diagnoseeinstellungen unterstützen keine Ressourcen-IDs mit Nicht-ASCII-Zeichen (z. B. „Preproduccón“). Da Sie Ressourcen in Azure nicht umbenennen können, müssen Sie eine neue Ressource ohne Nicht-ASCII-Zeichen erstellen. Wenn sich die Charaktere in einer Ressourcengruppe befinden, können Sie die Ressourcen in eine neue Gruppe verschieben.

Möglichkeit des Auftretens von duplizierten oder gelöschten Daten

Es wird alles dafür getan, um sicherzustellen, dass alle Protokolldaten ordnungsgemäß an Ihre Ziele gesendet werden. Zwischen Endpunkten kann jedoch keine hundertprozentige Datenübertragung von Protokollen garantiert werden. Wiederholungen und andere Mechanismen sind vorhanden, um diese Probleme zu umgehen und sicherzustellen, dass Protokolldaten beim Endpunkt ankommen.

Inaktive Ressourcen

Wenn eine Ressource inaktiv ist und Nullwertmetriken exportiert, wird für den Exportmechanismus der Diagnoseeinstellungen ein inkrementelles Backoff ausgeführt, um unnötige Kosten für das Exportieren und Speichern von Nullwerten zu vermeiden. Das Backoff kann zu einer Verzögerung beim Export des nächsten Werts ungleich Null führen.

Wenn eine Ressource eine Stunde lang inaktiv ist, wird für den Exportmechanismus ein Backoff auf 15 Minuten ausgeführt. Das bedeutet, dass es eine potenzielle Wartezeit von bis zu 15 Minuten gibt, bis der nächste Wert ungleich null exportiert wird. Die maximale Backoffzeit von zwei Stunden wird nach sieben Tagen Inaktivität erreicht. Sobald die Ressource mit dem Exportieren von Werten ungleich Null beginnt, wird der Exportmechanismus auf die ursprüngliche Exportwartezeit von drei Minuten zurückgesetzt.

Dieses Verhalten gilt nur für exportierte Metriken und wirkt sich nicht auf metrikbasierte Warnungen oder automatische Skalierung aus.

Warum wird duplizierte Telemetrie in Application Insights angezeigt, nachdem Diagnoseeinstellungen aktiviert wurden?

Wenn Sie Diagnoseeinstellungen aktivieren, um arbeitsbereichbasierte Application Insights-Daten in einen beliebigen Log Analytics-Arbeitsbereich zu exportieren, einschließlich desselben, das bereits Application Insights-Daten speichert, geben Abfragen doppelte Ergebnisse zurück. Diese Duplizierung geschieht, da sowohl die Standardpipeline als auch die Diagnoseeinstellungen dieselben Daten an den Arbeitsbereich senden.

Um doppelte Telemetrie zu vermeiden, konfigurieren Sie keine Diagnoseeinstellungen, um Daten an denselben Arbeitsbereich zu senden. Wenn Sie Daten in einen anderen Arbeitsbereich exportieren müssen, verwenden Sie eine Datensammlungsregel (Data Collection Rule, DCR) mit einer Transformation und einer benutzerdefinierten Tabelle. Diese Einrichtung filtert die Daten vor der Aufnahme und verhindert doppelte Datensätze in Ihren Abfragen.