Transformationen für die Datensammlung in Azure Monitor
Mit Transformationen in Azure Monitor können Sie eingehende Daten filtern oder ändern, bevor sie an einen Log Analytics-Arbeitsbereich gesendet werden. Dieser Artikel enthält eine grundlegende Beschreibung von Transformationen und wie sie implementiert werden. Es bietet Links zu anderen Inhalten, um eine Transformation zu erstellen.
Transformationen werden in Azure Monitor in der Datenerfassungspipeline durchgeführt, nachdem die Datenquelle die Daten übermittelt hat und bevor sie an das Ziel gesendet werden. Die Datenquelle kann vor dem Senden von Daten eine eigene Filterung durchführen, verlässt sich dann aber bei der weiteren Bearbeitung auf die Transformation, bevor sie an das Ziel gesendet werden.
Transformationen werden in einer Datenerfassungsregel (DCR) definiert und verwenden eine Kusto Query Language (KQL)-Anweisung, die einzeln auf jeden Eintrag in den eingehenden Daten angewendet wird. Sie muss das Format der eingehenden Daten verstehen können und die Ausgabe in der Struktur der Zieltabelle erstellen.
Das folgende Diagramm veranschaulicht den Transformationsprozess für eingehende Daten und zeigt eine Beispielabfrage, die verwendet werden könnte. Weitere Informationen zum Aufbau von Transformationsabfragen finden Sie unter Struktur von Transformationen in Azure Monitor.
Gründe für die Verwendung von Transformationen
In der folgenden Tabelle werden die verschiedenen Ziele beschrieben, die Sie mit Transformationen erreichen können.
| Category | Details |
|---|---|
| Erstellen vertraulicher Daten | Möglicherweise haben Sie eine Datenquelle, die Informationen sendet, die Sie aus Datenschutz- oder Compliance-Gründen nicht speichern möchten. Filtern Sie vertrauliche Informationen. Filtern Sie ganze Zeilen oder bestimmte Spalten heraus, die vertrauliche Informationen enthalten. Verschleiern Sie sensible Informationen. Ersetzen Sie Informationen wie Ziffern in einer IP-Adresse oder Telefonnummer durch ein allgemeines Zeichen. An alternative Tabelle senden. Senden Sie vertrauliche Datensätze an eine alternative Tabelle mit einer anderen rollenbasierten Zugriffssteuerungskonfiguration (RBAC). |
| Reichern Sie Daten mit mehr oder berechneten Informationen an | Verwenden Sie eine Umwandlung, um Informationen zu Daten hinzuzufügen, die den Geschäftskontext bereitstellen oder die spätere Abfrage der Daten vereinfachen. Fügen Sie eine Spalte mit weiteren Informationen hinzu. Beispielsweise könnten Sie eine Spalte hinzufügen, die angibt, ob eine IP-Adresse in einer anderen Spalte intern oder extern ist. Fügen Sie geschäftsspezifische Informationen hinzu. Beispielsweise könnten Sie eine Spalte hinzufügen, die einen Unternehmensbereich basierend auf Standortinformationen in anderen Spalten angibt. |
| Reduzieren der Datenkosten | Da Ihnen für alle Daten, die an einen Log Analytics-Arbeitsbereich gesendet werden, Erfassungskosten in Rechnung gestellt werden, möchten Sie alle Daten herausfiltern, die Sie nicht benötigen, um Ihre Kosten zu senken. Entferne ganze Reihen. Sie verfügen möglicherweise über eine Diagnoseeinstellung zum Sammeln von Ressourcenprotokollen von einer bestimmten Ressource, benötigen jedoch nicht alle generierten Protokolleinträge. Erstellen Sie eine Transformation, die Datensätze herausfiltert, die einem bestimmten Kriterium entsprechen. Entfernen Sie eine Spalte aus jeder Zeile. Beispielsweise können Ihre Daten Spalten mit Daten enthalten, die redundant sind oder einen minimalen Wert haben. Erstellen Sie eine Transformation, die nicht benötigte Spalten herausfiltert. Analysieren Sie wichtige Daten aus einer Spalte. Möglicherweise haben Sie eine Tabelle mit wertvollen Daten in einer bestimmten Spalte vergraben. Verwenden Sie eine Transformation, um die wertvollen Daten in eine neue Spalte zu parsen und das Original zu entfernen. Senden bestimmter Zeilen an Basisprotokolle. Senden Sie Zeilen in Ihren Daten, die grundlegende Abfragefunktionen erfordern, an Basisprotokolltabellen, um die Erfassungskosten zu senken. |
| Formatieren von Daten für das Ziel | Sie haben möglicherweise eine Datenquelle, die Daten in einem Format sendet, das nicht mit der Struktur der Zieltabelle übereinstimmt. Verwenden Sie eine Transformation, um die Daten in das gewünschte Schema umzuformatieren. |
Unterstützte Tabellen
Unter Tabellen, die Transformationen in Azure Monitor-Protokollen unterstützen finden Sie eine Liste der Tabellen, die mit Transformationen verwendet werden können. Sie können auch den Azure Monitor-Datenverweis verwenden, der die Attribute für jede Tabelle auflistet, einschließlich der Unterstützung von Transformationen. Zusätzlich zu diesen Tabellen werden auch alle benutzerdefinierten Tabellen (Suffix von _CL) unterstützt.
- Alle Azure-Tabellen, die unter Tabellen, die Transformationen in Azure Monitor-Protokollen unterstützen. Sie können auch den Azure Monitor-Datenverweis verwenden, der die Attribute für jede Tabelle auflistet, einschließlich der Unterstützung von Transformationen.
- Jede benutzerdefinierte Tabelle, die für den Azure Monitor-Agent erstellt wurde. (MMA-benutzerdefinierte Tabelle kann keine Transformationen verwenden)
Erstellen einer Transformation
Abhängig von der Datenerfassungsmethode gibt es mehrere Methoden zum Erstellen von Transformationen. In der folgenden Tabelle sind Anleitungen für verschiedene Methoden zum Erstellen von Transformationen aufgeführt.
| Datensammlung | Verweis |
|---|---|
| Protokollerfassungs-API | Senden von Daten an Azure Monitor-Protokolle mithilfe der REST-API (Azure-Portal) Tutorial: Senden von Daten an Azure Monitor-Protokolle mithilfe der REST-API (Azure Resource Manager-Vorlagen) |
| Virtueller Computer mit dem Azure Monitor-Agent | Hinzufügen einer Transformation zum Azure Monitor-Protokoll |
| Kubernetes-Cluster mit Containererkenntnisse | Datentransformationen in Container Insights |
| Azure Event Hubs | Tutorial: Erfassen von Ereignissen aus Azure Event Hubs in Azure Monitor-Protokollen (Public Preview) |
Mehrere Ziele
Mit Transformationen können Sie Daten an mehrere Ziele in einem Log Analytics-Arbeitsbereich mit einer einzelnen DCR senden. Sie stellen für jedes Ziel eine KQL-Abfrage bereit, und die Ergebnisse jeder Abfrage werden an den entsprechenden Speicherort gesendet. Sie können verschiedene Datensätze an unterschiedliche Tabellen senden oder mehrere Abfragen verwenden, um verschiedene Datensätze an dieselbe Tabelle zu senden.
Sie können beispielsweise Ereignisdaten mithilfe der Protokollerfassungs-API an Azure Monitor senden. Die meisten Ereignisse sollten an eine Analysetabelle gesendet werden, in der sie regelmäßig abgefragt werden können, während Überwachungsereignisse an eine für Basisprotokolle konfigurierte benutzerdefinierte Tabelle gesendet werden sollten, um Ihre Kosten zu senken.
Wenn Sie mehrere Ziele verwenden möchten, müssen Sie derzeit entweder manuell eine neue DCR erstellen oder eine vorhandene bearbeiten. Im Abschnitt Beispiele finden Sie Beispiele für DCRs, die mehrere Ziele verwenden.
Wichtig
Derzeit müssen sich die Tabellen in der DCR im selben Log Analytics-Arbeitsbereich befinden. Verwenden Sie zum Senden aus einer einzelnen Datenquelle an mehrere Arbeitsbereiche mehrere DCRs, und konfigurieren Sie Ihre Anwendung so, dass die Daten an jeden gesendet werden.
Überwachen von Transformationen
Weitere Informationen zu Protokollen und Metriken, welche die Integrität und Leistung von Transformationen überwachen, finden Sie unter Überwachen und Problembehandlung bei der DCR-Datensammlung in Azure Monitor. Dies umfasst das Identifizieren von Fehlern, die in der KQL auftreten, und Metriken, um ihre Ausführungsdauer nachzuverfolgen.
Kosten für Transformationen
Zwar fallen für Transformationen selbst keine direkten Kosten an, doch 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 erfassten Daten um mehr als 50 % reduziert, wird Ihnen die Menge der gefilterten Daten, die 50 % übersteigt, in Rechnung gestellt.
Verwenden Sie die folgende Formel, um die auf Transformationen basierende Datenverarbeitungsgebühr zu berechnen:
[GB nach Transformationen herausgefiltert] – ([Von der Pipeline erfasste GB-Daten] / 2). Die folgende Tabelle enthält Beispiele.
| Von der Pipeline erfasste Daten | Durch Transformation gelöschte Daten | Vom Log Analytics-Arbeitsbereich erfasste Daten | Datenverarbeitungsgebühr | Erfassungsgebühr |
|---|---|---|---|---|
| 20 GB | 12 GB | 8 GB | 2 GB 1 | 8 GB |
| 20 GB | 8 GB | 12 GB | 0 GB | 12 GB |
1 Diese Gebühr schließt die Gebühr für Daten aus, die vom Log Analytics-Arbeitsbereich erfasst werden.
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 aktuellen Gebühren für die Erfassung und Aufbewahrung von Protokolldaten in Azure Monitor finden Sie unter Azure Monitor – Preise.
Wichtig
Wenn Azure Sentinel für den Log Analytics-Arbeitsbereich aktiviert ist, fallen unabhängig davon, wie viele Daten die Transformation filtert, keine Gebühren für die Filterung der Erfassung an.
Beispiele
Die folgenden Resource Manager-Vorlagen zeigen Beispiel-DCRs mit unterschiedlichen Mustern. Sie können diese Vorlagen als Ausgangspunkt zum Erstellen von DCRs mit Transformationen für Ihre eigenen Szenarien verwenden.
Einzelnes Ziel
Das folgende Beispiel ist eine DCR für den Azure Monitor-Agent, der Daten an die Syslog-Tabelle sendet. In diesem Beispiel filtert die Transformation die Daten nach Datensätzen mit einem error in der Meldung.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "singleDestinationDCR",
"apiVersion": "2021-09-01-preview",
"location": "eastus",
"properties": {
"dataSources": {
"syslog": [
{
"name": "sysLogsDataSource",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"auth",
"authpriv",
"cron",
"daemon",
"mark",
"kern",
"mail",
"news",
"syslog",
"user",
"uucp"
],
"logLevels": [
"Debug",
"Critical",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Syslog"
],
"transformKql": "source | where message has 'error'",
"destinations": [
"centralWorkspace"
]
}
]
}
}
]
}
Mehrere Azure-Tabellen
Das folgende Beispiel ist eine DCR für Daten aus der Protokollerfassungs-API, die Daten sowohl an die Syslog- als auch an die SecurityEvent-Tabelle sendet. Diese DCR erfordert jeweils einen separaten dataFlow mit einer anderen transformKql und einem anderen OutputStream für beide. In diesem Beispiel werden alle eingehenden Daten an die Syslog-Tabelle gesendet, während schädliche Daten auch an die SecurityEvent-Tabelle gesendet werden. Wenn Sie die schädlichen Daten in beiden Tabellen nicht replizieren möchten, können Sie der ersten Abfrage eine where-Anweisung hinzufügen, um diese Datensätze zu entfernen.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, Message = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | where (AdditionalContext has 'malicious traffic!' | project TimeGenerated = Time, Computer, Subject = AdditionalContext",
"outputStream": "Microsoft-SecurityEvent"
}
]
}
}
]
}
Kombination von Azure- und benutzerdefinierten Tabellen
Das folgende Beispiel ist eine DCR für Daten aus der Protokollerfassungs-API, die Daten in einem anderen Format sowohl an die Syslog-Tabelle als auch an eine benutzerdefinierte Tabelle senden. Diese DCR erfordert jeweils einen separaten dataFlow mit einer anderen transformKql und einem anderen OutputStream für beide. Bei der Verwendung von benutzerdefinierten Tabellen ist es wichtig sicherzustellen, dass das Schema des Ziels (Ihre benutzerdefinierte Tabelle) die benutzerdefinierten Spalten (Vorgehensweise zum Hinzufügen oder Löschen benutzerdefinierter Spalten) enthält, die dem Schema der von Ihnen gesendeten Datensätze entsprechen. Wenn Ihr Datensatz beispielsweise ein Feld namens SyslogMessage aufweist, die benutzerdefinierte Zieltabelle jedoch nur „TimeGenerated“ und „RawData“ enthält, erhalten Sie ein Ereignis in der benutzerdefinierten Tabelle, in dem nur das Feld „TimeGenerated“ aufgefüllt und das Feld „RawData“ leer ist. Das SyslogMessage-Feld wird gelöscht, da das Schema der Zieltabelle kein Zeichenfolgenfeld namens SyslogMessage enthält.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources" : [
{
"type": "Microsoft.Insights/dataCollectionRules",
"name": "multiDestinationDCR",
"location": "eastus",
"apiVersion": "2021-09-01-preview",
"properties": {
"dataCollectionEndpointId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers//Microsoft.Insights/dataCollectionEndpoints/my-dce",
"streamDeclarations": {
"Custom-MyTableRawData": {
"columns": [
{
"name": "Time",
"type": "datetime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "AdditionalContext",
"type": "string"
}
]
}
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "clv2ws1"
},
]
},
"dataFlows": [
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | project TimeGenerated = Time, Computer, SyslogMessage = AdditionalContext",
"outputStream": "Microsoft-Syslog"
},
{
"streams": [
"Custom-MyTableRawData"
],
"destinations": [
"clv2ws1"
],
"transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
"outputStream": "Custom-MyTable_CL"
}
]
}
}
]
}