Struktur einer Datensammlungsregel in Azure Monitor
In diesem Artikel wird die JSON-Struktur von Datensammlungsregeln 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.
Eigenschaften
In der folgenden Tabelle werden die Eigenschaften auf der obersten Ebene der Datensammlungsregeln beschrieben.
Eigenschaft | 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 Datensammlungsregeln nicht vorhanden, die keinen Datensammlungsendpunkt verwenden. |
endpoints 1 |
Enthält die URLs logsIngestion und metricsIngestion der Endpunkte für die Datensammlungsregel 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 Datensammlungsregel verwendet wird Dieser Parameter wird weiter unten beschrieben. |
1 Diese Eigenschaft wurde nicht für Datensammlungsregeln 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.
Variante
Die kind
-Eigenschaft der Datensammlungsregel gibt den Typ der Auflistung an, für die die Datensammlungsregel verwendet wird. Jeder Typ von Datensammlungsregel weist eine andere Struktur und andere Eigenschaften auf.
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 Datensammlungsregel enthält keinen Eingabestream. |
Übersicht über den Datenfluss bei Datensammlungsregeln
Im folgenden Diagramm ist grundlegende Flow einer Datensammlungsregel dargestellt. Die einzelnen Komponenten werden in den folgenden Abschnitten beschrieben.
Eingabestreams
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
Datensammlungsregeln für Arbeitsbereichstransformationen-DCRs verfügen über keinen Eingabestream.
Eingabestream | 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
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.
Allgemeine Parameter
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> . |
Gültige Datenquellentypen
Die derzeit verfügbaren Datenquellentypen sind in der folgenden Tabelle aufgelistet.
Datenquellentyp | Beschreibung | Streams | 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 VM | 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 | Microsoft-Syslog |
facilityNames : Einrichtungen, die erfasst werden sollenlogLevels : 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.
Datenstromdeklarationen
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.
Datentypen
Die möglichen Datentypen, die den Eigenschaften zugewiesen werden können, sind:
string
int
long
real
boolean
dynamic
datetime
.
Destinations
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.
Allgemeine Parameter
Parameter | Beschreibung |
---|---|
name |
Name zur Identifikation des Ziels im Abschnitt dataSources |
Gültige Ziele
Die derzeit verfügbaren Ziele sind in der folgenden Tabelle aufgeführt.
Destination | 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 es nur einen Metrikspeicher für das Abonnement gibt. |
storageTablesDirect |
Azure-Tabellenspeicher | storageAccountResourceId : Ressourcen-ID des SpeicherkontostableName : Name der Tabelle |
storageBlobsDirect |
Azure Blob Storage | storageAccountResourceId : Ressourcen-ID des SpeicherkontoscontainerName : Name des Blobcontainers |
eventHubsDirect |
Event 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
Datenflüsse gleichen Eingabestreams mit Zielen ab. Jede Datenquelle kann optional eine Transformation und in einigen Fällen eine bestimmte Tabelle im Log Analytics-Arbeitsbereich angeben.
Datenflusseigenschaften
Abschnitt | Beschreibung |
---|---|
streams |
Mindestens ein Stream, der im Abschnitt für Eingabestreams definiert ist 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 |
Mindestens ein Ziel aus dem Abschnitt destinations oben. In Multi-Homing-Szenarien sind mehrere Ziele 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. |