Transformationen in Azure Monitor

Transformationen in Azure Monitor filtern oder ändern eingehende Daten, bevor sie an einen Log Analytics-Arbeitsbereich gesendet werden. Transformationen werden nach der Übermittlung der Daten und vor dem Senden an das Ziel ausgeführt. Sie werden in einer Datensammlungsregel (Data Collection Rule, DCR) definiert.

Standardtransformationen verwenden eine Kusto Query Language (KQL)-Anweisung , die einzeln auf jeden Eintrag in den eingehenden Daten angewendet wird. Mehrstufige Transformationen erweitern dieses Modell mit einer Pipeline deklarativer Prozessoren, wobei eine KQL-Abfrage einer von vielen verfügbaren Prozessortypen in der Transformationskette ist.

Das folgende Diagramm veranschaulicht den Transformationsprozess für eingehende Daten und zeigt eine Beispielabfrage, die verwendet werden könnte. In diesem Beispiel werden nur Datensätze erfasst, in denen die message Spalte das Wort error enthält.

Diagramm, das die Erfassungszeittransformation für eingehende Daten zeigt.

Unterstützte Tabellen

Die folgenden Tabellen in einem Log Analytics-Arbeitsbereich unterstützen Transformationen.

Erstellen einer Transformation

Einige Datensammlungsszenarien unterstützen das Hinzufügen einer Transformation über das Azure-Portal, aber die meisten Szenarien erfordern das Erstellen eines neuen DCR mithilfe der JSON-Definition oder das Hinzufügen einer Transformation zu einem vorhandenen DCR. Weitere Informationen finden Sie unter Erstellen einer Transformation in Azure Monitor für verschiedene Optionen und Best Practices und Beispiele für Transformationen in Azure Monitor für Beispieltransformationsabfragen allgemeiner Szenarien.

Mehrstufige Transformationen (Vorschau)

Von Bedeutung

Mehrstufige Transformationen befinden sich derzeit in der öffentlichen Vorschau. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Standardtransformationen wenden bei der Erfassung eingehender Daten eine einzelne KQL-Abfrage an. Mehrstufige Transformationen erweitern dieses Modell, indem Sie eine Verarbeitungspipeline definieren können, die aus mehreren geordneten Verarbeitungsphasen besteht und als Datenflüsse über das System angewendet wird.

Bei mehrstufigen Transformationen definiert ein DCR eine Datenverarbeitungspipeline anstelle eines einzelnen Transformationsschritts. Daten fließen durch die folgenden Phasen:

  1. Datensammlung. Azure Monitor Agent (AMA) sammelt Daten aus der Ressource basierend auf den Datenquelleneinstellungen im DCR.
  2. Clientseitige Verarbeitung. Transformationen werden lokal auf dem Agent ausgeführt, bevor Daten über das Netzwerk gesendet werden. Die Transformation gilt für die Daten in der rohen Form, die sich von der Standardtabellendarstellung unterscheiden können.
  3. Verarbeitung von Erfassungszeit. Nachdem Daten Azure Monitor erreicht haben, werden Transformationen während der Aufnahme angewendet, bevor die Daten in die Zieltabelle in Log Analytics geschrieben werden. Diese Transformation gilt, nachdem die Daten vollständig schematisiert und bereichert wurden.
  4. Datenübermittlung. Verarbeitete Protokolle werden an ihr endgültiges Ziel übermittelt.

Processors

Transformationen in mehrstufigen DCRs werden mithilfe von Prozessoren definiert – kleine, deklarative Bausteine, die jeweils einen bestimmten Vorgangstyp ausführen. Prozessoren weisen die folgenden Merkmale auf:

  • Zusammensetzbar. Mehrere Prozessoren können in einer einzigen Transformation miteinander verkettet werden.
  • Bestellt. Prozessoren werden sequenziell in der in der Transformation definierten Reihenfolge ausgeführt.
  • Phasenunabhängig. Derselbe Prozessortyp kann in verschiedenen Datenquellen, Phasen oder Szenarien mit einigen Einschränkungen während der Vorschau verwendet werden.

Jede Transformation beginnt mit einem Headerprozessor , der Rohdaten in ein bekanntes schematisiertes tabellarisches Format konvertiert. Nach dem Header können Sie zusätzliche Prozessoren zum Filtern, Zuordnen, Analysieren, Aggregieren, Anreichern oder Anwenden von KQL-Ausdrücken auf die Daten verketten.

Die folgenden Prozessorfamilien sind verfügbar:

Familie Processors Description
Header header.Syslog, header.WindowsEvents, header.TextLog, header.StandardStream, , header.CustomStreamund andere Strukturieren Sie Rohdaten in eine Tabellenform. Muss der erste Prozessor sein.
Filter filter.Basic Verwerfen Sie Datensätze basierend auf der Bewertung einer Bedingung.
Map map.Rename, map.Drop Spalten umbenennen, umwandeln oder löschen.
Parse parse.JsonPath, parse.XmlPathparse.CEFAttribute Extrahieren Sie Felder aus JSON-, XML- oder CEF-formatierten Zeichenfolgen.
Aggregation aggregate.Basic Zusammenfassen von Datensätzen mithilfe von Aggregationsoperatoren mit Gruppierungsdimensionen.
Anreicherung enrich.DNSLookup Suchen Sie eine IP-Adresse, und fügen Sie eine DNS-Namensspalte hinzu.
Benutzerdefinierte Transformation transform.KQL Wenden Sie einen beliebigen KQL-Ausdruck an. Nur erfassungsseitig.

Die vollständige Prozessorreferenz, einschließlich Konfigurationsschemas und Ausgabeschemas, finden Sie unter DCR-Struktur – Transformationen.

Transformationen auf Client-Seite vs. auf der Ingestion-Seite

Jede Transformation wird einer bestimmten Verarbeitungsphase zugewiesen. Diese Unterscheidung bestimmt, wo die Berechnung erfolgt, welche Daten über das Netzwerk gesendet werden und welche Kosten frühzeitig optimiert werden können.

Aspect Clientseitig Aufnahmezeit
Zuordnung Datenquelle (dataSources) Datenfluss (dataFlows)
Läuft auf Azure Monitor Agent (VM) Azure Monitor-Dienst
Kopfzeilenprozessor Datenquellenspezifisch (z. B header.Syslog. ) header.StandardStream oder header.CustomStream
Kostenvorteil Reduziert die Netzwerk- und Aufnahmekosten durch Filtern/Aggregieren, bevor Daten die Ressource verlassen. Gilt, nachdem Daten schematisiert und mit zusätzlichen Tabellenspalten erweitert wurden

Ein einzelner DCR kann clientseitige und Erfassungszeittransformationen kombinieren. Die Ausgabe der clientseitigen Phase wird automatisch zur Eingabe in die Erfassungszeitphase.

Überlegungen zu mehrstufigem DCR

  • Mehrstufige Transformationen erfordern API-Version 2025-05-11 oder höher. Der transformations Abschnitt und die transform Eigenschaft für Datenquellen und Datenflüsse werden von früheren API-Versionen nicht erkannt.
  • Die Eigenschaft transform ist pro Datenfluss mit transformKql gegenseitig ausschließend. Ein DCR kann alte und neue Datenflüsse über verschiedene Datenströme hinweg kombinieren.
  • Während der Vorschau müssen Sie den Header der nachgelagerten Transformation manuell auf das Ergebnis der vorgelagerten Transformation abstimmen. Wenn Sie beispielsweise eine Aggregation auf einen rohen Datenstrom von Windows-Ereignissen anwenden, ist das Ergebnis möglicherweise nicht mit der entsprechenden Ereignistabelle kompatibel, und die Aufnahmezeittransformation sollte mit einem benutzerdefinierten Datenstromheader beginnen.

Entwurfsansatz für mehrstufige Verarbeitung

Führen Sie beim Entwerfen eines mehrstufigen DCR die folgenden Schritte aus:

  1. Bewerten Sie Datenquellen und -ziele. Identifizieren Sie Ihre Datenquellentypen und entscheiden Sie, ob jeder in der Standardtabelle oder in einer benutzerdefinierten Tabelle landet.
  2. Identifizieren der Aggregationsanforderungen. Aggregierte Protokolle sollten zu einer separaten Tabelle wechseln, da sich ihre Form vom unformatierten Formular unterscheidet.
  3. Planen Sie die differenzierte Verarbeitung. Wenn Sie Teile derselben Protokolle unterschiedlich verarbeiten müssen, erstellen Sie mehrere Datenquellen desselben Typs mit unterschiedlichen Sammlungseinstellungen, und wenden Sie jeweils unterschiedliche clientseitige Transformationen an.
  4. Erstellen Sie clientseitige Transformationen. Verwenden Sie Standarddatenströme (Microsoft-*), wenn die Ausgabe das Header-Schema beibehält, oder benutzerdefinierte Datenströme (Custom-*), wenn dies nicht der Fall ist. Definieren von benutzerdefinierten Datenströmen in streamDeclarations.
  5. Definieren von Datenflüssen. Erstellen Sie für jeden Datenstrom einen Datenfluss. Verwenden Sie Datenflüsse zum Erfassungszeitpunkt, um einen einzelnen Datenstrom auf mehrere Zieltabellen aufzuteilen, indem Sie für jeden Datenfluss unterschiedliche Filterkriterien anwenden.

Arbeitsbereichstransformations-DCR

Transformationen werden in einer Datensammlungsregel (Data Collection Rule, DCR) definiert. Es gibt jedoch immer noch Datensammlungen in Azure Monitor, die noch keine DCR verwenden. Beispiele hierfür sind Ressourcenprotokolle, die von Diagnoseeinstellungen gesammelt werden, und Anwendungsdaten, die von Application Insights gesammelt werden.

Die Datensammlungsregel (DCR) für die Arbeitsbereichstransformation ist eine spezielle DCR, die direkt auf einen Log Analytics-Arbeitsbereich angewendet wird. Der Zweck dieses DCR besteht darin, Transformationen für Daten durchzuführen, die noch keinen DCR für die Datensammlung verwenden und somit keine Möglichkeit haben, eine Transformation zu definieren.

Für jeden Arbeitsbereich kann nur eine Arbeitsbereichs-DCR vorhanden sein. Diese kann jedoch Transformationen für eine beliebige Anzahl unterstützter Tabellen enthalten. Diese Transformationen werden auf alle Daten angewendet, die an diese Tabellen gesendet werden, es sei denn, diese Daten stammen von einem anderen DCR.

Diagramm, das den Vorgang der Arbeitsbereichstransformation DCR zeigt.

Beispielsweise wird die Ereignistabelle verwendet, um Ereignisse von virtuellen Windows-Computern zu speichern. Wenn Sie eine Transformation in der Arbeitsbereichstransformation DCR für die Ereignistabelle erstellen, wird sie auf Ereignisse angewendet, die von virtuellen Computern gesammelt werden, auf denen der Log Analytics-Agent1 ausgeführt wird, da dieser Agent keinen DCR verwendet. Die Transformation würde von allen Daten ignoriert, die vom Azure Monitor-Agent (AMA) gesendet werden, da sie eine DCR für die Definition der Datensammlung verwendet. Sie können weiterhin eine Transformation mit dem Azure Monitor-Agent verwenden. Jedoch würden Sie diese Transformation in die DCR einschließen, die dem Agent zugeordnet ist, und nicht in die Arbeitsbereichs-DCR der Transformation.

Diagramm, das DCR-Standardtransformationen mit der Arbeitsbereichs-DCR der Transformation vergleicht.

1 Der Log Analytics-Agent ist veraltet, aber einige Umgebungen verwenden sie möglicherweise noch. Es ist nur ein Beispiel für eine Datenquelle, die keine DCR verwendet.

Azure Monitor-Pipelinetransformationen

Azure Monitor Pipelinedatentransformationen bieten ähnliche Funktionen wie clientseitige Transformationen in Azure Monitor. Beide ermöglichen es Ihnen, eine KQL-Abfrage auf eingehende Daten anzuwenden, um diese Daten zu filtern oder zu ändern, bevor sie an den nächsten Schritt im Datenfluss gesendet wird.

Azure Monitor-Transformationen zur Erfassungszeit werden erst ausgeführt, nachdem die Daten von Azure Monitor empfangen wurden, jedoch bevor sie in den Log Analytics-Arbeitsbereich aufgenommen werden. Azure Monitor-Pipelinetransformationen werden weiter oben im Datenfluss angewendet, sodass datenstrukturiert und gefiltert werden können, bevor die Daten an Azure Monitor gesendet werden. Dies macht Pipelinetransformationen nützlich, um Datenvolumen und Netzwerkbandbreite beim Senden von Daten aus Edge- oder Multicloud-Umgebungen zu reduzieren.

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen Azure Monitor Pipelinetransformationen und Azure Monitor Erfassungszeittransformationen zusammengefasst:

Merkmal Azure Monitor Pipeline Transformationen Azure Monitor-Transformationen zur Erfassungszeit
Bei Anwendung Vor dem Senden von Daten an Azure Monitor Nachdem Daten von Azure Monitor empfangen wurden.
Bevor sie im Log Analytics-Arbeitsbereich gespeichert wird
Definition Definiert in Datenflüssen in der Azure Monitor-Pipeline Definiert in Data Collection Rules (DCRs) in Azure Monitor
Language Kusto-Abfragesprache (KQL) Kusto-Abfragesprache (KQL)
Aggregationen werden unterstützt? Yes Nein
Wird die Vorlage unterstützt? Yes Nein

Die in Azure Monitor aufgenommenen Daten sind eine Kombination aus der Pipelinetransformation und allen nachfolgenden Azure Monitor-Erfassungszeittransformationen. Die einzige Anforderung besteht darin, dass das Ausgabeschema der Pipelinetransformation mit dem Eingabeschema übereinstimmen muss, das von der Azure Monitor-Erfassungszeittransformation erwartet wird. Zwar können Sie Daten in beiden Transformationen filtern, doch ist es in der Regel effizienter, Daten in den Pipelinetransformationen zu filtern, da dadurch die Menge der über das Netzwerk gesendeten Daten reduziert wird. Das Schema der Datenausgabe durch die Azure Monitor Erfassungszeittransformation muss mit dem Schema der Zieltabelle im Log Analytics Arbeitsbereich übereinstimmen.

Diagramm, das den Datenfluss von der Pipelinetransformation zu Azure Monitor-Transformation in den Log Analytics-Arbeitsbereich zeigt.

Kosten für Transformationen

Die Verarbeitung von Protokollen (Transformieren und Filtern) in der Azure Monitor-Cloudpipeline hat unterschiedliche Auswirkungen auf die Abrechnung, abhängig vom Typ der Tabelle, in die Daten in einem Log Analytics-Arbeitsbereich aufgenommen werden.

Hilfsprotokolle

Hilfsprotokolle verursachen Kosten für verarbeitete Daten und für Daten, die in einen Log Analytics-Arbeitsbereich aufgenommen werden. Die Datenverarbeitungsgebühr gilt für alle eingehenden Daten, die vom Azure Monitor empfangen werden, wenn das Ziel in einem Log Analytics Arbeitsbereich eine Tabelle mit Hilfsprotokollen ist. Dies schließt die Datenmenge ein, die von jeder Azure Monitor-Erfassungszeittransformationen verarbeitet wird. Die Datenerfassungsgebühr gilt nur für die Daten nach der Erfassungszeittransformation, die an eine Tabelle mit Hilfsprotokollen übermittelt wurde. Transformationen können entweder die Größe der Daten vergrößern oder verkleinern.

Die folgende Tabelle enthält einige Beispiele:

Eingehende Datengröße Gelöschte oder durch Transformation hinzugefügte Daten In einem Log Analytics-Arbeitsbereich als Zusatzprotokolltabelle erfasste Daten Verrechenbare GB bei der Datenverarbeitung Datenaufnahme abrechnungsfähige GB
20 GB 12 GB verloren 8 GB 20 GB 8 GB
20 GB 8 GB gedroppt 12 GB 20 GB 12 GB
20 GB 4 GB hinzugefügt 24 GB 20 GB 24 GB

Siehe Azure Monitor-Preise für Preise für die Protokollverarbeitung und Protokolldatenaufnahme.

Analyse- oder Standardprotokolle

Bei Analyse- oder Standardprotokollen entstehen Transformationen selbst normalerweise keine Kosten, aber die folgenden Szenarien können zu zusätzlichen Gebühren führen:

  • Wenn eine Transformation die Größe der eingehenden Daten erhöht, z. B. durch Hinzufügen einer berechneten Spalte, wird Ihnen die Standarderfassungsrate für die zusätzlichen Daten in Rechnung gestellt.
  • Wenn eine Transformation die aufgenommenen Daten um mehr als 50%reduziert, werden Sie für die Menge der gefilterten Daten über 50%belastet.

Verwenden Sie die folgende Formel, um die auf Transformationen basierende Datenverarbeitungsgebühr zu berechnen:

[Durch Transformation verlorene Daten in GB] - ([Größe der eingehenden Daten in GB] / 2).

Die folgende Tabelle enthält Beispiele.

Eingehende Datengröße Gelöschte oder durch Transformation hinzugefügte Daten In den Log Analytics-Arbeitsbereich aufgenommene Daten als eine Analyse- oder Standardprotokolltabelle Verrechenbare GB bei der Datenverarbeitung Datenaufnahme abrechnungsfähige GB
20 GB 12 GB verloren 8 GB 2 GB 8 GB
20 GB 8 GB gedroppt 12 GB 0,0 GB 12 GB
20 GB 4 GB hinzugefügt 24 GB 0,0 GB 24 GB

Um diese Gebühr zu vermeiden, sollten erfasste Daten über alternative Methoden gefiltert werden, bevor Transformationen angewendet werden. Auf diese Weise können Sie die Menge der von Transformationen verarbeiteten Daten reduzieren und somit alle zusätzlichen Kosten minimieren.

Informationen zu den Preisen für die Protokollverarbeitung und die Erfassung von Protokolldaten finden Sie unter Azure Monitor .

Von Bedeutung

Wenn Microsoft Sentinel für den Log Analytics-Arbeitsbereich aktiviert ist, gibt es keine Kosten für die Transformation in Analytics-Tabellen, unabhängig davon, wie viele Daten die Transformationsfilter filtern.