Custom Logs ziehen bis September 2026 auf die Logs Ingestion API um

In vielen Azure-Umgebungen, die ich betreue, landen eigene Logs noch immer über die klassische Azure Monitor HTTP Data Collector API im Workspace. Meist stecken kleine Skripte, PowerShell-Module, Logic Apps oder selbst entwickelte Dienste dahinter, die ihre Daten einfach mit dem Workspace-Key in benutzerdefinierte Tabellen schreiben. Nach aktueller Ankündigung ist damit im September 2026 endgültig Schluss. Zukunftssicher ist dann nur noch die neue Logs Ingestion API, und die verlangt an einigen Stellen ein anderes Setup.

Die Logs Ingestion API wird jetzt zur Pflicht

Microsoft stellt die Data Collector API aus zwei handfesten Gründen ein. Zum einen ist die Authentifizierung über den Workspace-Key aus Sicherheitssicht nicht mehr tragbar. Zum anderen lassen sich neuere Anforderungen wie Transformationen damit nicht umsetzen. Die Logs Ingestion API setzt stattdessen auf Data Collection Endpoints und Data Collection Rules (DCRs). Angemeldet wird über Entra ID, entweder mit einer verwalteten Identität oder mit einer Entra-App. Auch bei den Zieltabellen in Log Analytics gibt es kleinere Änderungen. Neue Custom Tables erhalten das Suffix _CL und ein Schema, das sich am neuen Table Creation Wizard orientiert.

Viele Lösungen, die mir in Projekten begegnen, sind ohne große Planung entstanden. Da liegt ein Workspace-Key im App Service, dort schickt eine Logic App alle paar Minuten Daten, und solange alles läuft, fragt niemand nach. Spätestens beim nächsten Audit oder Sicherheitsvorfall zeigt sich dann, dass Shared Keys eigentlich gar nicht mehr verwendet werden sollten.

Tipp: Mit Azure Policy könnt ihr die Nutzung von Workspace Shared Keys erkennen und gezielt abschalten. Die passende Definition steht im Azure-Policy-Katalog unter „Azure Monitor Log Analytics workspaces should not use shared keys for ingestion“.

Bei der Migration ändern sich vier Bausteine grundlegend

Für die Umstellung müsst ihr vier Bausteine neu planen:

• Direkte Aufrufe mit dem Workspace-Key entfallen. Alles läuft über einen Data Collection Endpoint (DCE) und eine Data Collection Rule (DCR).
• Die Anmeldung erfolgt über Entra ID, entweder mit einer verwalteten Identität (etwa einer Logic App oder VM) oder mit einer App-Registrierung samt Zertifikat bzw. Secret.
• Die Zieltabellen (Custom Logs) legt ihr im neuen Format an, also mit dem Suffix _CL und fest definierten Spalten.
• Transformationen und Schema-Mappings pflegt ihr direkt in der DCR und nicht mehr im Payload oder am Ziel.

Den konkreten Ablauf zeigt das Diagramm unten. Technisch ist der Wechsel gut zu bewältigen, er verlangt aber auch ein anderes Berechtigungs- und Rollenkonzept. Bei bestehenden Skripten und Logic Apps ist genau das oft die größte Hürde.

flowchart TD
    Quelle["Quelle (Skript, App, Logic App)"] --> Auth["Authentifizierung (Entra App oder verwaltete Identität)"]
    Auth --> DCE["Data Collection Endpoint"]
    DCE --> DCR["Data Collection Rule (DCR)"]
    DCR --> Tabelle["Custom Table (_CL)"]

Abbildung: So gelangen eigene Logs künftig von der Quelle über DCE und DCR in die Custom Table.

Data Collection Endpoint und Rule entstehen in zwei Schritten

Zuerst legt ihr im Azure-Portal oder per ARM/Bicep einen Data Collection Endpoint an. Er ist die Netzwerkschnittstelle, über die die Daten hereinkommen. Anschließend erstellt ihr eine Data Collection Rule. Sie wird mit dem Endpoint verknüpft, legt das Ziel aus Workspace und Tabelle fest und enthält bei Bedarf Transformationen. Diese Transformationen sind KQL-Ausdrücke direkt in der DCR und in der Praxis sehr hilfreich. Ihr könnt damit Felder umbenennen oder herausfiltern und Daten anreichern, was sich vor allem dann auszahlt, wenn mehrere Quellen unterschiedliche Formate liefern.

Die Zieltabelle legt ihr ausdrücklich im neuen Format an, zum Beispiel so (im Azure-Portal unter „Log Analytics Workspace“ → „Tables“ → „Create“ → „Custom log“):

{
  "tableName": "CustomEvents_CL",
  "columns": [
    {"name": "EventTime", "type": "datetime"},
    {"name": "Level", "type": "string"},
    {"name": "Details", "type": "dynamic"}
  ]
}

Beispiel für eine neue benutzerdefinierte Tabelle (im Portal anlegen und das Schema bei Bedarf anpassen).

Achtet auf die passenden Berechtigungen. Die verwendete Identität braucht auf der DCR mindestens die Rolle „Monitoring Metrics Publisher“. Zugewiesen wird sie über Access Control (IAM) im Resource-Blade der DCR, alternativ per PowerShell oder ARM.

Skripte und Logic Apps brauchen eine neue Authentifizierung

Die meiste Arbeit steckt in den Clients. Jede Anwendung, die bisher mit dem Workspace-Key (Shared Key) arbeitet, muss angepasst werden. Bei PowerShell oder eigenen Apps greift ihr am besten zum SDK, etwa Azure.Monitor.Ingestion für .NET, oder ruft die REST-Schnittstelle direkt mit einem OAuth2-Token auf. In Logic Apps braucht ihr einen HTTP-Connector mit Entra-Anmeldung. Ärgerlich ist, dass viele Security-Tools und Integrationen von Drittanbietern die neue API noch nicht unterstützen. Dann bleibt oft nur ein Feature-Request beim Hersteller oder ein Umweg über Azure Functions.

Alte Data-Collector-Aufrufe erkennt ihr im Code meist an URLs wie https://<workspace-id>.ods.opinsights.azure.com/api/logs?api-version=... und am X-API-Key im Header. Die Logs Ingestion API spricht dagegen den Data Collection Endpoint an, der meist unter https://<endpoint-name>.<region>.ingest.monitor.azure.com erreichbar ist, und erwartet zur Authentifizierung ein Bearer-Token für die Resource-URI https://monitor.azure.com/.

Einen guten Einstieg bietet die Microsoft-Dokumentation zur Logs Ingestion API. Wer von Legacy-Custom-Logs kommt, sollte außerdem das Migrationsdokument von Microsoft lesen.

Vor der Umstellung spüre ich alle Shared-Key-Nutzer auf

In vielen Workspaces ist nirgends festgehalten, welche Anwendungen oder Personen den Workspace-Key überhaupt noch verwenden. Deshalb prüfe ich immer zuerst, wie die Shared Keys genutzt werden. Einen schnellen Überblick liefert das Azure-Portal im Workspace unter „Workspace summary“ → „Shared key usage“. In Sentinel-Workspaces gehören vor allem Custom Connectors zu den typischen Migrationskandidaten. Sie hängen oft noch am alten Collector, lassen sich aber auf die Logs Ingestion API umstellen, sofern der Hersteller des Connectors mitzieht.

Über Log Analytics (KQL) lässt sich die Nutzung der alten API leider nur eingeschränkt nachvollziehen, weil die Authentifizierung außerhalb des KQL-Loggings abläuft. Habt ihr eure eigenen Pipelines geprüft, stellt ihr alle Skripte und Apps auf die neue API um. Bei SaaS-Lösungen lohnt sich außerdem die Nachfrage beim Anbieter, welchen Migrationspfad er vorsieht.

Eine frühe Migration zahlt sich doppelt aus

Auf den ersten Blick wirkt die Logs Ingestion API aufwendiger, dafür gewinnt ihr deutlich an Sicherheit. Shared Keys verschwinden aus den Skripten, die Berechtigungen sind sauber auf DCR-Ebene geregelt, und Transformationen greifen direkt an der Quelle. Das senkt die Fehlerquote und verkleinert die Angriffsfläche. Ich rate dazu, die Migration jetzt zu planen und nicht erst kurz vor dem Stichtag im September 2026. Verschafft euch mit einer Inventur einen Überblick über alle Quellen und legt für jede davon ein Migrationsziel fest. Vor allem in Verbindung mit Sentinel oder automatisierter Governance erspart euch das im Ernstfall viel Ärger. Hinzu kommt, dass die neue API gut dokumentiert ist und sich inzwischen sehr zuverlässig per Terraform oder Bicep einrichten lässt. Der Umstieg lohnt sich, und ab September 2026 führt ohnehin kein Weg mehr daran vorbei.