Freigeben über


Beispiele für Datenerfassungsregeln (DCR) in Azure Monitor

Dieser Artikel enthält Beispiele für Datensammlungsregeln (DCRs) für gängige Datensammlungsszenarien in Azure Monitor. Sie können diese DCR-Definitionen nach Bedarf für Ihre Umgebung ändern und die DCR anhand der Anleitung in Erstellen oder Bearbeiten einer Datensammelregel erstellen. Sie können die grundlegenden Strategien in diesen Beispielen auch verwenden und kombinieren, um DCRs für andere Szenarien zu erstellen.

Diese Beispiele erfordern die Kenntnis der DCR-Struktur, wie in Struktur einer Datensammelregel in Azure Monitor beschrieben. Mehrere können über das Azure-Portal konfiguriert werden, ohne dass detaillierte Kenntnisse der DCR-Struktur erforderlich sind. Verwenden Sie diese Beispiele, wenn Sie mit der DCR-Definition selbst arbeiten müssen, um erweiterte Konfigurationen durchzuführen oder die Erstellung von DCRs zu automatisieren.

Jedes dieser Beispiele konzentriert sich auf eine bestimmte Datenquelle, obwohl Sie mehrere Datenquellen unterschiedlichen Typs in einer einzigen DCR kombinieren können. Fügen Sie jeweils einen Datenfluss ein, um die Daten an das entsprechende Ziel zu senden. Es gibt keinen funktionalen Unterschied zwischen der Kombination mehrerer Datenquellen in einer einzigen DCR oder der Erstellung separater DCRs für jede Datenquelle. Die Wahl hängt von Ihren Anforderungen an die Verwaltung und Überwachung der Datenerfassung ab.

Hinweis

Die in diesem Artikel gezeigten Beispiele liefern das für die Erstellung der DCR erforderliche Quell-JSON. Nach der Erstellung verfügt der DCR über zusätzliche Eigenschaften, wie in Struktur einer Datensammlungsregel in Azure Monitor beschrieben.

DCRs für den Azure Monitor-Agent

Der Azure Monitor-Agent wird auf VMs, VM Scale Sets und Kubernetes-Clustern ausgeführt. Er unterstützt VM Insights und Containereinblicke und unterstützt verschiedene Szenarien zur Datensammlung für VMs, die in Datensammlung mit Azure Monitor-Agent beschrieben werden.

Die folgenden Beispiele zeigen DCRs für die Erfassung verschiedener Arten von Daten mit dem Azure Monitor-Agent.

Windows-Ereignisse

DCRs für Windows-Ereignisse verwenden die Datenquelle windowsEventLogs mit dem eingehenden Stream Microsoft-Event. Das Schema dieses Streams ist bekannt, so dass es in diesem dataSources-Abschnitt nicht definiert werden muss. Die zu sammelnden Ereignisse werden in der Eigenschaft xPathQueries angegeben. Unter Sammeln von Windows-Ereignissen mit dem Azure Monitor-Agent finden Sie weitere Einzelheiten zur Verwendung von XPaths, um die spezifischen Daten zu filtern, die Sie sammeln möchten. Für den Anfang können Sie die Anleitung in diesem Artikel verwenden, um eine DCR über das Azure-Portal zu erstellen und dann das JSON mithilfe der Anleitung unter DCR-Definition zu inspizieren.

Sie können der Eigenschaft dataFlows eine Transformation für berechnete Spalten und zum weiteren Filtern von Daten hinzufügen, aber Sie sollten XPaths verwenden, um die Daten so weit wie möglich im Agent zu filtern, um effizient zu sein und potenzielle Datenerfassungsgebühren zu vermeiden.

Die folgende Beispiel-DCR führt die folgenden Aktionen aus:

  • Erfasst Windows-Anwendungs- und Systemereignisse mit den Fehlerstufen Warnung, Fehler oder Kritisch.
  • Sendet Daten an die Ereignistabelle im Arbeitsbereich.
  • Verwendet eine einfache Transformation eines source, die keine Änderungen an den eingehenden Daten vornimmt.
{
    "location": "eastus",
    "properties": {
      "dataSources": {
        "windowsEventLogs": [
          {
            "name": "eventLogsDataSource",
            "streams": [
              "Microsoft-Event"
            ],
            "xPathQueries": [
              "System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
              "Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
            ]
          }
        ]
    },
      "destinations": {
        "logAnalytics": [
          {
            "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
            "name": "centralWorkspace"
          }
        ]
      },
      "dataFlows": [
        {
          "streams": [
            "Microsoft-Event"
          ],
          "destinations": [
            "centralWorkspace"
          ],
            "transformKql": "source",
            "outputStream": "Microsoft-Event"
        }
      ]
    }
  }

Syslog-Ereignisse

DCRs für Syslog-Ereignisse verwenden die Datenquelle syslog mit dem eingehenden Stream Microsoft-Syslog. Das Schema dieses Streams ist bekannt, so dass es in diesem dataSources-Abschnitt nicht definiert werden muss. Die zu sammelnden Ereignisse werden in den Eigenschaften facilityNames und logLevels angegeben. Weitere Einzelheiten finden Sie unter Sammeln von Syslog-Ereignissen mit dem Azure Monitor-Agent. Für den Anfang können Sie die Anleitung in diesem Artikel verwenden, um eine DCR über das Azure-Portal zu erstellen und dann das JSON mithilfe der Anleitung unter DCR-Definition zu inspizieren.

Sie können der Eigenschaft dataFlows eine Transformation hinzufügen, um zusätzliche Funktionen zu erhalten und die Daten weiter zu filtern. Aus Effizienzgründen sollten Sie jedoch so oft wie möglich facilityNames und logLevels für die Filterung verwenden, um potenzielle Datenerfassungsgebühren zu vermeiden.

Die folgende Beispiel-DCR führt die folgenden Aktionen aus:

  • Sammelt alle Ereignisse der Einrichtung cron.
  • Sammelt Warning und höhere Ereignisse aus den Einrichtungen syslog und daemon.
    • Sendet Daten an die Syslog-Tabelle im Arbeitsbereich.
    • Verwendet eine einfache Transformation eines source, die keine Änderungen an den eingehenden Daten vornimmt.
{
    "location": "eastus",
    "properties": {
      "dataSources": {
        "syslog": [
          {
            "name": "cronSyslog",
            "streams": [
              "Microsoft-Syslog"
            ],
            "facilityNames": [
              "cron"
            ],
            "logLevels": [
              "Debug",
              "Info",
              "Notice",
              "Warning",
              "Error",
              "Critical",
              "Alert",
              "Emergency"
            ]
          },
          {
            "name": "syslogBase",
            "streams": [
              "Microsoft-Syslog"
            ],
            "facilityNames": [
              "daemon",              
              "syslog"
            ],
            "logLevels": [
              "Warning",
              "Error",
              "Critical",
              "Alert",
              "Emergency"           
            ]
          }
        ]
      },
      "destinations": {
        "logAnalytics": [
          {
            "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
            "name": "centralWorkspace"
          }
        ]
      },
      "dataFlows": [
        {
          "streams": [
            "Microsoft-Syslog"
          ],
          "destinations": [
            "centralWorkspace"
          ],
            "transformKql": "source",
            "outputStream": "Microsoft-Syslog"
        }
      ]
    }
  }

Leistungsindikatoren

DCRs für Leistungsdaten verwenden die Datenquelle performanceCounters mit den eingehenden Datenströmen Microsoft-InsightsMetrics und Microsoft-Perf. Microsoft-InsightsMetrics wird verwendet, um Daten an Azure Monitor Metrics zu senden, während Microsoft-Perf verwendet wird, um Daten an einen Log Analytics-Arbeitsbereich zu senden. Sie können beide Datenquellen in die DCR aufnehmen, wenn Sie Leistungsdaten an beide Ziele senden. Die Schemata dieser Streams sind bekannt, so dass sie im Abschnitt dataSources nicht definiert werden müssen.

Die zu sammelnden Leistungsindikatoren werden in der Eigenschaft counterSpecifiers angegeben. Weitere Informationen finden Sie unter Sammeln von Leistungsindikatoren mit dem Azure Monitor-Agent. Für den Anfang können Sie die Anleitung in diesem Artikel verwenden, um eine DCR über das Azure-Portal zu erstellen und dann das JSON mithilfe der Anleitung unter DCR-Definition zu inspizieren.

Sie können der Eigenschaft dataFlows eine Transformation für Microsoft-Perf hinzufügen, um zusätzliche Funktionen zu erhalten und die Daten weiter zu filtern. Sie sollten jedoch nur die Zähler auswählen, die Sie in counterSpecifiers für die Effizienz benötigen, um potenzielle Datenerfassungsgebühren zu vermeiden.

Die folgende Beispiel-DCR führt die folgenden Aktionen aus:

  • Erfasst alle 60 Sekunden einen Satz von Leistungsindikatoren und einen weiteren Satz alle 30 Sekunden.
  • Sendet Daten an Azure Monitor Metrics und einen Log Analytics-Arbeitsbereich.
  • Verwendet eine einfache Transformation eines source, die keine Änderungen an den eingehenden Daten vornimmt.
{
    "location": "eastus",
    "properties": {
      "dataSources": {
        "performanceCounters": [
          {
            "name": "perfCounterDataSource60",
            "streams": [
              "Microsoft-Perf",
              "Microsoft-InsightsMetrics"
            ],
            "samplingFrequencyInSeconds": 60,
            "counterSpecifiers": [
              "\\Processor(_Total)\\% Processor Time",
              "\\Memory\\Committed Bytes",
              "\\LogicalDisk(_Total)\\Free Megabytes",
              "\\PhysicalDisk(_Total)\\Avg. Disk Queue Length"
            ]
          },
          {
            "name": "perfCounterDataSource30",
            "streams": [
              "Microsoft-Perf"
            ],
            "samplingFrequencyInSeconds": 30,
            "counterSpecifiers": [
              "\\Process(_Total)\\Thread Count"
            ]
          }
        ]
      },
      "destinations": {
        "logAnalytics": [
          {
            "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
            "name": "centralWorkspace"
          }
        ],
        "azureMonitorMetrics": 
        {
            "name": "azureMonitorMetrics-default"
        }
      },
      "dataFlows": [
        {
            "streams": [
                "Microsoft-Perf"
            ],
            "destinations": [
                "centralWorkspace"
            ],
            "transformKql": "source",
            "outputStream": "Microsoft-Perf"
        },
        {
            "streams": [
                "Microsoft-Perf"
            ],
            "destinations": [
                "azureMonitorMetrics-default"
            ],
            "outputStream": "Microsoft-InsightsMetrics"
        }
      ]
    }
}

Textprotokolle

DCRs für Textprotokolle haben eine logfiles-Datenquelle, die die Details für die Protokolldateien enthält, die vom Agent gesammelt werden sollen. Dazu gehört der Name eines Streams, der zusammen mit den Spalten der eingehenden Daten in streamDeclarations definiert werden muss. Dies ist derzeit eine festgelegte Liste, wie unter Sammeln von Protokollen aus einer Textdatei mit Azure Monitor-Agent beschrieben.

Fügen Sie der Eigenschaft dataFlows eine Transformation hinzu, um Datensätze herauszufiltern, die Sie nicht sammeln möchten, und um die Daten so zu formatieren, dass sie dem Schema der Zieltabelle entsprechen. Ein häufiges Szenario ist das Analysieren einer durch Trennzeichen getrennten Protokolldatei in mehrere Spalten, wie in Durch Trennzeichen getrennte Protokolldateien beschrieben.

Die folgende Beispiel-DCR führt die folgenden Aktionen aus:

  • Sammelt Einträge von allen Dateien mit der Erweiterung von .txt im c:\logs-Ordner des Agent-Computers.
  • Verwendet eine Transformation, um die eingehenden Daten anhand eines Kommas (,) in Spalten aufzuteilen. Diese Umwandlung ist spezifisch für das Format der Protokolldatei und muss für Protokolldateien mit anderen Formaten angepasst werden.
  • Sendet die gesammelten Protokolle an eine benutzerdefinierte Tabelle mit dem Namen MyTable_CL. Diese Tabelle muss bereits existieren und die von der Transformation ausgegebenen Spalten enthalten.
  • Sammelt die FilePath- und Computer-Werte für das Textprotokoll, wie in Eingehender Datenstrom beschrieben. Diese Spalten müssen auch in der Zieltabelle vorhanden sein.
{
    "location": "eastus",
    "properties": {
        "dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
        "streamDeclarations": {
            "Custom-MyLogFileFormat": {
                "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "datetime"
                    },
                    {
                        "name": "RawData",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "Computer",
                        "type": "string"
                    }
                ]
            }
        },
        "dataSources": {
            "logFiles": [
                {
                    "streams": [
                        "Custom-MyLogFileFormat"
                    ],
                    "filePatterns": [
                        "C:\\logs\\*.txt"
                    ],
                    "format": "text",
                    "settings": {
                        "text": {
                            "recordStartTimestampFormat": "ISO 8601"
                        }
                    },
                    "name": "myLogFileFormat-Windows"
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "MyDestination"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Custom-MyLogFileFormat"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source | project d = split(RawData,\",\") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])",
                "outputStream": "Custom-MyTable_CL"
            }
        ]
    }
}

JSON-Protokolle

DCRs für JSON-Protokolle haben eine logfiles-Datenquelle, die die Details für die Protokolldateien enthält, die vom Agent gesammelt werden sollen. Dazu gehört der Name eines Streams, der zusammen mit den Spalten der eingehenden Daten in streamDeclarations definiert werden muss. Weitere Einzelheiten finden Sie unter Sammeln von Protokollen aus einer JSON-Datei mit dem Azure Monitor-Agent.

Fügen Sie der Eigenschaft dataFlows eine Transformation hinzu, um Datensätze herauszufiltern, die Sie nicht sammeln möchten, und um die Daten so zu formatieren, dass sie dem Schema der Zieltabelle entsprechen.

Die folgende Beispiel-DCR führt die folgenden Aktionen aus:

  • Sammelt Einträge von allen Dateien mit der Erweiterung von .json im c:\logs-Ordner des Agent-Computers. Die Datei muss im JSON-Format formatiert sein und die in der Datenstromdeklaration aufgeführten Spalten enthalten.
  • Sendet die gesammelten Protokolle an eine benutzerdefinierte Tabelle mit dem Namen MyTable_CL. Diese Tabelle muss bereits vorhanden sein und die gleichen Spalten wie der eingehende Datenstrom haben. Wenn die Spalten nicht übereinstimmen, müssen Sie die Transformation in der Eigenschaft transformKql ändern, um die Daten für die Zieltabelle zu formatieren.
{
    "location": "eastus",
    "properties": {
        "dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
        "streamDeclarations": {
            "Custom-Json-stream": {
                "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "datetime"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "Code",
                        "type": "int"
                    },
                    {
                        "name": "Module",
                        "type": "string"
                    },
                    {
                        "name": "Message",
                        "type": "string"
                    }
                ]
            }
        },
        "dataSources": {
            "logFiles": [
                {
                    "streams": [
                        "Custom-Json-stream"
                    ],
                    "filePatterns": [
                        "C:\\logs\\*.json"
                    ],
                    "format": "json",
                    "name": "MyJsonFile"
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "MyDestination"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Custom-Json-stream"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source",
                "outputStream": "Custom-MyTable_CL"
            }
        ]
    }
}

Senden von Daten an Event Hubs oder Storage

DCRs, die Daten an Event Hubs oder Storage-Konten senden, verwenden dieselben Datenquellen wie andere DCRs, die Daten mit dem Azure Monitor-Agent (AMA) sammeln, haben aber eines oder mehrere der folgenden Ziele. Weitere Informationen finden Sie unter Senden von Daten an Event Hubs und Storage (Vorschau).

  • eventHubsDirect
  • storageBlobsDirect
  • storageTablesDirect

Hinweis

DCRs, die Daten an Event Hubs oder Storage-Konten senden, benötigen "kind": "AgentDirectToStore".

Die folgende Beispiel-DCR führt die folgenden Aktionen aus:

  • Erfasst Leistungszähler und Windows-Ereignisse von Windows-Rechnern mit dem Azure Monitor-Agent (AMA).
  • Sendet die Daten an Event Hub, Blob Storage und Table Storage.
{
    "location": "eastus",
    "kind": "AgentDirectToStore",
    "properties": {
        "dataSources": {
            "performanceCounters": [
                {
                "streams": [
                    "Microsoft-Perf"
                ],
                "samplingFrequencyInSeconds": 10,
                "counterSpecifiers": [
                    "\\Process(_Total)\\Working Set - Private",
                    "\\Memory\\% Committed Bytes In Use",
                    "\\LogicalDisk(_Total)\\% Free Space",
                    "\\Network Interface(*)\\Bytes Total/sec"
                ],
                "name": "perfCounterDataSource"
                }
            ],
            "windowsEventLogs": [
                {
                "streams": [
                    "Microsoft-Event"
                ],
                "xPathQueries": [
                    "Application!*[System[(Level=2)]]",
                    "System!*[System[(Level=2)]]"
                ],
                "name": "eventLogsDataSource"
                }
            ]
        },
        "destinations": {
            "eventHubsDirect": [
                {
                "eventHubResourceId": "/subscriptions/71b36fb6-4fe4-4664-9a7b-245dc62f2930/resourceGroups/my-resource-group/providers/Microsoft.EventHub/namespaces/my-eventhub-namespace/eventhubs/my-eventhub",
                "name": "myEh"
                }
            ],
            "storageBlobsDirect": [
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "myperfblob",
                "name": "PerfBlob"
                },
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "myeventblob",
                "name": "EventBlob"
                }
            ],
            "storageTablesDirect": [
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "myperftable",
                "name": "PerfTable"
                },
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "mymyeventtable",
                "name": "EventTable"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                "Microsoft-Perf"
                ],
                "destinations": [
                "myEh",
                "PerfBlob",
                "PerfTable"
                ]
            },
            {
                "streams": [
                "Microsoft-Event"
                ],
                "destinations": [
                "myEh",
                "EventBlob",
                "EventTable"
                ]
            },
        ]
    }
}

Protokollerfassungs-API

DCRs für die Protokollaufnahme-API müssen das Schema des eingehenden Streams im Abschnitt streamDeclarations der DCR-Definition definieren. Die eingehenden Daten müssen in JSON mit einem Schema formatiert sein, das den Spalten in dieser Definition entspricht. Es ist keine Transformation erforderlich, wenn dieses Schema mit dem Schema der Zieltabelle übereinstimmt. Wenn die Schemata nicht übereinstimmen, müssen Sie der Eigenschaft dataFlows eine Transformation hinzufügen, um die Daten zu formatieren. Weitere Informationen finden Sie unter Protokollerfassungs-API in Azure Monitor.

Das nachfolgende DCR-Beispiel enthält die folgenden Details:

  • Sendet Daten an eine Tabelle mit dem Namen MyTable_CL in einem Arbeitsbereich mit dem Namen my-workspace. Bevor Sie diese DCR installieren, müssen Sie die Tabelle mit den folgenden Spalten erstellen:
    • TimeGenerated
    • Computer
    • AdditionalContext
    • ExtendedColumn (definiert in der Transformation)
  • Wendet eine Transformation auf die eingehenden Daten an, um die Daten für die Zieltabelle zu formatieren.

Wichtig

In diesem Beispiel ist die Eigenschaft dataCollectionEndpointId nicht enthalten, da diese automatisch erstellt wird, wenn die DCR erstellt wird. Sie benötigen den Wert dieser Eigenschaft, da es sich um die URL handelt, an die die Anwendung Daten senden wird. Die DCR muss mit der Eigenschaft kind:Direct erstellt werden. Weitere Informationen finden Sie unter Eigenschaften.

{
    "location": "eastus",
    "kind": "Direct",
    "properties": {
        "streamDeclarations": {
            "Custom-MyTable": {
                "columns": [
                    {
                        "name": "Time",
                        "type": "datetime"
                    },
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "AdditionalContext",
                        "type": "string"
                    }
                ]
            }
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/cefingestion/providers/microsoft.operationalinsights/workspaces/my-workspace",
                    "name": "LogAnalyticsDest"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Custom-MyTable"
                ],
                "destinations": [
                    "LogAnalyticsDest"
                ],
                "transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
                "outputStream": "Custom-MyTable_CL"
            }
        ]
    }
}

Arbeitsbereichstransformations-DCR

Bei DCRs für Arbeitsbereichstransformationen ist der Abschnitt datasources leer, da die Transformationen auf alle Daten angewendet werden, die an unterstützte Tabellen im Arbeitsbereich gesendet werden. Sie benötigt nur einen einzigen Eintrag für workspaceResourceId und einen Eintrag in dataFlows für jede Tabelle mit einer Transformation. Sie muss auch "kind": "WorkspaceTransforms" haben.

Das nachfolgende DCR-Beispiel enthält die folgenden Details:

  • Transformation für die Tabelle LAQueryLogs, die Abfragen der Tabelle selbst herausfiltert und eine Spalte mit dem Namen des Arbeitsbereichs hinzufügt.
  • Transformation für die Tabelle Event, die Informationsereignisse herausfiltert und die Spalte ParameterXml entfernt. Dies gilt nur für Daten, die vom veralteten Log Analytics-Agenten stammen und nicht vom Azure Monitor-Agenten, wie in Arbeitsbereichstransformations-DCR erläutert.
{
    "kind": "WorkspaceTransforms",
    "location": "eastus",
    "properties": {
        "dataSources": {},
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "clv2ws1"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-Table-LAQueryLogs"
                ],
                "destinations": [
                    "clv2ws1"
                ],
                "transformKql": "source | where QueryText !contains 'LAQueryLogs' | extend Context = parse_json(RequestContext) | extend Workspace_CF = tostring(Context['workspaces'][0]) | project-away RequestContext, Context"
            },
            {
                "streams": [
                    "Microsoft-Table-Event"
                ],
                "destinations": [
                    "clv2ws1"
                ],
                "transformKql": "source | where EventLevelName in ('Error', 'Critical', 'Warning') | project-away ParameterXml"
            }
        ]
    }
}

Senden von Daten an mehrere Tabellen

Es gibt mehrere Gründe, warum Sie Daten aus einer einzigen Datenquelle an mehrere Tabellen im selben Log Analytics-Arbeitsbereich senden möchten, wie zum Beispiel:

  • Einsparung von Datenerfassungskosten, indem Sie Datensätze, die für gelegentliche Problembehandlung verwendet werden, an eine Basisprotokolltabelle senden.
  • Senden von Datensätzen oder Spalten mit vertraulichen Daten an eine Tabelle mit anderen Berechtigungen oder Aufbewahrungseinstellungen.

Um Daten aus einer einzigen Datenquelle an mehrere Tabellen zu senden, erstellen Sie in der DCR mehrere Datenflüsse mit einer eindeutigen Transformationsabfrage und Ausgabetabelle für jede Tabelle, wie in der folgenden Abbildung dargestellt.

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.

Diagramm einer Transformation, die Daten an mehrere Tabellen sendet.

Das folgende Beispiel filtert Datensätze, die vom Azure Monitor-Agent an die Ereignistabelle gesendet werden. Nur Warn- und Fehlerereignisse werden an die Ereignistabelle gesendet. Andere Ereignisse werden an eine Kopie der Ereignistabelle mit dem Namen „Event_CL“ gesendet, die für grundlegende Protokolle konfiguriert ist.

Hinweis

Für dieses Beispiel benötigen Sie eine Kopie der Tabelle „Event“, die im selben Arbeitsbereich unter dem Namen „Event_CL“ erstellt wurde.

{
    "location": "eastus",
    "properties": {
        "dataSources": {
            "windowsEventLogs": [
              {
                "name": "eventLogsDataSource",
                "streams": [
                  "Microsoft-Event"
                ],
                "xPathQueries": [
                  "System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
                  "Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
                ]
              }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "MyDestination"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-Event"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source | where EventLevelName in ('Error', 'Warning')",
                "outputStream": "Microsoft-Event"
            },
            {
                "streams": [
                    "Microsoft-Event"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source | where EventLevelName !in ('Error', 'Warning')",
                "outputStream": "Custom-Event_CL"
            }
        ]
    }
}

Nächste Schritte