Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Details zum Erstellen und Konfigurieren von Diagnoseeinstellungen zum Senden von Azure-Plattformmetriken, Ressourcenprotokollen und Aktivitätsprotokollen an verschiedene Ziele.
Jede Azure-Ressource erfordert eine eigene Diagnoseeinstellung, die folgende Kriterien definiert:
- Quellen: Der Typ der Metrik- und Protokolldaten, die an die in der Einstellung definierten Ziele gesendet werden sollen. Die verfügbaren Typen variieren je nach Ressourcentyp.
- Ziele: Mindestens ein Ziel, an das gesendet werden soll.
Mit einer einzelnen Diagnoseeinstellung kann maximal eines der Ziele definiert werden. Wenn Sie Daten an mehrere Ziele eines bestimmten Typs senden möchten (z. B. zwei verschiedene Log Analytics-Arbeitsbereiche), erstellen Sie mehrere Einstellungen. Jede Ressource kann über bis zu fünf Diagnoseeinstellungen verfügen.
Warnung
Wenn Sie eine Ressource löschen, umbenennen, verschieben oder über Ressourcengruppen oder Abonnements hinweg migrieren möchten, löschen Sie zunächst die Diagnoseeinstellungen. Andernfalls kann es abhängig von der Ressourcenkonfiguration der jeweiligen Ressource vorkommen, dass die Diagnoseeinstellungen für die gelöschte Ressource in die neue Ressource eingeschlossen werden, wenn Sie diese Ressource neu erstellen. Wenn die Diagnoseeinstellungen in die neue Ressource eingeschlossen werden, wird die Sammlung von Ressourcenprotokollen wie in der Diagnoseeinstellung definiert fortgesetzt, und die entsprechenden Metrik- und Protokolldaten werden an das zuvor konfigurierte Ziel gesendet.
Außerdem empfiehlt es sich, die Diagnoseeinstellungen für eine Ressource, die Sie löschen und voraussichtlich nicht erneut verwenden möchten, zu löschen, um die Umgebung zu bereinigen.
Das folgende Video führt Sie durch das Routing von Ressourcenplattformprotokollen mit Diagnoseeinstellungen. Das Video wurde zu einem früheren Zeitpunkt aufgenommen. Bedenken Sie dabei folgende Änderungen:
- Es gibt jetzt vier Ziele. Sie können Plattformmetriken und -protokolle an bestimmte Azure Monitor Partner senden.
- Im November 2021 wurde ein neues Feature namens Kategoriegruppen eingeführt.
Informationen zu diesen neueren Features finden Sie in diesem Artikel.
Quellen
Es gibt drei Quellen für Diagnoseinformationen:
- Plattformmetriken werden standardmäßig und ohne Konfiguration automatisch an Azure Monitor-Metriken gesendet. Weitere Informationen zu unterstützten Metriken finden Sie unter "Unterstützte Metriken" mit Azure Monitor
- Plattform-Protokolle liefern detaillierte Diagnose- und Überwachungsinformationen für Azure-Ressourcen und die Azure-Plattform, von der sie abhängen.
- Ressourcenprotokolle werden erst gesammelt, wenn sie an ein Ziel weitergeleitet werden. Weitere Informationen zu unterstützten Protokollen finden Sie unter "Unterstützte Ressourcenprotokollkategorien" für Azure Monitor
- Das Aktivitätsprotokoll stellt Informationen zu Ressourcen von außerhalb der Ressource bereit, z. B. wann die Ressource erstellt oder gelöscht wurde. Einträge existieren für sich allein, können aber an andere Stellen weitergeleitet werden.
Metriken
Die Einstellung "AllMetrics " leitet die Plattformmetriken einer Ressource an andere Ziele weiter. Diese Option ist möglicherweise nicht bei allen Ressourcenanbietern vorhanden.
Ressourcenprotokolle
Bei Ressourcenprotokollen können Sie die Protokollkategorien, die Sie weiterleiten möchten, einzeln auswählen oder eine Kategoriegruppe wählen.
Kategoriegruppen
Hinweis
Kategoriegruppen gelten nicht für alle Metrikressourcenanbieter. Wenn ein Anbieter sie nicht in den Diagnoseeinstellungen im Azure-Portal verfügbar hat, dann sind sie auch nicht über Azure Resource Manager-Vorlagen verfügbar.
Sie können Kategoriegruppen verwenden, um Ressourcenprotokolle basierend auf vordefinierten Gruppierungen dynamisch zu sammeln, anstatt einzelne Protokollkategorien auszuwählen. Microsoft definiert die Gruppierungen, um die Überwachung bestimmter Anwendungsfälle über alle Azure-Dienste hinweg zu erleichtern. Im Laufe der Zeit können die Kategorien in der Gruppe aktualisiert werden, wenn neue Protokolle eingeführt werden oder sich Bewertungen ändern. Wenn Protokollkategorien einer Kategoriegruppe hinzugefügt oder daraus entfernt werden, wird Ihre Protokollsammlung automatisch geändert, ohne dass Sie Ihre Diagnoseeinstellungen aktualisieren müssen.
Wenn Sie Kategoriegruppen verwenden, können Sie:
- Ressourcenprotokolle nicht mehr individuell auf der Grundlage einzelner Kategorietypen auswählen.
- Aufbewahrungseinstellungen nicht mehr auf Protokolle anwenden, die an Azure Storage gesendet werden.
Derzeit gibt es zwei Gruppen von Kategorien:
- Alle: Jeder Protokolleintrag, der von der Ressource angeboten wird.
- Überwachung: Alle Ressourcenprotokolle, die Kundeninteraktionen mit Daten oder den Einstellungen des Diensts aufzeichnen. Ressourcenanbieter mit Überwachungsprotokollen versuchen, die relevantesten Überwachungsdaten bereitzustellen. Aus Sicht der Überwachungsstandards ist dies je nach Anwendungsfall jedoch möglicherweise nicht ausreichend. Wie oben erwähnt, sind die erfassten Elemente dynamisch, und Microsoft kann dies im Laufe der Zeit ändern, wenn neue Ressourcenprotokollkategorien verfügbar werden.
Die Kategoriegruppe „Überwachung“ ist eine Teilmenge der Kategoriegruppe „Alle“. Beide Kategorien werden jedoch vom Azure-Portal und der REST-API als separate Einstellungen betrachtet. Wenn Sie die Kategoriegruppe „Alle“ auswählen, werden auch ohne Auswahl der Kategoriegruppe „Überwachung“ alle Überwachungsprotokolle erfasst.
Die folgende Abbildung zeigt die Protokollkategoriegruppen auf der Seite " Diagnoseeinstellungen hinzufügen" .
Hinweis
Durch Aktivieren der Kategorie "Überwachung" in den Diagnoseeinstellungen für die Azure SQL-Datenbank wird die Überwachung für die Datenbank nicht aktiviert. Um die Datenbanküberwachung zu aktivieren, müssen Sie sie auf dem Überwachungsblatt für Azure-Datenbank aktivieren.
Aktivitätsprotokoll
Weitere Informationen finden Sie im Abschnitt "Aktivitätsprotokolleinstellungen" .
Zielorte
Plattformprotokolle und -metriken können an die Ziele in der folgenden Tabelle gesendet werden.
Zur Gewährleistung der Datensicherheit während der Übertragung werden alle Zielendpunkte so konfiguriert, dass sie TLS 1.2 unterstützen.
Bestimmungsort | BESCHREIBUNG |
---|---|
Log Analytics-Arbeitsbereich | Metriken werden in das Protokollformular konvertiert. Diese Option ist möglicherweise nicht für alle Ressourcentypen verfügbar. Wenn Sie sie an den Azure Monitor Logs-Speicher senden (der über Log Analytics durchsuchbar ist), können Sie sie in Abfragen, Benachrichtigungen und Visualisierungen mit vorhandenen Protokolldaten integrieren. |
Azure Storage-Konto | Das Archivieren von Protokollen und Metriken in einem Speicherkonto ist für Überwachung, statische Analyse oder Sicherung nützlich. Im Vergleich zu Azure Monitor-Protokollen oder einem Log Analytics-Arbeitsbereich ist Storage kostengünstiger, und die Protokolle können unbegrenzt aufbewahrt werden. |
Azure Event Hubs | Wenn Sie Protokolle und Metriken an Event Hubs senden, können Sie Daten an externe Systeme wie SIEMs von Drittanbietern und andere Log Analytics-Lösungen weiterleiten. |
Azure Monitor-Partnerlösungen | Es können spezielle Integrationen zwischen Azure Monitor und anderen Überwachungsplattformen, die nicht von Microsoft stammen, vorgenommen werden. Die Integration ist nützlich, wenn Sie bereits einen der Partner verwenden. |
Aktivitätsprotokolleinstellungen
Das Aktivitätsprotokoll verwendet eine Diagnoseeinstellung, verfügt aber über eine eigene Benutzeroberfläche, da es für das gesamte Abonnement und nicht für einzelne Ressourcen gilt. Die hier aufgeführten Zielinformationen gelten weiterhin. Weitere Informationen finden Sie im Azure-Aktivitätsprotokoll.
Anforderungen und Einschränkungen
In diesem Abschnitt werden Anforderungen und Einschränkungen erläutert.
Zeit, bis die Telemetrie ans Ziel gelangt
Sobald Sie eine Diagnoseeinstellung eingerichtet haben, sollte innerhalb von 90 Minuten der Datenfluss an die ausgewählten Ziele beginnen. Beim Senden von Protokollen an einen Log Analytics-Arbeitsbereich wird die Tabelle automatisch erstellt, wenn sie noch nicht vorhanden ist. Die Tabelle wird nur erstellt, wenn die ersten Protokolldatensätze empfangen werden. Wenn Sie innerhalb von 24 Stunden keine Informationen erhalten, liegt möglicherweise eines der folgenden Probleme vor:
- Es werden keine Protokolle generiert.
- Im zugrunde liegenden Routingmechanismus ist ein Fehler aufgetreten.
Wenn ein Problem vorliegt, können Sie versuchen, die Konfiguration zu deaktivieren und sie dann erneut zu aktivieren. Wenn das Problem weiterhin besteht, wenden Sie sich über das Azure-Portal an den Azure-Support.
Metriken als Quelle
Der Export von Metriken unterliegt gewissen Einschränkungen:
- Das Senden von mehrdimensionalen Metriken über Diagnoseeinstellungen wird derzeit nicht unterstützt. Metriken mit Dimensionen werden als vereinfachte eindimensionale Metriken exportiert und dimensionswertübergreifend aggregiert. Beispielsweise kann die IOReadBytes-Metrik auf einer Blockchain auf einer Knotenebene untersucht und diagrammiert werden. Beim Exportieren über die Diagnoseeinstellungen zeigt die exportierte Metrik jedoch alle gelesenen Bytes für alle Knoten an.
- Nicht alle Metriken können mit Diagnoseeinstellungen exportiert werden. Aufgrund von internen Einschränkungen nicht alle Metriken in Azure Monitor-Protokolle oder in Log Analytics exportiert werden. Weitere Informationen finden Sie in der Liste der unterstützten Metriken in der Spalte "Exportierbar".
Um diese Einschränkungen für bestimmte Metriken zu umgehen, können Sie sie mithilfe der Metrik-REST-API manuell extrahieren. Anschließend können Sie sie mithilfe der Azure Monitor Data Collector-API in Azure Monitor-Protokolle importieren.
Von Bedeutung
Diagnoseeinstellungen unterstützen keine Ressourcen-IDs mit Nicht-ASCII-Zeichen (z. B. „Preproduccón“). Weitere Informationen finden Sie unter "Problembehandlung".
Grenzen des Reiseziels
Alle Ziele für die Diagnoseeinstellungen müssen festgelegt werden, bevor Sie die Diagnoseeinstellungen erstellen. Das Ziel muss sich nicht in demselben Abonnement befinden wie die Ressource, die die Protokolle sendet, wenn der Benutzer, der die Einstellung festlegt, über die entsprechende rollenbasierte Zugriffssteuerung von Azure Zugriff auf beide Abonnements hat. Mit Azure Lighthouse ist es auch möglich, Diagnoseeinstellungen an einen Arbeitsbereich, an ein Speicherkonto oder an eine Event Hub-Instanz in einem anderen Microsoft Entra-Mandanten senden zu lassen.
In der folgenden Tabelle sind besondere Anforderungen für die einzelnen Ziele einschließlich regionaler Einschränkungen aufgeführt.
Bestimmungsort | Anforderungen |
---|---|
Log Analytics-Arbeitsbereich | Der Arbeitsbereich muss sich nicht in derselben Region wie die überwachte Ressource befinden. |
Speicherkonto | Verwenden Sie kein bestehendes Speicherkonto, in dem andere, nicht überwachungsrelevante Daten gespeichert sind. Durch das Aufteilen der Datentypen können Sie den Zugriff auf die Daten besser steuern. Wenn Sie das Aktivitätsprotokoll und Ressourcenprotokollen zusammen archivieren, können Sie dasselbe Speicherkonto verwenden, damit sich alle Überwachungsdaten an einem zentralen Ort befinden. Um Änderungen der Daten zu verhindern, senden Sie sie an unveränderlichen Speicher. Legen Sie die unveränderliche Richtlinie für das Speicherkonto fest, wie unter "Festlegen und Verwalten von Unveränderlichkeitsrichtlinien für Azure Blob Storage" beschrieben. Sie müssen alle Schritte in diesem verlinkten Artikel befolgen, einschließlich der Aktivierung des geschützten Schreibens von Append Blobs. Wenn die überwachte Ressource regional ist, muss sich das Speicherkonto in derselben Region wie die Ressource befinden. Diagnoseeinstellungen können nicht auf Speicherkonten zugreifen, wenn virtuelle Netzwerke aktiviert sind. Sie müssen zulassen, dass vertrauenswürdige Microsoft-Dienste diese Firewalleinstellung in Speicherkonten umgehen können, damit dem Azure Monitor-Diagnoseeinstellungendienst Zugriff auf Ihr Speicherkonto gewährt wird. Azure DNS-Zonenendpunkte (Vorschau) und alle Premium-Speicherkonten werden nicht als Protokoll- oder Metrikziel unterstützt. Alle Standardspeicherkonten werden unterstützt. |
Ereignis-Hubs | Die SAS-Richtlinie für den Namespace definiert die Berechtigungen für den Streamingmechanismus. Für das Streaming an Event Hubs werden Berechtigungen für das Verwalten, Senden und Lauschen benötigt. Wenn Sie der Diagnoseeinstellung das Streamingfeature hinzufügen möchten, müssen Sie in der Event Hubs-Autorisierungsregel über die ListKey-Berechtigung verfügen. Wenn die überwachte Ressource regional ist, muss sich der Event Hub-Namespace in derselben Region wie die Ressource befinden. Diagnoseeinstellungen können nicht auf Event-Hubs-Ressourcen zugreifen, wenn virtuelle Netzwerke aktiviert sind. Sie müssen zulassen, dass vertrauenswürdige Microsoft-Dienste diese Firewalleinstellung in Event Hubs umgehen können, damit dem Azure Monitor-Diagnoseeinstellungendienst Zugriff auf Ihre Event Hubs-Ressourcen gewährt wird. |
Partnerlösungen | Die Lösungen variieren je nach Partner. Ausführliche Informationen finden Sie in der Dokumentation zu Azure Native ISV Services . |
Diagnoseprotokolle für Application Insights
Wenn Sie Diagnoseprotokolle für Application Insights in einem Log Analytics-Arbeitsbereich speichern möchten, senden Sie die Protokolle nicht an denselben Arbeitsbereich, auf dem die Application Insights-Ressource basiert. Diese Konfiguration kann dazu führen, dass doppelte Telemetriedaten angezeigt werden, da Application Insights diese Daten bereits speichert. Senden Sie Ihre Application Insights-Protokolle an einen anderen Log Analytics-Arbeitsbereich.
Beachten Sie beim Senden von Application Insights-Protokollen an einen anderen Arbeitsbereich, dass Application Insights über Application Insight-Ressourcen auf Telemetriedaten zugreift (einschließlich mehrerer Log Analytics-Arbeitsbereiche). Beschränken Sie den Zugriff des Application Insights-Benutzers nur auf den Log Analytics-Arbeitsbereich, der mit der Application Insights-Ressource verknüpft ist. Legen Sie den Zugriffssteuerungsmodus auf "Arbeitsbereichsberechtigungen" fest , und verwalten Sie Berechtigungen über die rollenbasierte Zugriffssteuerung von Azure, um sicherzustellen, dass Application Insights nur Zugriff auf den Log Analytics-Arbeitsbereich hat, auf dem die Application Insights-Ressource basiert.
Kontrolle von Kosten
Es fallen Kosten für das Sammeln von Daten in einem Log Analytics-Arbeitsbereich an, also sammeln Sie nur die Kategorien, die Sie für jeden Dienst benötigen. Das Datenvolumen für Ressourcenprotokolle variiert erheblich von Dienst zu Dienst.
Sie sollten außerdem keine Plattformmetriken von Azure-Ressourcen sammeln, da diese Daten bereits in Metriken gesammelt werden. Konfigurieren Sie Ihre Diagnosedaten nur dann für die Sammlung von Metriken, wenn Sie Metrikdaten im Arbeitsbereich für komplexere Analysen mit Protokollabfragen benötigen. Diagnoseeinstellungen gestatten keine präzise Filterung von Ressourcenprotokollen.
Tipp
Strategien zum Reduzieren Ihrer Azure Monitor-Kosten finden Sie unter Kostenoptimierung und Azure Monitor.
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.