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.
In diesem Artikel wird die JSON-Struktur von DCRs für die Fälle beschrieben, in denen Sie direkt mit ihrer Definition arbeiten müssen.
- Details zum Arbeiten mit der hier beschriebenen JSON finden Sie unter Erstellen und bearbeiten von Datensammlungsregeln (Data Collection Rules, DCRs) in Azure Monitor.
- Siehe Beispiele für Datensammlungsregeln (DCRs) in Azure Monitor für Beispiel-DCRs für verschiedene Szenarien.
In der folgenden Tabelle werden die Eigenschaften auf der obersten Ebene der Datensammlungsregeln beschrieben.
Eigentum | BESCHREIBUNG |
---|---|
description |
Optionale Beschreibung von benutzerseitig definierten Datensammlungsregeln |
dataCollectionEndpointId |
Ressourcen-ID des Datensammlungsendpunkts (DCE), der von der Datensammlungsregel verwendet wird, wenn Sie bei ihrer Erstellung einen angegeben haben Diese Eigenschaft ist in DCRs nicht vorhanden, die keinen DCE verwenden. |
endpoints 1 |
Enthält die URLs logsIngestion und metricsIngestion der Endpunkte für die DCR. Dieser Abschnitt und seine Eigenschaften werden automatisch erstellt, wenn die Datensammlungsregel nur erstellt wird, wenn das kind -Attribut in der Datensammlungsregel Direct ist. |
immutableId |
Ein eindeutiger Bezeichner für die Datensammlungsregel. Diese Eigenschaft und ihr Wert werden automatisch erstellt, wenn die Datensammlungsregel erstellt wird. |
kind |
Gibt das Datensammlungsszenario an, für das die DCR verwendet wird. Dieser Parameter wird weiter unten beschrieben. |
1 Diese Eigenschaft wurde nicht für DCRs erstellt, die vor dem 31. März 2024 erstellt wurden. DCRs, die vor diesem Datum erstellt wurden, erforderten einen Datensammlungsendpunkt (DCE) und die eine Festlegung der dataCollectionEndpointId
-Eigenschaft. Wenn Sie diese eingebetteten DCEs verwenden möchten, müssen Sie einen neuen DCR erstellen.
Die kind
-Eigenschaft in der DCR gibt den Typ der Sammlung an, für die die DCR verwendet wird. Jede Art von DCR hat eine andere Struktur und andere Eigenschaften.
In der folgenden Tabelle sind die verschiedenen Typen von Datensammlungsregeln und deren Details aufgeführt.
Variante | BESCHREIBUNG |
---|---|
Direct |
Direkte Erfassung mithilfe der Protokollerfassungs-API Endpunkte werden nur für die Datensammlungsregel erstellt, wenn dieser Werttyp verwendet wird. |
AgentDirectToStore |
Senden Sie die gesammelten Daten an Azure Storage und Event Hubs. |
AgentSettings |
Konfigurieren Sie Parameter für den Azure Monitor-Agent. |
Linux |
Sammeln Sie Ereignisse und Leistungsdaten von Linux-Computern. |
PlatformTelemetry |
Exportieren Sie Plattformmetriken. |
Windows |
Sammeln Sie Ereignisse und Leistungsdaten von Windows-Computern. |
WorkspaceTransforms |
Arbeitsbereichstransformations-DCR. Diese DCR enthält keinen Eingabestream. |
Im folgenden Diagramm ist der grundlegende Ablauf eines DCR gezeigt. Die einzelnen Komponenten werden in den folgenden Abschnitten beschrieben.
Der Abschnitt für den Eingabestream einer Datensammlungsregel definiert die eingehenden Daten, die gesammelt werden. Es gibt zwei Typen von Eingabestream, die vom jeweiligen Datensammlungsszenario abhängen. In den meisten Datensammlungsszenarien wird einer der Eingabestreams verwendet, während einige auch beide verwenden können.
Hinweis
Arbeitsplatztransformations-DCRs verfügen über keinen Eingabestream.
Eingabedatenstrom | BESCHREIBUNG |
---|---|
dataSources |
Bekannter Datentyp. Dies sind häufig Daten, die vom Azure Monitor-Agent verarbeitet und mithilfe eines bekannten Datentyps an Azure Monitor übermittelt werden. |
streamDeclarations |
Benutzerdefinierte Daten, die in der Datensammlungsregel definiert werden müssen |
Daten, die von der Protokollerfassungs-API gesendet werden, verwenden eine streamDeclaration
für das Schema der eingehenden Daten. Dies liegt daran, dass die API benutzerdefinierte Daten sendet, die über ein beliebiges Schema verfügen können.
Textprotokolle vom AMA sind ein Beispiel für eine Datensammlung, die sowohl dataSources
als auch streamDeclarations
erfordert. Die Datenquelle enthält die Konfiguration.
Datenquellen sind eindeutige Quellen für Überwachungsdaten, die jeweils ein eigenes Format und eine eigene Methode zum Verfügbarmachen ihrer Daten aufweisen. Jeder Datenquellentyp verfügt über eindeutige Parameter, die für jede Datenquelle konfiguriert werden müssen. Die von der Datenquelle zurückgegebenen Daten weisen in der Regel einen bekannten Typ auf, sodass das Schema nicht in der Datensammlungsregel definiert werden muss.
Beispielsweise verwenden Ereignisse und Leistungsdaten, die von einer VM mit dem Azure Monitor-Agent (AMA) gesammelt werden, Datenquellen wie windowsEventLogs
und performanceCounters
. Sie geben Kriterien für die Ereignisse und Leistungsindikatoren an, die Sie sammeln möchten, aber Sie müssen die Struktur der Daten selbst nicht definieren, da es sich um ein bekanntes Schema für potenzielle eingehende Daten handelt.
Alle Datenquellentypen weisen die folgenden Parameter auf.
Parameter | BESCHREIBUNG |
---|---|
name |
Name zum Identifizieren der Datenquelle in der Datensammlungsregel |
streams |
Liste der Datenströme, die von der Datenquelle erfasst werden Wenn es sich um einen Standarddatentyp wie ein Windows-Ereignis handelt, hat der Datenstrom die Form Microsoft-<TableName> . Wenn es sich um einen benutzerdefinierten Typ handelt, hat er die Form Custom-<TableName> . |
Die derzeit verfügbaren Datenquellentypen sind in der folgenden Tabelle aufgelistet.
Datenquellentyp | BESCHREIBUNG | Bäche | Parameter |
---|---|---|---|
eventHub |
Daten aus Azure Event Hubs | Benutzerdefiniert1 | consumerGroup : Consumergruppe des Event Hubs, von dem erfasst werden soll |
iisLogs |
IIS-Protokolle von Windows-Computern | Microsoft-W3CIISLog |
logDirectories : Verzeichnis, in dem IIS-Protokolle auf dem Client gespeichert werden |
logFiles |
Text- oder JSON-Protokoll auf einer virtuellen Maschine | Benutzerdefiniert1 | filePatterns : Ordner- und Dateimuster für Protokolldateien, die vom Client erfasst werden sollenformat - JSON oder Text |
performanceCounters |
Leistungsindikatoren für virtuelle Windows- und Linux-Computer | Microsoft-Perf Microsoft-InsightsMetrics |
samplingFrequencyInSeconds : Häufigkeit, mit der Leistungsdaten erfasst werden sollencounterSpecifiers : Objekte und Zähler, die erfasst werden sollen |
prometheusForwarder |
Aus Kubernetes-Clustern erfasste Prometheus-Daten | Microsoft-PrometheusMetrics |
streams – Zu sammelnde DatenströmelabelIncludeFilter – Liste der Bezeichnungseinschlussfilter als Name-Wert-Paare. Derzeit wird nur „microsoft_metrics_include_label“ unterstützt. |
syslog |
Syslog-Ereignisse auf virtuellen Linux-Computern Ereignisse im Common Event Format für Sicherheitsgeräte |
Microsoft-Syslog Microsoft-CommonSecurityLog für CEF |
facilityNames - Einrichtungen zum SammelnlogLevels : Protokollebenen, die erfasst werden sollen |
windowsEventLogs |
Windows-Ereignisprotokoll auf virtuellen Computern | Microsoft-Event |
xPathQueries : XPaths, die die Kriterien für die Ereignisse angeben, die erfasst werden sollen |
extension |
Erweiterungsbasierte Datenquelle, die vom Azure Monitor-Agent verwendet wird | Variiert je nach Erweiterung | extensionName : Name der ErweiterungextensionSettings : Werte für jede Einstellung, die für die Erweiterung erforderlich ist |
1 Diese Datenquellen verwenden sowohl eine Datenquellen- als auch eine Datenstromdeklaration, da das Schema der gesammelten Daten variieren kann. Der an der Datenquelle verwendete Datenstrom sollte der in der Datenstromdeklaration definierte benutzerdefinierte Datenstrom sein.
Erklärung der verschiedenen Datentypen, die an den Log Analytics-Arbeitsbereich gesendet werden. Jeder Datenstrom ist ein Objekt, dessen Schlüssel den Datenstromnamen darstellt, der mit Custom- beginnen muss. Der Stream enthält eine vollständige Liste der Eigenschaften oberster Ebene, die in den zu sendenden JSON-Daten enthalten sind. Die Form der Daten, die Sie an den Endpunkt senden, muss nicht mit der Form der Zieltabelle übereinstimmen. Stattdessen muss die Ausgabe der Transformation, die auf die Eingabedaten angewendet wird, mit der Zielform übereinstimmen.
Die möglichen Datentypen, die den Eigenschaften zugewiesen werden können, sind:
string
int
long
real
boolean
dynamic
datetime
.
Der Abschnitt destinations
enthält einen Eintrag für jedes Ziel, an das die Daten gesendet werden. Diese Ziele werden mit Eingabestreams im Abschnitt dataFlows
abgeglichen.
Parameter | BESCHREIBUNG |
---|---|
name |
Name zur Identifikation des Ziels im Abschnitt dataSources |
Die derzeit verfügbaren Ziele sind in der folgenden Tabelle aufgeführt.
Bestimmungsort | BESCHREIBUNG | Erforderliche Parameter |
---|---|---|
logAnalytics |
Log Analytics-Arbeitsbereich | workspaceResourceId : Ressourcen-ID des ArbeitsbereichsworkspaceID : ID des ArbeitsbereichsDamit wird nur der Arbeitsbereich angegeben, nicht die Tabelle, an die die Daten gesendet werden. Wenn es sich um ein bekanntes Ziel handelt, muss keine Tabelle angegeben werden. Benutzerdefinierte Tabellen werden in der Datenquelle angegeben. |
azureMonitorMetrics |
Azure Monitor-Metriken | Es ist keine Konfiguration erforderlich, da nur ein einziger Metrikspeicher für das Abonnement vorhanden ist. |
storageTablesDirect |
Azure-Tabellenspeicher | storageAccountResourceId : Ressourcen-ID des SpeicherkontostableName : Name der Tabelle |
storageBlobsDirect |
Azure Blob-Speicher | storageAccountResourceId : Ressourcen-ID des SpeicherkontoscontainerName : Name des Blobcontainers |
eventHubsDirect |
Ereignis-Hubs | eventHubsDirect : Ressourcen-ID des Event Hubs |
Wichtig
Ein Datenstrom kann nur an einen Log Analytics-Arbeitsbereich in einem DCR gesendet werden. Sie können mehrere dataFlow
Einträge für einen einzelnen Datenstrom haben, wenn sie unterschiedliche Tabellen im selben Arbeitsbereich verwenden. Wenn Sie Daten aus einem einzigen Datenstrom an mehrere Log Analytics-Arbeitsbereiche senden müssen, erstellen Sie für jeden Arbeitsbereich einen separaten DCR.
Datenflüsse ordnen Eingabestreams den Zielen zu. Jede Datenquelle kann optional eine Transformation und in einigen Fällen eine bestimmte Tabelle im Log Analytics-Arbeitsbereich angeben.
`Section` | BESCHREIBUNG |
---|---|
streams |
Einer oder mehrere Streams, die im Abschnitt für Eingabestreams definiert sind. Sie können mehrere Datenströme in einen einzelnen Datenfluss einschließen, wenn Sie mehrere Datenquellen an dasselbe Ziel senden möchten. Verwenden Sie jedoch nur einen einzelnen Datenstrom, wenn der Datenfluss eine Transformation enthält. Ein Datenstrom kann auch von mehreren Datenflüssen verwendet werden, wenn Sie eine bestimmte Datenquelle an mehrere Tabellen im gleichen Log Analytics-Arbeitsbereich senden möchten. |
destinations |
Ein oder mehrere Ziele aus dem oben genannten Abschnitt destinations . In Multi-Homing-Szenarien sind mehrere Destinationen zulässig. |
transformKql |
Optionale Transformation, die auf den eingehenden Datenstrom angewendet wird. Die Transformation muss das Schema der eingehenden Daten und Ausgabedaten im Schema der Zieltabelle verstehen. Wenn Sie eine Transformation verwenden, sollte der Datenfluss nur einen einzelnen Datenstrom verwenden. |
outputStream |
Beschreibt, in welcher Tabelle in dem unter der Eigenschaft destination angegebenen Arbeitsbereich die Daten erfasst werden. Der Wert von outputStream hat das Format Microsoft-[tableName] , wenn Daten in einer Standardtabelle erfasst werden, oder Custom-[tableName] , wenn Daten in einer benutzerdefinierten Tabelle erfasst werden. Es ist nur ein Ziel pro Datenstrom zulässig.Diese Eigenschaft wird nicht für bekannte Datenquellen aus Azure Monitor verwendet, z. B. Ereignisse und Leistungsdaten, da diese an vordefinierte Tabellen gesendet werden. |
Überblick über die Datensammlungsregeln und Methoden zu deren Erstellung