Azure Monitor Kosten senken mit Data Collection Rules und Tabellentransformation

David Göschel

1. September 2025 • 9 Min. Lesezeit

In diesem Blog erfährst du, wie du mit Data Collection Rules (DCRs) und Tabellentransformationen die Kosten von Azure Monitor und Log Analytics Workspace deutlich senken kannst

Data Collection Rules (DCRs) in Azure Monitor

Wir beginnen mit der Frage, was Data Collection Rules sind und wie man diese einsetzen kann, um die Menge der Daten zu minimieren

Die Data Collection Rules sind eine Funktion in Azure Monitor, die uns dabei helfen, die Daten, die nach Azure Log Analytics Workspace gesendet werden, zu filtern und zu transformieren bevor sie gespeichert werden. Mit Data Collection Rules können wir gezielt steuern, welche Daten erfasst und wie diese verarbeitet werden

Workspace Transformation Data Collection Rules (Workspace DCR)

Eine besondere Form der Data Collection Rules sind die Workspace Transformation Data Collection Rules (dt. Arbeitsbereichstransformation DCR). Dabei handelt es sich um eine Data Collection Rule, die auf die gesamte Log Analytics Workspace angewendet wird und einmalig pro Workspace definiert wird. Jede unterstützte Tabelle in Azure Monitor kann mit einer Tabellentransformation versehen werden, um die Datenmenge zu reduzieren

Die Grafik zeigt die Architektur einer Data Collection Rule für eine Log Analytics Workspace-Ressource in Azure Monitor. Die Datenquelle sendet die Daten an Azure Log Analytics Workspace und durchläuft, ähnlich einer Pipeline in einer ETL-Strategie, die Data Collection Rule und filtert jeden Eintrag mithilfe einer Kusto Query Language (KQL)-Abfrage, bevor diese in den Tabellen von Azure Log Analytics Workspace gespeichert werden

Tabellentransformation mit Data Collection Rules

Benutzerdefinierte Tabellen und Tabellen, die von Microsoft unterstützt werden, können in Azure Monitor mit Data Collection Rules (DCRs) transformiert werden um die Menge der erfassten Daten zu reduzieren und die Kosten zu senken

1. Data Collection Rule erstellen

Um eine Transformation für eine Tabelle zu erstellen, öffnen wir auf der linken Seite im Menu die Settings und navigieren zu Tables. Dort wählen wir zunächst die Tabelle aus, für die wir eine Data Collection Rule erstellen möchten

In unserem Fall ist es die Tabelle AppRequests, die standardmäßig von Application Insights verwendet wird, um Daten von Webapplikationen zu speichern. Jede Tabelle bietet über ein Kontextmenü die Möglichkeit, eine Data Collection Rule zu erstellen

Das Video zeigt, an welcher Stelle im Azure Portal die Data Collection Rule für eine Tabellentransformation zu finden ist

Es öffnet sich ein geführtes Menü, in dem wir die Data Collection Rule erstellen können

Die Felder sind bereits vorausgefüllt, da wir die Data Collection Rule aus dem Kontextmenü der Tabelle AppRequests erstellen möchten. Wenn noch keine Data Collection Rule für diesen Log Analytics Workspace existiert, können wir eine neue erstellen und diese mit der Tabelle verknüpfen

Wenn bereits eine Data Collection Rule für diesen Log Analytics Workspace existiert, wird diese automatisch ausgewählt und eine neue KQL-Abfrage für die jeweilige Tabelle der Data Collection Rule hinzugefügt

Wir konfigurieren die Data Collection Rule mit einem aussagekräftigen Namen und zu welchem Abonnement und Ressourcengruppe diese gehören soll

2. KQL-Abfrage zur Tabellentransformation

Nachdem die wenigen Felder ausgefüllt sind, gehen wir weiter zum nächsten Schritt und erstellen die KQL-Abfragen

Zunächst sehen wir eine Vorschau der Daten, die aktuell in der jeweiligen Tabelle gespeichert sind. Diese sind auf maximal 10 Datensätze begrenzt, was uns hilft, die Struktur der Daten besser zu verstehen

Diese Daten filtern wir jetzt mit einer KQL-Abfrage und öffnen dazu den KQL-Editor mit einem Klick auf “Transformation editor”

Das Keyword source ist ein alias für die Tabelle, die für die Tabellentransformation in der Data Collection Rule zurzeit verwendet wird. Mit dem Klick auf den Button “Run” können wir die 10 neuesten Datensätze einsehen

Jetzt beginnen wir mit der KQL-Abfrage, um die Datenmenge zu reduzieren, die je nach Anwendungsfall und Geschäftsanforderungen unterschiedlich ausfallen

In unserem Fall möchten wir nur die Spalten TimeGenerated und Url aus der jeweiligen Tabelle erfassen und an Azure Log Analytics Workspace senden

So sieht die KQL-Abfrage aus:

source
| project TimeGenerated, Url

Mit einem Klick auf “Run” wird die KQL-Abfrage ausgeführt und das Ergebnis angezeigt und mit “Apply” bestätigt

Das Ergebnis der KQL-Abfrage zeigt nur die beiden Spalten TimeGenerated und Url an. Alle anderen Spalten werden nicht erfasst und somit auch nicht mehr an Azure Log Analytics Workspace gesendet

3. Data Collection Rule speichern

Nachdem die KQL-Abfrage geschrieben und die Vorschau die gewünschten Daten anzeigt, können wir die Data Collection Rule speichern und mit einem Klick auf “Create” erstellen

In der Regel dauert es 1 - 2 Stunden bis die Tabellentransformation innerhalb der Data Collection Rule aktiv ist und die Daten entsprechend filtert

4. Datenmenge analysieren

Um die Datenmenge zu analysieren, die an Azure Log Analytics Workspace gesendet wird, werten wir die Spalte _BilledSize aus. Das ist eine Standardspalte, die in jeder Tabelle von Azure Monitor vorhanden ist und die Größe der einzelnen Datensätze in Bytes angibt

Mit diesem Wissen ist es uns möglich, ein Vergleich der erfassten Datenmenge vor und nach der Tabellentransformation zu visualisieren

Ich habe innerhalb eines Zeitraums von etwa 45 Minuten in der Webapplikation Daten generiert und die Datensätze mit der folgenden KQL-Abfrage analysiert und ausgewertet

AppRequests
| where TimeGenerated between (todatetime('2025-08-26T16:05:33.02Z') .. todatetime('2025-08-26T16:50:03.39Z'))
| extend _BilledSize=format_bytes(_BilledSize)
| sort by TimeGenerated asc

Das Ergebnis sind 20 Datensätze mit 10 Einträge vor und 10 Einträge nach der Tabellentransformation

Es ist zu erkennen, dass nur die Spalten TimeGenerated und Url aus der KQL-Abfrage zur Tabellentransformation erfasst wurden, während die anderen Spalten leer sind

Das bedeutet, dass die Datenmenge, die an Azure Log Analytics Workspace gesendet wird, nach der Tabellentransformation deutlich reduziert wurden. Anhand der Spalte _BilledSize können wir die Größe der einzelnen Datensätze in Bytes ablesen

Mit der folgenden KQL-Abfrage werden die Datensätze vor und nach der Tabellentransformation gruppiert und eine Summe in Bytes dargestellt, die das Einsparpotenzial verdeutlicht

AppRequests
| where TimeGenerated between (todatetime('2025-08-26T16:05:33.02Z') .. todatetime('2025-08-26T16:50:03.39Z'))
| extend SizeGroup = iif(_BilledSize < 1024, "Unter 1KB", "Über 1KB")
| summarize TotalBytes=format_bytes(sum(_BilledSize)), RequestCount=count() by SizeGroup

Die Auswertung zeigt, dass die Datenmenge nach der Tabellentransformation von 11 KB auf 6 KB reduziert wurde. Das sind rund die Hälfte der Daten, die an Azure Log Analytics Workspace gesendet wurden

Auf den ersten Blick wirkt das Einsparpotenzial noch nicht groß genug, da nur ein kurzer Zeitraum für eine Tabelle betrachtet wurde und die Daten von einem einzigen Benutzer einer Webapplikation stammen. Aber in Unternehmen, die viele Daten über einen langen Zeitraum aus unterschiedlichen Diensten generieren, sind die Kosteneinsparungen enorm

Deshalb ist die Tabellentransformation mit Data Collection Rules eine sehr effektive Maßnahme, um die Kosten von Azure Monitor deutlich zu reduzieren

5. Einstellungen der Data Collection Rule einsehen

Die Workspace Transformation Data Collection Rule (DCR) kann jederzeit im Azure Portal eingesehen und bearbeitet werden. In der Suchleiste sucht man nach “Data Collection Rules” und wählt die entsprechende Ressource aus

Eine besonderheit ist, dass eine Workspace Transformation Data Collection Rule (DCR) nur einmal pro Log Analytics Workspace erstellt werden kann. Das bedeutet, dass alle Tabellen, die mit einer Tabellentransformation versehen werden sollen, in derselben Data Collection Rule konfiguriert werden müssen

Neben den Feldern, in welcher Subscription, Ressourcengruppe und Region die Data Collection Rule erstellt wurde, zeigt die Spalte Kind an, dass es sich um eine Workspace Transformation DCR handelt während die Spalte Destination auf die Logs von Azure Monitor verweist

Interessant sind die Details zu einer Data Collection Rule, die mit einem Klick auf den Namen der DCR geöffnet werden können

Die Immutable ID wird von Azure automatisch generiert um eine Data Collection Rule eindeutig zu identifizieren. Die wichtigsten Informationen zu einer Data Collection Rule findet man jedoch in der JSON-Ansicht

Für uns sind die Felder dataFlows, destinations, kind und immutableId relevant:

6. Automatisch generierte Metriken für Data Collection Rules

Neben der Analyse der Datenmengen mit einer KQL-Abfrage gibt es noch eine weitere Möglichkeit, das übermittelte Datenvolumen, welches durch eine Data Collection Rule (DCR) verarbeitet wird und nach Azure Log Analytics Workspace gesendet wird, zu überwachen

Jede Data Collection Rule (DCR) generiert automatisch Metriken, die im Azure Monitor in der Detailansicht unter dem Reiter Monitoring eingesehen werden können

Diese Metriken geben Auskunft darüber, wie viele Daten durch die Data Collection Rule (DCR) verarbeitet wurden und helfen dabei, die Menge der erfassten Daten zu überwachen und zu optimieren

Fazit

Dieser Leitfaden ist auf Basis eines Kundenworkshops entstanden, das ich zum Thema Kostenoptimierung in Azure Monitor gehalten habe. Der Fokus lag darauf, wie die Datenmenge bereits an der Quelle mithilfe von Data Collection Rules reduziert werden kann, um die Kosten in Azure Monitor in Verbindung mit Log Analytics Workspace und Application Insights zu senken

Interesse an einer Beratung?

Du möchtest die Kosten für Azure Monitor weiter optimieren oder hast Fragen zu Data Collection Rules? Kontaktiere mich gerne für ein unverbindliches Gespräch oder individuelle Beratung