Wer regelmäßig Azure-Umgebungen betreut, kennt das Problem: Die Kosten für Log Analytics wachsen und wachsen, vor allem wenn Microsoft Sentinel mitläuft. In vielen Tenants, die ich mir ansehe, stoße ich schnell auf Kostenblöcke, mit denen niemand gerechnet hat. Häufig liegt das daran, dass sämtliche Tabellen standardmäßig im Analytics-Plan laufen. Mit Table Plans, einer durchdachten Retention und ein wenig KQL lässt sich oft spürbar sparen, ohne dass wichtige Security- und Betriebsdaten verloren gehen.

Log Analytics kennt die drei Table Plans Analytics, Basic und Auxiliary

Seit einiger Zeit lässt sich der Table Plan für jede Tabelle im Log-Analytics-Workspace einzeln festlegen, und zwar auf Analytics, Basic oder Auxiliary. Analytics ist der klassische Plan. Er bietet alle Funktionen, die Logs sind sofort durchsuchbar, KQL steht vollständig zur Verfügung, und Workbooks und Alerts arbeiten wie gewohnt. Basic kostet weniger, bringt aber deutliche Einschränkungen mit sich. Die Suche ist begrenzt, Operatoren wie „join“ oder „parse“ funktionieren nicht, und für Workbooks oder Monitoring-Lösungen taugen die Daten kaum. Für forensische Suchen, etwa nach einem Security-Incident, genügt der Plan dagegen oft. Auxiliary liegt dazwischen und passt vor allem zu großen Mengen an Diagnosedaten, zum Beispiel aus Application Insights, die man nur selten durchsucht. Welche Tabelle welchen Plan unterstützt, hängt von Datentyp und Quelle ab und lässt sich im Azure-Portal unter Log Analytics Workspace → Tables nachsehen (Microsoft-Dokumentation).

Abfragekosten und Retention bergen die meisten Fallen

Im Analytics-Plan zahlt man pro GB aufgenommener Daten, Abfragen sind darin ohne Aufpreis enthalten, solange die Nutzung nicht außergewöhnlich hoch ausfällt. Basic und Auxiliary sind pro aufgenommenem GB deutlich günstiger. Dafür wird jede interaktive Abfrage zusätzlich berechnet, und zwar nach abgefragter Datenmenge in GB. Suchen Admins nachträglich in alten Logs, kann das schnell ins Geld gehen. Gern übersehen wird auch, dass sich die Retention unterscheidet. Analytics bietet eine interaktive Aufbewahrung, die bis zu einer bestimmten Dauer kostenlos ist (z. B. 30 Tage) und danach Geld kostet. Hinzu kommt die Long-Term Retention mit bis zu 12 Jahren, die allerdings nur dem Export und der Aufbewahrung dient und keine schnellen KQL-Suchen erlaubt. Basic und Auxiliary haben zwar ebenfalls eine Retention, sie ist aber weniger komfortabel und bietet keine Langzeit-Analytics. Einzelheiten beschreibt Microsoft auf dieser Seite.

Der Table Plan wird pro Tabelle eingestellt, und zwar unter Log Analytics Workspace → Tables → gewünschte Tabelle → Manage Table → Table Plan. Genau hier setze ich am liebsten an, wenn es ums Sparen geht, statt die Retention für alle Daten pauschal zu kürzen. Noch ein Hinweis: Commitment Tiers, also die Mengenrabatte für Log Analytics, greifen nur bei Analytics-Daten. Basic und Auxiliary werden immer gesondert abgerechnet.

Die Usage-Tabelle zeigt die größten Kostentreiber

Vor dem Umstellen der Pläne sollte klar sein, welche Tabellen überhaupt die meisten Daten liefern. Diese Information steckt in der Usage-Tabelle des Log-Analytics-Workspace. Die folgende Abfrage verwende ich regelmäßig (im Workspace unter Logs):

Usage
| where TimeGenerated > ago(30d)
| summarize DataGB=sum(Quantity) by DataType
| sort by DataGB desc

Sie listet für jeden Datentyp, also für jede Tabelle, die Datenmenge der letzten 30 Tage in GB auf. Damit sieht man auf einen Blick, wo sich ein anderer Table Plan oder eine DCR-Optimierung am stärksten bemerkbar macht. Weitere Analysemöglichkeiten beschreibt dieser Artikel von Microsoft.

DCR-Transformationen filtern überflüssige Daten vor dem Speichern heraus

Transformationen in Data Collection Rules (DCRs) werden oft unterschätzt. Mit ihnen lassen sich Daten filtern oder Feldinhalte kürzen, bevor sie überhaupt im Log-Analytics-Workspace landen. Bei Windows-Security-Logs, Diagnosedaten oder ApplicationInsights fallen viele Datenpunkte an, die weder für die Security noch für den Betrieb von Bedeutung sind und sich deshalb gleich verwerfen lassen. Im DCR-Editor (Azure-Portal → Data Collection Rules → gewünschte DCR → Transformations) legt man dafür einfache Filterregeln in KQL an, zum Beispiel, damit nur Events mit bestimmten EventIDs übernommen werden:

where EventID in (4624, 4625, 4634)

Mein Tipp: Prüfen Sie zuerst, welche Events und Felder tatsächlich genutzt werden, und spielen Sie Transformationen anfangs nur in Test-Workspaces oder auf einzelnen Servern ein.

Ausführlicher gehe ich darauf in meinem Beitrag zur Migration auf den Azure Monitor Agent ein.

Ein genauer Blick auf die Daten bringt mehr als pauschal gekürzte Retention

Spreche ich mit Kunden über die Kosten für Log Analytics, kommt fast immer zuerst der Vorschlag: „Retention überall herunterdrehen und fertig.“ In der Praxis bringt es wesentlich mehr, sich die größten Kostentreiber einzeln vorzunehmen, die Table Plans bewusst zu wählen und DCR-Transformationen einzusetzen. Wer obendrein die Commitment Tiers klug nutzt, hält die Kosten auch bei steigendem Log-Volumen im Zaum und muss trotzdem auf keine Daten verzichten, die Security oder Betrieb brauchen. Die Auswertung der Usage-Tabelle lohnt sich jedes Mal, denn sie erspart einem böse Überraschungen auf der Monatsrechnung.

flowchart TD
    A["Log-Quelle"] --> B["DCR-Transformation"]
    B --> C["Tabelle im Workspace"]
    C --> D["Table Plan wählen"]
    D --> E["Retention konfigurieren"]
    C --> F["Usage-Analyse mit KQL"]

Abbildung: Der Weg der Daten von der Quelle bis zur Kostenoptimierung mit Table Plans, DCR und Usage-Analyse.