Datentransformationen in Container Insights
In diesem Artikel wird beschrieben, wie Datentransformationen in Container Insights implementiert werden. Transformationen in Azure Monitor ermöglichen es Ihnen, Daten zu verändern oder zu filtern, bevor sie in Ihrem Log Analytics-Arbeitsbereich erfasst werden. Sie ermöglichen es Ihnen, Aktionen wie das Filtern von Daten auszuführen, die in Ihrem Cluster gesammelt werden, um Kosten zu sparen oder eingehende Daten zu verarbeiten, um Ihre Datenabfragen zu unterstützen.
Wichtig
Die Artikel Konfigurieren der Protokollsammlung in Container Insights und Filtern der Protokollsammlung in Container Insights beschreiben Standardkonfigurationseinstellungen zum Konfigurieren und Filtern der Datenerfassung für Container Insights. Sie sollten alle erforderlichen Konfigurationen mit diesen Features ausführen, bevor Sie Transformationen verwenden. Verwenden Sie eine Transformation, um Filterung oder andere Datenkonfigurationen durchzuführen, die Sie nicht mit den Standardkonfigurationseinstellungen ausführen können.
Datensammlungsregel
Transformationen werden in Datensammlungsregeln (Data Collections Rules, DCRs) implementiert, die zum Konfigurieren der Datensammlung in Azure Monitor verwendet werden. Dieser Artikel beschreibt die DCR, die automatisch erstellt wird, wenn Sie Container Insights in einem Cluster aktivieren. Zum Erstellen einer Transformation müssen Sie eine der folgenden Aktionen ausführen:
- Neuer Cluster. Verwenden Sie eine vorhandene ARM-Vorlage , um das Onboarding eines AKS-Cluster in Container Insights durchzuführen. Ändern Sie die Datensammlungsregel in dieser Vorlage mit der erforderlichen Konfiguration, einschließlich einer Transformation, die einem der folgenden Beispiele ähnelt.
- Vorhandene DCR. Nachdem das Onboarding eines Clusters in Container Insights durchgeführt und die Erfassung konfiguriert wurde, bearbeiten Sie die Datensammlungsregel, um eine Transformation mithilfe einer der Methoden einzuschließen, die Sie unter Bearbeitung von Datensammlungsregeln finden.
Hinweis
Für die Bearbeitung von DCRs ist derzeit eine minimale Benutzeroberfläche vorhanden, die zum Hinzufügen von Transformationen erforderlich ist. In den meisten Fällen müssen Sie die DCR manuell bearbeiten. In diesem Artikel wird die zu implementierende DCR-Struktur beschrieben. Weitere Details zum Implementieren dieser Struktur finden Sie unter Erstellen und Bearbeiten von Datensammlungsregeln (Data Collection Rules, DCRs) in Azure Monitor.
Datenquellen
Im Abschnitt der Datenquellen einer Datensammlungsregel werden die verschiedenen Typen eingehender Daten definiert, die von der Datensammlungsregel verarbeitet werden. Für Container Insights ist dies die Container Insights-Erweiterung, die einen oder mehrere vordefinierte streams enthält, die mit dem Präfix Microsoft- beginnen.
Die Liste der Container Insights-Streams in der Datensammlungsregel ist von der Kostenvoreinstellung abhängig, die Sie für den Cluster ausgewählt haben. Wenn Sie alle Tabellen sammeln, verwendet die Datensammlungsregel den Microsoft-ContainerInsights-Group-Default-Stream. Dies ist ein Gruppenstream, der alle unter Streamwerte aufgeführten Streams enthält. Sie müssen dies in individuelle Streams ändern, wenn Sie eine Transformation verwenden möchten. Alle anderen Kostenvoreinstellungen verwenden bereits einzelne Datenströme.
Der folgende Beispielcode zeigt den Microsoft-ContainerInsights-Group-Default-Stream. Ein Beispiel für die Verwendung einzelner Streams finden Sie in den Beispiel-DCRs.
"dataSources": {
"extensions": [
{
"streams": [
"Microsoft-ContainerInsights-Group-Default"
],
"name": "ContainerInsightsExtension",
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"namespaces": null,
"enableContainerLogV2": true
}
}
}
]
}
Datenflüsse
Im Abschnitt der Datenflüsse einer Datensammlungsregel werden Streams mit Zielen abgeglichen, die im Abschnitt destinations der Datensammlungsregel definiert sind. Tabellennamen müssen für bekannte Streams nicht angegeben werden, wenn die Daten an die Standardtabelle gesendet werden. Die Streams, für die keine Transformation erforderlich ist, können in einem einzigen Eintrag gruppiert werden, der nur das Arbeitsbereichsziel enthält. Jeder wird an seine Standardtabelle gesendet.
Erstellen Sie einen separaten Eintrag für Streams, die eine Transformation erfordern. Dieser sollte das Arbeitsbereichsziel und die Eigenschaft transformKql enthalten. Wenn Sie Daten an eine alternative Tabelle senden, müssen Sie die Eigenschaft outputStream einschließen, die den Namen der Zieltabelle angibt.
Das folgende Beispiel zeigt den dataFlows-Abschnitt für einen einzelnen Stream mit einer Transformation. Weitere Informationen zu mehreren Streams einer einzelnen Datensammlungsregel finden Sie in den Beispiel-DCRs.
"dataFlows": [
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where PodNamespace == 'kube-system'"
}
]
Beispiel-DCRs
Filtern von Daten
Im ersten Beispiel werden Daten aus dem ContainerLogV2 basierend auf der Spalte LogLevel gefiltert. Es werden nur Datensätze mit einem LogLevel von error oder critical erfasst, da dies die Einträge sind, die Sie möglicherweise zum Warnen und Identifizieren von Problemen im Cluster verwenden können. Das Erfassen und Speichern anderer Ebenen wie info und debug generiert Kosten ohne signifikanten Wert.
Sie können diese Datensätze mit der folgenden Protokollabfrage abrufen.
ContainerLogV2 | where LogLevel in ('error', 'critical')
Diese Logik ist im folgenden Diagramm dargestellt.
In einer Transformation wird der Tabellenname source verwendet, um die eingehenden Daten darzustellen. Es folgt die geänderte Abfrage, die in der Transformation verwendet werden soll.
source | where LogLevel in ('error', 'critical')
Das folgende Beispiel zeigt diese Transformation, die der Container Insights-DCR hinzugefügt wurde. Beachten Sie, dass ein separater Datenfluss für Microsoft-ContainerLogV2 verwendet wird, da dies der einzige eingehende Stream ist, auf den die Transformation angewendet werden soll. Ein separater Datenfluss wird für die anderen Streams verwendet.
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
}
],
},
}
Senden von Daten an verschiedene Tabellen
Im obigen Beispiel werden nur Datensätze mit einem LogLevel von error oder critical erfasst. Eine alternative Strategie, anstatt diese Datensätze überhaupt nicht zu erfassen, besteht darin, sie in einer alternativen Tabelle zu speichern, die für Basisprotokolle konfiguriert ist.
Für diese Strategie sind zwei Transformationen erforderlich. Die erste Transformation sendet die Datensätze mit einem LogLevel von error oder critical an die Standardtabelle. Die zweite Transformation sendet die anderen Datensätze an eine benutzerdefinierte Tabelle mit dem Namen ContainerLogV2_CL. Die jeweiligen Abfragen werden unten mithilfe von source für die eingehenden Daten angezeigt, wie im vorherigen Beispiel beschrieben.
# Return error and critical logs
source | where LogLevel in ('error', 'critical')
# Return logs that aren't error or critical
source | where LogLevel !in ('error', 'critical')
Diese Logik ist im folgenden Diagramm dargestellt.
Wichtig
Bevor Sie die DCR in diesem Beispiel installieren, müssen Sie eine neue Tabelle mit demselben Schema wie ContainerLogV2 erstellen. Weisen Sie ihr den Namen ContainerLogV2_CL zu, und konfigurieren Sie sie für Basisprotokolle.
Das folgende Beispiel zeigt diese Transformation, die der Container Insights-DCR hinzugefügt wurde. Es gibt zwei Datenflüsse für Microsoft-ContainerLogV2 in dieser DCR, einen für jede Transformation. Der erste sendet an die Standardtabelle, und Sie müssen keinen Tabellennamen angeben. Der zweite erfordert die outputStream-Eigenschaft, um die Zieltabelle anzugeben.
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel !in ('error','critical')",
"outputStream": "Custom-ContainerLogV2_CL"
}
],
},
}
Nächste Schritte
- Lesen Sie mehr über Transformationen und Datensammlungsregeln in Azure Monitor.