Kostenoptimierung in Azure Log Analytics und Azure Application Insights

Disclaimer

Diese Fallstudie basiert auf einer realen Kostenoptimierungsanalyse für Azure Log Analytics und Azure Application Insights. Aus Datenschutzgründen wurden alle Kundennamen, Ressourcenbezeichnungen und spezifischen Identifikatoren anonymisiert. Die dargestellten Daten, Analysen und Optimierungsmaßnahmen entsprechen jedoch den tatsächlichen Gegebenheiten und Ergebnissen des Projekts.

Inhalt

• Analyse der bestehenden Umgebungen
  • DEV-Umgebung
  • QA-Umgebung
• Erkenntnisse aus der DEV- und QA-Umgebung
  • Daten-Ingestion optimieren
  • Datenaufbewahrung und Wiederhestellungsstrategien
  • Transformationen mit KQL
  • Kostenmanagement
• Handlungsempfehlungen zur Kostenoptimierung
  • Daten-Ingestion optimieren
  • API-Endpunkte analysieren & gezielt filtern
  • Tabellenpläne evaluieren & umstellen
  • Tageslimits nur als Notlösung
  • Kostenmanagement & Transparenz
  • Weitere Optimierungen
• Fazit

Analyse der bestehenden Umgebungen

DEV-Umgebung

Log Analytics

• Ressource: dev-demo-analytics-log
• Standort: France Central
• Preis pro GB: €2.358 (Stand: 23.07.2025)

App Insights

• Ressource: dev-demo
• Standort: West Europe

Visualisierte Übersicht über 90 Tage Zeitraum

Abbildung 1: Zeitraum der letzten 90 Tagen für die 5 wichtigsten Tabellen von App Insights

Anzahl der Events in Summe in 90 Tagen:

Nutzung in GB aufsteigend sortiert:

Abbildung 2: Prozentuale Verteilung der Tabellen in App Insights

Tabellen, die optimiert werden müssen:

1. AppPerformanceCounters
2. AppTraces
3. AppDependencies
4. AppEvents

Diagnoseeinstellungen

Keine Einstellungen vorhanden

Annahme zum Zeitpunkt der Datenreduzierung

Abbildung 3: Zeitpunkt einer vermutlichen Maßnahme zur Kostenoptimierung

Ab dem 12.06 wurden Maßnahmen getroffen, um weniger Daten von App Insights zu speichern. Möglicherweise wurde das Tageslimit im Log Analytics auf 1 GB/Tag gesetzt, um die Datenmenge sofort zu reduzieren.

Abfrage der Tabelle Dependencies mit Zeitraum 90 Tage

// KQL-Abfrage für die Tabelle Dependencies
dependencies
| where timestamp >= startofday(ago(90d))
| summarize sum(_BilledSize) by operation_Name
| render barchart

Abbildung 4: Auszug von 1000 Einträgen, die abgerechnet werden und Kosten verursachen

Abbildung 5: Gruppierter Datenauszug von 1000 Einträgen mit einer Rundung von GB auf 2 Nachkommastellen

Zusammenfassung der Telemetriedaten

1. Kostenanalyse der API-Endpunkte, die am meisten Datenvolumen und Kosten verursachen
2. Optimierungspotenzial, da häufige Datenerfassung zu den API-Endpunkten wie etwa POST Container/GetContainerToken nicht unbedingt notwendig sind und ggf. reduziert werden können. Für Entwickler-Teams jedoch interessant und auswertbar, wie sich die Anwendung verhält
3. Zeitraum auf 90 Tage begrenzt, um aktuelle Daten einzusehen und Trends zu erkennen, welche API-Endpunkte besonders häufig angesprochen werden
4. Transparenz für Abrechnungen, da die Auswertung der KQL mit dem Filter _BilledSize aggregiert werden. Entscheidend für Kostenkontrollen und Forecastsmaßnahmen

Mit dieser detaillierten Datenanalyse lassen sich etwa Dashboards erstellen für eine kontinuierliche Überwachung. Man kann Warnungen einrichten, wenn einzelne API-Endpunkte ungewöhnlich viel Traffic in kurzem Zeitraum erzeugen und dadurch Kosten verursachen oder Code-Reviews anstoßen, um teure API-Endpunkte zu verbessern

QA-Umgebung

Log Analytics

• Ressource: dev-demo-analytics-log
• Standort: France Central
• Preis pro GB: €2.358 (Stand: 23.07.2025)

App Insights

• Ressource: qa-demoapp1 und qa-demoapp2
• Standort: West Europe und Germany West Central

Visualisierung in 90 Tagen Zeitraum

Abbildung 6: Zeitraum der letzten 90 Tagen für die 5 wichtigsten Tabellen von App Insights in der QA-Umgebung

Dashboard

Abbildung 7: Dashboard der abrechenbaren Tabellen von App Insights sortiert nach GB

Extrahierte Daten aus dem Dashboard

Kostenberechnung (Preis: €2.358 pro GB, Stand: 23.07.2025):

Hinweis: 962,88MB = 0,963GB (1GB = 1024MB)

Berechnung:
Kosten je Tabelle = Volumen (GB) × €2.358
Gesamtkosten = Summe aller Tabelleneinzelkosten

Telemetriedaten von 90 Tagen Zeitraum

Zusammenfassung der Telemetriedaten von 90 Tagen

1. Allgemeiner Trend “Down” von Anfang bis Ende zu erkennen, was auf ein insgesamten Rückgang der täglichen Datenerfassung zu verstehen ist
   1. Weniger Aktivitäten oder Nutzung der Anwendungen
   2. Maßnahmen zur Kostenoptimierung wie aktivierten Sampling oder SDK Konfigurationen
2. AppDependencies ist auffällig hoch und zeigt regelmäßig hohe Datenmengen die Kosten verursachen
3. Andere Tabellen sind unauffällig und speichern wenig Daten im Vergleich

Erkenntnisse aus der DEV- und QA-Umgebung

Daten-Ingestion optimieren

1. Filterung an der Quelle mithilfe von Data Collection Rules und Tabellentransformation um nur relevante Metriken und Logs aus App Insights und Log Analytics zu sammeln und bei Bedarf auch nur die notwendigen Spalten aufnehmen. Damit wird das Datenvolumen reduziert, minimiert die zu speichernden Daten und senkt die Kosten
   1. Handlungsempfehlung: Ja
2. Sampling für App Insights aktiveren um zu verhindern, dass unnötig viele Telemetriedaten (Requests, Dependencies, Traces, PerformanceCounters, Metrics) erfasst werden
   1. Handlungsempfehlung
      1. Sampling aktivieren
      2. Erweitertes Sampling
         1. Adaptives Sampling bei Spikes aktivieren (geht über SDK, nicht im Portal)
      3. Duplizierte Datenerfassung im Code ausschließen (aktive Maßnahme)
      4. Anpassen der host.json Datei beim Einsatz von Azure Functions
         1. logging.applicationInsights.samplingSettings
         2. logging.logLevel
      5. Einsatz von SDK und deaktivieren der automatischen Datenerfassung
         1. Instrumentationkey umbenennen oder nicht als Variable setzen
         2. SDK installieren, konfigurieren und steuern der Datenerfassung, die auch wirklich Business kritisch sind (Höchstes Einsparungspotenzial)
3. Generell gilt regelmäßig zu Prüfen welche Anwendungen oder Dienste besonders viele Daten speichern und prüfen ob das Volumen durch Filterung oder Anpassungen weiter gesenkt werden kann
4. Begrenzen der Zeitintervallen für unterschiedliche Dienste wie etwa von Dashboard’s, Arbeitsmappen, Power-BI Berichte, KQL-Abfragen (im Basic-Plan), DCR’s und Verfügbarkeitstest (Azure Monitor)
   1. Keine Maßnahmen erforderlich, da keine Einsicht zu den Diensten und keine Verfügbarkeitstests aktiv sind die Kosten verursachen könnten

Tageslimit von Log Analytics

Tageslimit: Diese Maßnahme Ist derzeit aktiv auf DEV und QA mit 1 GB/Tag

Problem: Sobald Log Analytics das Datenspeicherlimit von 1 GB/Tag erreicht, z. B. um 13 Uhr, dann werden alle weiteren Logs nicht mehr gespeichert von allen anderen Diensten (auch die, die ich zurzeit nicht sehe wegen Berechtigungen, wie z. B. Container Insights, Activity Logs). Diese Daten tauchen nirgendswo mehr auf und sind verloren. Alle dieser Dienste konkurrieren um das speichern der Daten

Folge: Verlust der Daten kann zu sogenannte “Blindspots” im Monitoring führen, Visualisierungen in Dashboard’s zeigen nur Daten bis zu einem bestimmten Limit an. Wenn in einem Messzeitraum Daten ausfallen, kann das dazu führen, dass Alarme nicht korrekt ausgelöst werden, selbst dann, wenn der Trend eigentlich einen kritischen Anstieg zeigt und ein Alarm notwendig gewesen wäre

Empfehlung: Das sollte nur als letzte Option angesehen werden, wenn die Daten unkontrolliert an Log Analytics gespeichert werden. Eine bessere Option ist es, Sampling (und zusätzlich Adaptives Sampling über SDK zu nutzen) zu aktivieren in den jeweiligen Diensten (dann kommt ein Bruchteil der Daten zu Log Analytics) oder/und wenn möglich Data Collection Rules und Tabellentransformation um Daten vorher zu filtern, bevor die in Log Analytics gespeichert werden

Datenaufbewahrung und Wiederhestellungsstrategien

Zurzeit ist keine aktuelle Umstellung notwendig, da bereits der Standardzeitraum von 30 bzw. 90 Tagen für die Tabellen von App Insights konfiguriert sind und keine längere Aufbewahrungszeitraum aus Compliance Gründen vorhanden sind

Dennoch gibt es eine Möglichkeit Kosten einzusparen bei der Auswahl eines richtigen Tabellenplan’s:

• Handlungsempfehlung:
  • Identifizieren von Tabellenpläne, die von “Analytics” zu “Basic” umgestellt werden können => moderates bis hohes Einsparungspotenzial

Einstellungen der Pläne für Tabellen

Originaler Link zu den Plänen: https://learn.microsoft.com/de-de/azure/azure-monitor/logs/data-platform-logs#table-plans

Die folgende Tabelle wurde um die Preise vom Standort Frankreich, Zentral von Azure Log Analytics erweitert

Zusammenfassung der Tabellenpläne

• Analytics: für kritische Logs, die langfristig und mehrfach in komplexen Queries auszuwerten sind
• Basic: für hohe Log-Volumen mit kurzer Abfragedauer (= Interaktive Aufbewahrungszeitraum 30 Tage) und geringem bis keinen Bedarf an Cross-Table-Analysen

Identifizierte Tabellen für App Insights

Wichtige Tabellen in App Insights

Zusammengefasst:

Diese Tabellen repräsentieren verschiedene Telemetriedaten, die App Insights sammelt, um die Leistung, Zuverlässigkeit und Nutzung der Anwendungen in den DEV- und QA-Umgebungen zu überwachen und zu analysieren

Transformationen mit KQL

Bei der Umstellung einzelnen Tabellenpläne von “Analytics” nach “Basic” können zusätzliche Kosten für die zu analysierenden Daten anfallen. Aus diesem Grund ist es wichtig, nur die Daten zu aggregieren, die für die jeweilige Visualisierung und Auswertung notwendig sind

Kostenmanagement

1. Fortlaufenden Überblick über die Menge der Datenerfassung als auch den Zeitraum von Kosten in Azure Cost Management behalten um frühe Optimierungsmaßnahmen zu erkennen
2. Budgetgrenzen und Benachrichtigungen konfigurieren um Kostenüberschreitungen zu vermeiden und frühzeitig zu reagieren

Handlungsempfehlungen zur Kostenoptimierung

Daten-Ingestion optimieren

Ziel: Reduktion des Datenvolumens bereits an der Quelle

Empfehlungen:

• Nutzung von Data Collection Rules und Tabellentransformation zur Filterung relevanter Telemetriedaten
• Sampling aktivieren in App Insights (auch adaptives Sampling via SDK)
• Mehrfache Datenerfassung vermeiden (z. B. doppelte SDK-Initialisierung)
• LogLevel optimieren in AppTraces (weniger Debug, mehr Warn/Error)

API-Endpunkte analysieren & gezielt filtern

Ziel: Reduktion von Datenkosten durch Analyse hochfrequenter API-Endpunkte

Empfehlungen:

• KQL-Auswertungen automatisieren (nach _BilledSize gruppieren)
• Endpunkte wie z. B. POST /GetContainerToken prüfen
• Regelmäßige Feedbacks an Entwicklerteams für gezielte Optimierung

Tabellenpläne evaluieren & umstellen

Ziel: Speicherkosten durch geeignete Nutzung von Tabellenplänen senken

Empfehlungen:

• Tabellen auf den Basic-Plan umstellen
  • Geringere Kosten (€0,697/GB statt €2,358/GB)
• Analytics-Plan beibehalten wenn Cross-Table-Abfragen notwendig sind und Warnungen eingesetzt werden

Tageslimits nur als Notlösung

Ziel: Vermeidung von Monitoring-Lücken

Empfehlungen:

• Tageslimit von 1 GB/Tag aktuell aktiv aber nicht als Dauerlösung zu verwenden
• Risiko: Wenn das Limit erreicht ist werden alle weiteren Logs verworfen, was zu Blindspots führen kann
• Eine bessere Lösung ist es ein Kombination aus Sampling (und adaptiven Sampling im SDK) und DCRs zu verwenden

Kostenmanagement & Transparenz

Ziel: Frühzeitige Erkennung und Steuerung der Kosten

Empfehlungen:

• Azure Cost Management Alerts & Budgets einrichten
• Dashboards zur Kosten- und Volumenüberwachung erstellen

Weitere Optimierungen

• InstrumentationKey deaktivieren oder SDK vollständig konfigurieren
• Intervallzeiträume anpassen, z. B. bei Dashboard’s
• Weniger Daten erfassen
• Nur relevante Daten speichern
• Bewusstsein in Teams schaffen
• Anpassung der host.json in Azure Functions:
  • logging.applicationInsights.samplingSettings
  • logging.logLevel

Fazit

Die durchgeführte Kostenoptimierungsanalyse für Azure Log Analytics und Azure Application Insights in den DEV- und QA-Umgebungen hat gezeigt, dass durch gezielte Maßnahmen erhebliche Kosteneinsparungen erzielt werden können.

Durch die Implementierung von Data Collection Rules und Tabellentransformation, die Aktivierung von Sampling-Methoden und die Evaluierung der Tabellenpläne konnten die Datenerfassungs- und Speicherkosten signifikant reduziert werden und führten zu einer geschätzten Kostenersparnis von rund 70% beim Kunden.