Custom Logs in Azure mit Data Collection Rules und Endpoints

Einführung

Die zentrale Erfassung von Logs ist ein wesentlicher Bestandteil in modernen Cloud-Architekturen. Dabei geht es längst nicht mehr nur um klassische Fehleranalyse, sondern um Sicherheitsüberwachung, Compliance‑Reporting, automatisiertes Alerting und die kontinuierliche Verbesserung von Applikationen.

In der Vergangenheit wurden oft Open‑Source‑Werkzeuge aus der Elastic oder Grafana Suite genutzt, um Logs und Metriken aus Workloads zu sammeln. Diese Lösungen bringen jedoch zusätzliche operative Komplexität, beschränkte Integrationsmöglichkeiten mit Azure-Ressourcen und bieten keine echte Governance-Anbindung.

Azure bietet mit dem Log Analytics Workspace eine native Alternative, die vollständig in die Azure-Plattform eingebettet ist. Diese Architektur ermöglicht es, strukturierte Log-Daten beliebiger Herkunft von Applikationen, CI/CD-Pipelines oder Third‑Party‑Systemen sicher, skalierbar und kosteneffizient zu übertragen.

Gleichzeitig werden Governance Mechanismen, Netzwerkisolation, RBAC, Transformation und Automatisierung als integrale Bestandteile unterstützt.

In diesem Beitrag behandele ich im Details die Data Collection Endpoints (DCE) und Data Collection Rules (DCR). Diese Bausteine in Azure ermöglichen die Erstellung und Speicherung von individuellen Log-Dateien in einem benutzerdefinierten Schema. Damit können wir die bereits umfangreich verfügbaren Logging-Kapazitäten zusätzlich unseren Anforderungen entsprechend erweitern.

Architektur der Lösung

Die Lösung basiert auf einer modularen, Azure-nativen Ingestion-Kette, deren zentrales Element der Log Analytics Workspace (LAW) ist. Dieser fungiert als skalierbare, Kusto-basierte Analyseplattform und speichert sowohl strukturierte als auch semi-strukturierte Log-Daten in benutzerdefinierten Tabellen.

Der LAW bildet damit nicht nur das persistente Zielsystem, sondern auch die Grundlage für Abfragen, Visualisierungen, Korrelationen und automatisierte Reaktionen auf Log-Ereignisse.

Die Anbindung externer oder interner Logquellen erfolgt über die Logs Ingestion API, die über HTTPS angesprochen wird. Jede eingehende Log-Nachricht muss dabei in einem strukturierten JSON-Format vorliegen und wird einer sogenannten Data Collection Rule (DCR) zugeordnet. Diese Rule definiert das erwartete Schema der Daten, also welche Felder erwartet werden und welchen Datentyp sie haben, sowie die nachgelagerte Zieltabelle im LAW. Darüber hinaus können DCRs optionale Kusto-Transformationen enthalten, die bereits beim Ingest ausgeführt werden. Auf diese Weise lassen sich Felder berechnen, anreichern, umbenennen oder filtern, bevor die Daten dauerhaft gespeichert werden. Das kann sowohl die Kosten als auch den Speicherbedarf signifikant reduzieren.

Die Datenübertragung selbst erfolgt durch deinen Client, beispielsweise eine Anwendung oder eine CI/CD-Pipeline, die die Logdaten vorbereitet und sich gegenüber Azure über Microsoft Entra ID authentifiziert. In der Regel kommt dabei ein Client-Credentials-Flow zum Einsatz, alternativ ist die Verwendung einer Managed Identity für Azure-native Ressourcen möglich. Die Ingestion-Requests referenzieren immer eine immutable DCR-ID, die fest mit der Rule und ihrem zugehörigen Datenstrom (Stream) verknüpft ist.

Die Ingestion kann entweder direkt über die DCR erfolgen oder über einen vorgelagerten Data Collection Endpoint (DCE). Letzterer ist insbesondere dann erforderlich, wenn Netzwerkisolation über Private Link gewünscht ist oder wenn bestimmte Plattformanforderungen dies notwendig machen. Der DCE stellt eine eigene, regional verteilte Ingestions-URL bereit und dient gleichzeitig als Verwaltungsendpunkt für Konfiguration und Authentifizierung.

Sobald der Upload beim DCE oder der DCR eingeht, übernimmt Azure Monitor die Kontrolle. Der JSON-Body wird gegen das deklarierte Schema geprüft, optional transformiert, und schließlich in der entsprechenden Tabelle im LAW persistiert. Dies geschieht mit geringer Latenz und wird von Azure vollständig verwaltet inklusive Skalierung, Lastverteilung und Retention Management.

Ein zentrales Merkmal dieser Architektur ist die Transformation on Ingest. Durch die frühzeitige Manipulation der Daten lassen sich nicht nur irrelevante Informationen verwerfen oder normalisieren (etwa die Standardisierung von Log-Leveln), sondern auch Metriken wie Latenzklassen, Fehlercodes oder Anomalien bereits vor der Persistenz ableiten. Dies senkt nicht nur die nachgelagerten Analyseaufwände, sondern reduziert vor allem die Kostenstruktur, da in Azure Monitor primär nach Ingest-Volumen und Query-Aufwand abgerechnet wird.

Diese Architektur ermöglicht eine entkoppelte, skalierbare und sicherheitskonforme Log-Erfassung über System- und Plattformgrenzen hinweg und das mit vollständiger Kontrolle über Format, Zugriff und Verarbeitung.

Log Analytics Workspace

Die Umsetzung beginnt stets mit dem Anlegen eines Log Analytics Workspace (LAW), der in Azure als zentrale Plattform für die Speicherung, Analyse und Korrelation von Log- und Metrikdaten dient. Die Erstellung kann über das Azure-Portal, die CLI oder mittels Infrastructure-as-Code mit Terraform oder Bicep erfolgen. Dabei sollten Namenskonventionen, Tags und Ressourcengruppenstrukturen bereits im frühen Stadium durchdacht werden, um bereits existierende Governance-Anforderungen zu erfüllen.

Ein entscheidender Vorteil des Log Analytics Workspaces liegt in seiner Quellenvielfalt. Logs können aus nativen Azure-Diensten, aus On-Premises-Systemen via Azure Monitor Agent oder auch aus Multi-Cloud-Umgebungen aggregiert werden.

Im Fall benutzerdefinierter Logs wird häufig eine Custom-Tabelle verwendet, etwa Custom_Table_1_CL. Solche Tabellen erfordern mindestens ein Zeitstempelfeld namens TimeGenerated und ein Payload-Feld, typischerweise RawData oder Message. Zusätzliche Spalten können beim Ingest durch Transformationen in der Data Collection Rule mittels KQL dynamisch erzeugt werden beispielsweise durch Extraktion einzelner Felder, Umbenennung oder Datenkonvertierung. Diese Entkopplung zwischen Rohdaten und Tabellenschema ermöglicht eine hohe Flexibilität bei der Weiterverarbeitung und Analyse.

Die Log Analytics Plattform selbst bietet erhebliche Mehrwerte. Neben der Speicherung von Logs erlaubt sie interaktive Analysen mit der Kusto Query Language (KQL), das Erstellen benutzerdefinierter Dashboards und Workbooks, sowie das Definieren regelbasierter Alerts. Solche Alert-Regeln können auf nahezu jede beliebige KQL-Abfrage reagieren und automatisierte Aktionen auslösen beispielsweise den Versand von Benachrichtigungen oder die Ausführung von Logic Apps.

Die Integration mit anderen Azure-Diensten ist tiefgreifend und häufig out-of-the-box verfügbar. Ressourcen wie Azure App Services, Application Gateway oder Key Vault bieten über ihre Diagnostic Settings die Möglichkeit, ohne zusätzliche Agenten oder manuelle Konfiguration Logs und Metriken direkt an den Workspace zu senden. Über die Logs Ingestion API lassen sich darüber hinaus beliebige Anwendungen und Services integrieren, die HTTP-Anfragen senden können. Das ist dabei ideal für Eigenentwicklungen, CI/CD-Pipelines oder externe Systeme.

Zusammenfassend stellt der Log Analytics Workspace nicht nur den Endpunkt für die Datenaufnahme dar, sondern fungiert als Herzstück der Telemetrie unserer Azure Cloud. Es vereinheitlicht Datenflüsse, bietet ein zentrales Sicherheits- und Zugriffskonzept, skaliert automatisch mit dem Datenvolumen und bildet die Grundlage für moderne, automatisierte Betriebsmodelle in Cloud- und Hybridumgebungen.

Data Collection Endpoint

Für Szenarien mit erhöhten Sicherheitsanforderungen wird ergänzend zum Log Analytics Workspace ein Data Collection Endpoint (DCE) eingerichtet. Der DCE stellt eine eigene Ingestions-URL bereit, unter der strukturierte Logdaten empfangen und an die zugehörige Data Collection Rule (DCR) weitergeleitet werden können. Im Unterschied zur direkten DCR-Ingestion erlaubt ein DCE die vollständige Kontrolle über die Netzwerkkommunikation zwischen Client und Azure Monitor, insbesondere durch die Unterstützung von Azure Private Link, Network Security Groups (NSG) und Firewall-Regeln auf Subnet-Ebene.

Ein DCE wird regionsspezifisch bereitgestellt und ist mit einer bestimmten Azure-Region verknüpft. Nach der Bereitstellung entsteht ein dedizierter Endpunkt im Format https://(dce-name-placeholder).(region-placeholder).ingest.monitor.azure.com, der als Ziel für alle Log-Ingestion-Aufrufe dient. Clients senden ihre POST-Anfragen mit Log-Daten an diesen Endpunkt, wobei die Ziel-DCR weiterhin explizit per ID referenziert wird.

Die Integration in ein virtuelles Netzwerk (VNet) erlaubt es, eingehende Ingestionsanfragen auf vertrauenswürdige Quellen zu beschränken. In Kombination mit NSG-Regeln und der Aktivierung von Private Link kann der Datenpfad vollständig vom öffentlichen Internet abgeschirmt werden. Das ist ein wesentliches Kriterium für Umgebungen mit strengen Compliance- und Datenschutzanforderungen, wie sie in regulierten Branchen oder Behörden üblich sind.

Darüber hinaus lassen sich über den DCE auch mehrere DCRs konsolidiert ansprechen, was den Betrieb in größeren Organisationseinheiten oder Mandantenstrukturen erleichtert. Die Trennung von Ingestion-Endpunkt (DCE) und Datenverarbeitung (DCR) führt dabei zu einer klaren Verantwortlichkeit und besserer Wiederverwendbarkeit der Konfigurationen.

Auch wenn ein DCE technisch optional ist, insbesondere seit der Möglichkeit, DCRs direkt als Endpunkt zu verwenden, bleibt er in produktiven Umgebungen häufig unverzichtbar. Sobald Private Link aktiviert ist, ist ein DCE zwingend erforderlich. Ebenso empfiehlt sich der Einsatz eines DCE in Szenarien mit Zero-Trust-Netzwerkarchitektur, da nur so eine explizite Kontrolle aller eingehenden Verbindungen zum Azure Monitor Ingestion-Dienst möglich ist.

Zusammenfassend stellt der Data Collection Endpoint das zentrale Bindeglied zwischen internen Logquellen und der Azure-Monitor-Infrastruktur dar, mit voller Unterstützung für Netzwerksegmentierung, Sicherheitsrichtlinien und mandantenfähige Skalierung.

Data Collection Rule

Die Data Collection Rule (DCR) bildet die logische Konfigurationsschicht innerhalb der Azure Monitor Ingestion-Architektur. Sie legt fest, wie eingehende Logdaten verarbeitet werden sollen, sowohl in Bezug auf Schema und Transformation als auch hinsichtlich der Zielressource, etwa eine benutzerdefinierte Tabelle im Log Analytics Workspace.

Die DCR wird in der Regel als JSON‑Dokument definiert und enthält drei zentrale Abschnitte, die Deklaration der erwarteten Datenströme (Streams), optionale Kusto-Transformationen sowie die Definition der Ausgabedestination. In den StreamDeclarations werden die erwarteten Felder, ihre Typen und die Zuordnung zu einem benannten Datenstrom festgelegt, wie beispielsweise Custom-DemoApp, der wiederum auf die Tabelle DemoApp_CL abgebildet wird.

Besonders leistungsfähig wird die DCR durch den Abschnitt transformKql, in dem Kusto Query Language (KQL) verwendet wird, um die eingehenden Daten noch vor der Persistierung zu manipulieren. Hier lassen sich etwa numerische Severity-Level aus Textfeldern ableiten, unstrukturierte Felder mit parse_json() oder extract() in einzelne Dimensionen zerlegen oder sensitive Inhalte, wie IP-Adressen oder User-IDs, gezielt herausfiltern. Transformationen auf Ingestion-Ebene sind dabei nicht nur ein Werkzeug zur Qualitätsverbesserung, sondern auch ein Mittel zur Kostenoptimierung, da irrelevante oder redundante Daten gar nicht erst gespeichert werden.

In Projekten mit heterogenen oder dynamischen Log-Quellen kann es notwendig sein, die Ingestionspipeline vorzuschalten, beispielsweise durch eigene Preprocessing-Skripte oder Agenten, die Daten vor dem Upload in das erwartete JSON-Format konvertieren, duplizierte Einträge eliminieren oder aggregierte Nutzlasten erzeugen. Diese Vorverarbeitung ergänzt die KQL-Transformationen und ermöglicht eine zweistufige Kontrolle der Datenqualität.

Die Verwendung einer DCR setzt eine sichere Authentifizierung voraus. Azure verlangt für den Zugriff auf die Logs Ingestion API ein gültiges OAuth2-Token, das über Microsoft Entra ID ausgestellt wird. Typischerweise wird hierfür entweder ein Service Principal mit Client-Credentials-Flow oder eine system- oder benutzerseitige Managed Identity verwendet. Die minimal erforderliche Berechtigung ist die RBAC-Rolle "Monitoring Metrics Publisher", die gezielt auf die DCR selbst vergeben wird. Das Token wird gegen die Ressource https://monitor.azure.com angefordert und muss in jedem API-Aufruf als Bearer-Token im Authorization-Header übergeben werden.

Durch diese Trennung von Authentifizierung, Transformation und Zielmapping stellt die Data Collection Rule das zentrale Steuerungsinstrument der Log-Ingestion dar. Das ist dabei flexibel genug für einfache Log-Felder und gleichzeitig mächtig genug für komplexe Datenströme in unternehmenskritischen Umgebungen.

Technische Umsetzung mit Terraform

Nachfolgenden habe ich dir eine kompakte Vorlage für die Erstellung der Data Collection Endpoints und Rules und alle zugehörigen Ressourcen hinterlegt. Bitte beachte ich habe für die Lesbarkeit die Modulstruktur, Variablen und Erweiterbarkeit explizit nicht berücksichtigt. Passe die Vorlage bitte entsprechend deiner Projektanforderungen an.

[...]
# ---------------------------------------------------------------------------
# Log Analytics Workspace (LAW)
# ---------------------------------------------------------------------------

resource "azurerm_resource_group" "law_rg" {
  name     = "rg-law-prod"
  location = "westeurope"

  tags = {
    environment = "prod"
    project     = "example"
  }
}

resource "azurerm_log_analytics_workspace" "law" {
  name                       = "law-prod-01"
  location                   = azurerm_resource_group.law_rg.location
  resource_group_name        = azurerm_resource_group.law_rg.name
  sku                        = "PerGB2018"
  retention_in_days          = 30
  internet_ingestion_enabled = false
  internet_query_enabled     = true

  tags = {
    environment = "prod"
    project     = "example"
  }
}

# ---------------------------------------------------------------------------
# Azure Monitor Private Link Scope (AMPLS)
# ---------------------------------------------------------------------------

resource "azurerm_monitor_private_link_scope" "ampls" {
  name                = "ampls-law-prod"
  resource_group_name = azurerm_resource_group.law_rg.name
  location            = azurerm_resource_group.law_rg.location

  ingestion_access_mode = "PrivateOnly"
  query_access_mode     = "Open"

  tags = {
    environment = "prod"
    project     = "example"
  }
}

resource "azurerm_monitor_private_link_scoped_service" "ampls_linked_law" {
  name                = "ampls-law-prod-law"
  resource_group_name = azurerm_resource_group.law_rg.name
  scope_name          = azurerm_monitor_private_link_scope.ampls.name
  linked_resource_id  = azurerm_log_analytics_workspace.law.id
}

# ---------------------------------------------------------------------------
# Private Endpoint zum AMPLS
# ---------------------------------------------------------------------------

resource "azurerm_private_endpoint" "ampls_pe" {
  name                = "pe-law-prod-01"
  location            = azurerm_resource_group.law_rg.location
  resource_group_name = azurerm_resource_group.law_rg.name
  subnet_id           = data.azurerm_subnet.pe_subnet.id

  private_service_connection {
    name                           = "law-prod-01-pe-ampls"
    private_connection_resource_id = azurerm_monitor_private_link_scope.ampls.id
    subresource_names              = ["azuremonitor"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "default"
    private_dns_zone_ids = [
      data.azurerm_private_dns_zone.monitor.id,
      data.azurerm_private_dns_zone.omsopeninsights.id,
      data.azurerm_private_dns_zone.odsopeninsights.id,
      data.azurerm_private_dns_zone.agentsvc.id,
      data.azurerm_private_dns_zone.blobcore.id,
    ]
  }

  tags = {
    environment = "prod"
    project     = "example"
  }
}

###############################################################################
# Data‑Collection‑Endpoint (DCE)
###############################################################################

resource "azurerm_monitor_data_collection_endpoint" "dce" {
  name                          = "dce-law-prod"
  resource_group_name           = azurerm_resource_group.law_rg.name
  location                      = azurerm_resource_group.law_rg.location
  kind                          = "Linux"
  public_network_access_enabled = false

  tags = {
    environment = "prod"
    project     = "example"
  }
}

###############################################################################
# Custom Log Table (azapi) + Data‑Collection‑Rule (DCR)
###############################################################################

# Beispiel‑Definition: 1 Custom‑Log‑Quelle namens "CustomLogExample".
# Wenn weitere Quellen benötigt werden, einfach kopieren & Namen ändern.

locals {
  custom_log_name              = "CustomLogExample"
  custom_log_table_name        = "CustomLogExample_CL"
  custom_log_retention_days    = 30
  custom_log_total_retention   = 365
}

resource "azapi_resource" "law_customlog_table" {
  name      = local.custom_log_table_name
  parent_id = azurerm_log_analytics_workspace.law.id
  type      = "Microsoft.OperationalInsights/workspaces/tables@2022-10-01"

  body = jsonencode({
    properties = {
      schema = {
        name    = local.custom_log_table_name
        columns = [
          { name = "TimeGenerated", type = "datetime" },
          { name = "Message",       type = "string"   }
        ]
      }
      retentionInDays      = local.custom_log_retention_days
      totalRetentionInDays = local.custom_log_total_retention
    }
  })
}

resource "azurerm_monitor_data_collection_rule" "law_dcr_customlog" {
  name                        = "${local.custom_log_name}DataCollectionRule"
  resource_group_name         = azurerm_resource_group.law_rg.name
  location                    = azurerm_resource_group.law_rg.location
  data_collection_endpoint_id = azurerm_monitor_data_collection_endpoint.dce.id

  destinations {
    log_analytics {
      name                  = azurerm_log_analytics_workspace.law.name
      workspace_resource_id = azurerm_log_analytics_workspace.law.id
    }
  }

  data_flow {
    streams       = ["Custom-${azapi_resource.law_customlog_table.name}"]
    destinations  = [azurerm_log_analytics_workspace.law.name]
    output_stream = "Custom-${azapi_resource.law_customlog_table.name}"
  }

  stream_declaration {
    stream_name = "Custom-${azapi_resource.law_customlog_table.name}"

    column {
      name = "TimeGenerated"
      type = "datetime"
    }

    column {
      name = "Message"
      type = "string"
    }
  }

  tags = {
    environment = "prod"
    project     = "example"
  }
}

Log-Ingestion mit Bash-Script

Damit die frisch angelegten Data-Collection Rules auch tatsächlich Daten erhalten, braucht es einen leichten Weg, lokale oder pipeline-generierte JSON-Dateien in den Azure Monitor Ingestion API-Endpoint hochzuladen.

Nachfolgend findest du ein generisches Bash-Script, das alle wichtigen Best-Practices berücksichtigt:

#!/usr/bin/env bash
set -euo pipefail

###############################################################################
# Konfiguration                                                             #
###############################################################################
SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"
TENANT_ID="00000000-0000-0000-0000-000000000000"

# Azure Monitor Ingestion
RESOURCE="https://monitor.azure.com"
DCR_ID="dcr-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
TABLE_NAME="MyCustomLog_CL"

# Region-Segment aus der DCE-URL, z. B. "westeurope-1"
REGION_SEGMENT="westeurope-1"

# endgültiger Ingestion-Endpoint
DCR_ENDPOINT="https://mdce-${REGION_SEGMENT}.ingest.monitor.azure.com/dataCollectionRules/
                ${DCR_ID}/streams/Custom-${TABLE_NAME}?api-version=2023-01-01"

# Sekunden Verzögerung zwischen zwei Uploads
SLEEP_SECONDS=1

###############################################################################
# Login + Access Token                                                      #
###############################################################################
echo "Authenticating via managed identity …"
az login --identity --tenant "$TENANT_ID" >/dev/null

az account set --subscription "$SUBSCRIPTION_ID"

BEARER_TOKEN="$(az account get-access-token \
  --resource "$RESOURCE" \
  --query accessToken -o tsv)"

###############################################################################
# Hilfsfunktion: Curl mit einfachem Retry-Mechanismus                       #
###############################################################################
retry() {
  local n=1
  local max=5
  local delay=2
  while true; do
    "$@" && break || {
      if [[ $n -lt $max ]]; then
        ((n++))
        echo "Retry $n/$max …"
        sleep $delay
      else
        echo "Fehler: Endpoint nicht erreichbar – Abbruch." >&2
        return 1
      fi
    }
  done
}

###############################################################################
# Upload-Loop                                                               #
###############################################################################
for file in *.json; do
  # leere Arrays oder 0-Byte-Dateien überspringen
  if [[ ! -s "$file" ]] || grep -q '^[[:space:]]*\\[\\][[:space:]]*$' "$file"; then
    echo "Skip: $file enthält keine verwertbaren Daten"
    continue
  fi

  echo "Lade $file hoch …"
  status_code=$(retry curl -s -o /dev/null -w "%{http_code}" -X POST "$DCR_ENDPOINT" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $BEARER_TOKEN" \
    --data-binary @"$file")

  if [[ "$status_code" == "204" ]]; then
    echo "✔ Upload erfolgreich (HTTP 204)"
  else
    echo "✖ Upload fehlgeschlagen (HTTP $status_code)" >&2
  fi

  sleep "$SLEEP_SECONDS"
done

Vorteile dieser Lösung

Nachteile dieser Lösung

Zusammenfassung

Im Vergleich zum klassischen Grafana Pushgateway-Ansatz ist die Azure-native Lösung klar überlegen. Während beim Pushgateway weder robuste Authentifizierung noch Schema-Validierung stattfinden, erzwingt Azure bereits beim Eintritt in die Plattform eine präzise Strukturierung sämtlicher Datenströme. Transformationen passieren damit früh noch vor der Persistierung, statt erst in Dashboards oder Query-Schichten.

Das verbessert:

• Performance bei Abfragen, weil Logs bereits normalisiert vorliegen.
• Datenintegrität,da fehlerhafte Payloads direkt verworfen werden.
• Sicherheit & Governance (RBAC, Private Link, kein offener Port 9091)

Zusammenfassend entscheiden wir uns für ein wenig mehr Setup-Aufwand gegen langfristig niedrigere Betriebs- und Wartungskosten sowie bessere Auditierbarkeit.

Hilfreiche Links für weiterführende Recherchen

• Übersicht zur Ingestion API, inklusive Authentifizierung, Limitierungen und Payload-Format: Logs Ingestion API – Azure Monitor (offizielle Dokumentation)

• Grundlagen zu DCR, inkl. Aufbau, Anwendungsfälle und Beziehung zu DCE und Log Analytics: Data Collection Rules (DCR) – Azure Monitor

• Erklärung, wann ein DCE benötigt wird, wie Regionen funktionieren und wie die URL zusammengesetzt ist: Data Collection Endpoints (DCE) – Azure Monitor

• Sicherheitskonzept von AMPLS mit Beispielen für DNS-Zonen, Endpunkt-Integration und Einschränkungen: Private Link für Azure Monitor und Log Analytics (AMPLS)