Logging mit Azure: Mehr Klarheit, weniger Chaos

Logging gehört zu den wichtigsten Werkzeugen im Cloud-Betrieb. Es liefert Einblicke in das Verhalten von Anwendungen, hilft bei der Fehlersuche, unterstützt Sicherheitsanalysen und ermöglicht die kontinuierliche Verbesserung von Systemen. Doch obwohl Logs so wertvoll sind, werden sie oft falsch eingesetzt. Viele Teams sammeln riesige Mengen an Daten, ohne klare Struktur oder Zielsetzung. Das Ergebnis ist eine unübersichtliche Datenflut, die nicht nur schwer zu analysieren ist, sondern auch hohe Kosten verursacht. Logging sollte deshalb nicht als notwendiges Übel betrachtet werden, sondern als strategisches Element der Systemarchitektur. Wer es richtig plant, kann schneller reagieren, gezielter optimieren und gleichzeitig die Kosten im Griff behalten.

Log Analytics, Azure Monitor oder doch Application Insights

Wer in Azure mit Logging und Telemetrie arbeitet, begegnet schnell drei Begriffen, die oft verwechselt werden, aber unterschiedliche Aufgaben haben: Log Analytics, Azure Monitor und Application Insights. Um Logging gezielt einzusetzen, lohnt sich ein genauer Blick auf die Unterschiede und das Zusammenspiel dieser Komponenten.

Source: Microsoft Learn

Azure Monitor ist der zentrale Dienst für alle Monitoring- und Observability-Funktionen in Azure. Dazu zählen Metriken, Logs, Alerts, Dashboards und Visualisierungen. Application Insights ist ein Bestandteil von Azure Monitor und spezialisiert auf die Überwachung von Anwendungen. Es bietet Funktionen wie Application Map, Live Metrics, Smart Detection, Usage Dashboards und Dependency Tracking. Damit lassen sich Performance-Probleme, Fehler und das Nutzerverhalten in Echtzeit analysieren.

Die Daten aus Application Insights werden, sofern der Workspace-Modus aktiviert ist, direkt im Log Analytics Workspace gespeichert. Das bedeutet, Application Insights ist zwar eine eigene Azure-Ressource, schreibt ihre Telemetrie aber in die zentrale Log-Datenbank von Azure Monitor. Dort können die Daten gemeinsam mit anderen Logs aus Azure-Diensten oder eigenen Anwendungen mit der Kusto Query Language (KQL) abgefragt, korreliert und analysiert werden.

Microsoft entwickelt sich aktuell strategisch in Richtung OpenTelemetry, einem offenen Standard für Telemetrie-Erfassung. OpenTelemetry stellt ein einheitliches SDK für das Sammeln von Metriken, Logs und Traces bereit, unabhängig von Plattform oder Anbieter. In Azure kann das OpenTelemetry SDK direkt in Anwendungen integriert werden. Die gesammelten Daten werden dann über den Azure Monitor OpenTelemetry Exporter an Azure Monitor gesendet. Von dort aus gelangen sie, je nach Konfiguration, ebenfalls in den Log Analytics Workspace. So entsteht eine moderne, offene und erweiterbare Logging-Architektur, die nicht mehr auf proprietäre SDKs angewiesen ist.

Diese Entwicklung macht deutlich, dass Logging in Azure nicht mehr nur einzelne Ressourcen betrifft, sondern Teil einer umfassenden Observability-Strategie ist. Wer frühzeitig auf OpenTelemetry setzt und die Architektur rund um Azure Monitor und Log Analytics sauber gestaltet, schafft eine zukunftssichere Basis für Monitoring, Analyse und Kostenkontrolle.

Typische Fehler im Logging – und wie man sie vermeidet

Ein häufiger Fehler besteht darin, einfach alles zu loggen, was technisch möglich ist. Ohne klare Strategie führt das schnell zu einer unüberschaubaren Datenmenge, die kaum noch sinnvoll ausgewertet werden kann. Gleichzeitig steigen die Kosten, weil jede geloggte Zeile Speicherplatz und Rechenleistung beansprucht. Auch die fehlende Trennung nach Umgebung, etwa zwischen Entwicklung, Test und Produktion, sorgt für Verwirrung und ineffiziente Nutzung. Ein weiteres Problem ist das Fehlen von Sampling-Strategien. Wenn jede einzelne Operation vollständig geloggt wird, entstehen schnell unnötige Datenmengen. Wer Logging sinnvoll einsetzen will, braucht klare Regeln: Welche Daten sind wirklich relevant? Wie lange müssen sie aufbewahrt werden? Und wie oft werden sie tatsächlich abgefragt?

Log Analytics Workspaces: Einer oder viele?

Die Wahl der Workspace-Strategie hat direkte Auswirkungen auf Verwaltung, Sicherheit und Kosten. Ein zentraler Log Analytics Workspace ist oft die einfachste Lösung, wenn mehrere Anwendungen zur gleichen Umgebung oder zum gleichen Team gehören. Er ermöglicht eine einheitliche Analyse und reduziert den Verwaltungsaufwand. Separate Workspaces sind nur dann sinnvoll, wenn es klare organisatorische oder regulatorische Gründe gibt, etwa bei unterschiedlichen Mandanten, Teams oder Projekten mit strikter Trennung. Wer zu früh fragmentiert, schafft sich unnötige Komplexität. Wer zu spät trennt, riskiert unübersichtliche Datenstrukturen. Die Entscheidung sollte deshalb bewusst und mit Blick auf Governance, Zugriffskontrolle und Skalierbarkeit getroffen werden.

@description('Name des Log Analytics Workspace für die Produktionsumgebung (z.B. law-weu-demo-prod-001)')
param logAnalyticsNameProd string = 'law-weu-demo-prod-001'

@description('Name der Application Insights Ressource für die Produktionsumgebung (z.B. ai-weu-demo-prod-001)')
param appInsightsNameProd string = 'ai-weu-demo-prod-001'

@description('Azure-Region')
param location string = 'westeurope'

// Produktionsumgebung
resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2023-10-01' = {
  name: logAnalyticsName
  location: location
  sku: {
    name: 'PerGB2018' // Pay as you go
  }
  retentionInDays: 90 // Standard-Retention für Logs
}

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: appInsightsName
  location: location
  kind: 'web'
  properties: {
    WorkspaceResourceId: logAnalytics.id
  }
}

Kostenfaktoren verstehen und gezielt steuern

Die größten Kosten im Zusammenhang mit Log Analytics entstehen durch das Schreiben von Daten: Die sogenannte Ingestion. Azure unterscheidet dabei zwischen drei Tiers: Analytics, Basic und Auxiliary.

Analytics bietet den vollen Funktionsumfang und kostet entsprechend mehr als die anderen Tiers. Hier liegen die Preise bei etwa 2,65 Euro pro GB anfallender Daten. Es ist ideal für kritische Logs, die regelmäßig und gemeinsam analysiert werden müssen, etwa für Monitoring, Alerts und Dashboards.

Basic ist deutlich günstiger, verursacht aber unter Umständen zusätzliche Kosten beim Abfragen der Daten. Hier reduziert sich der Preis auf 58 Cent pro GB. Die Daten werden standardmäßig aber nur 30 Tage aufbewahrt und können auch nur über diesen Zeitraum eingeschränkt abgefragt werden. Abfragen sind nur auf eine einzelne Tabelle möglich oder mit Lookups auf Analytics-Tabellen. Wer Daten länger aufheben möchte, muss zusätzlich bezahlen, sowohl für die Speicherung als auch für die Abfrage. Basic eignet sich gut für seltene Analysen oder große Datenmengen, bei denen die Kosten pro Abfrage nicht so stark ins Gewicht fallen. Auch wer seine Daten nicht unbedingt korreliert analysieren muss, findet hier eine kostengünstige Lösung.

Auxiliary ist die günstigste Option, allerdings mit Einschränkungen bei der Funktionalität. Hier liegen wir etwa bei 11 Cent pro GB. Der Auxiliary-Tier steht aktuell nur für DCR-basierte Custom Tables (Data Collection Rules) zur Verfügung, in die Daten über den Azure Monitor Agent oder die Logs Ingestion API eingespeist werden. Es eignet sich vor allem für bestimmte System- und Diagnose-Logs, während viele Standardtabellen weiterhin das Analytics- oder Basic-Tier benötigen.

Die Wahl des richtigen Tiers hängt davon ab, wie wichtig und wie häufig die jeweiligen Logs benötigt werden. Kritische Logs, die regelmäßig analysiert werden, gehören in Analytics. Seltene oder sehr umfangreiche Logs lassen sich besser in Basic oder Auxiliary speichern. So lassen sich die Kosten gezielt steuern, ohne auf wichtige Informationen zu verzichten.

Retention, Export und langfristige Speicherung

Standardmäßig bleiben Logs im Log Analytics Workspace zwischen 30 und 90 Tagen erhalten. In Application Insights beträgt die Aufbewahrungsdauer 90 Tage. Wer Daten länger speichern möchte, etwa für Audits oder historische Analysen, muss entweder für eine längere Retention bezahlen oder die Daten exportieren. Der Export in Azure Storage ist eine kostengünstige Alternative, allerdings mit Zusatzkosten für das Schreiben und spätere Abrufen. Dafür lassen sich die Daten bei Bedarf wieder analysieren, etwa mit Azure Data Explorer oder Microsoft Fabric. Wichtig ist, frühzeitig zu entscheiden, welche Daten wie lange benötigt werden. Eine klare Retention-Strategie spart nicht nur Geld, sondern sorgt auch für Übersichtlichkeit.

Sampling, Daily Caps und Logging-Level

Sampling ist ein effektives Mittel, um die Menge an Telemetriedaten zu reduzieren, ohne die Aussagekraft zu verlieren. Es sorgt dafür, dass nur ein repräsentativer Teil der Daten gespeichert wird. Besonders in produktiven Umgebungen ist gezieltes Sampling sinnvoller als harte Tageslimits.

Daily Caps können in Entwicklungsumgebungen hilfreich sein, um Kosten zu begrenzen. Dabei wird ein festgelegtes Limit für die tägliche Datenmenge gesetzt. Sobald dieses Limit erreicht ist, werden keine weiteren Daten mehr gespeichert. Das kann in der Entwicklung sinnvoll sein, um unkontrolliertes Wachstum zu verhindern und Kosten im Griff zu behalten. In der Produktion sind sie jedoch riskant, da bei Erreichen des Limits keine weiteren Daten mehr gespeichert werden.

Logging-Level sollten bewusst gewählt werden. In der Entwicklung ist Debug sinnvoll, in der Produktion reicht meist Information. Drittanbieter-Bibliotheken erzeugen oft zu viele Logs. Hier lohnt es sich, das Level auf Warning oder Error zu setzen. So werden nur relevante Informationen gespeichert. Auch die Möglichkeit die Logging-Level dynamisch anzupassen, etwa über Konfigurationsdateien oder Umgebungsvariablen, kann helfen, die Menge an Logs zu steuern und gleichzeitig die Flexibilität zu erhöhen.

Commitment Tiers und Pre-Aggregation

Für große Datenmengen bietet Azure sogenannte Commitment Tiers an. Diese reservieren eine bestimmte Datenmenge pro Tag zu einem reduzierten Preis. Ab etwa 100 Gigabyte pro Tag lassen sich hier Rabatte von bis zu 30 Prozent erzielen. Wer regelmäßig große Mengen an Logs verarbeitet, kann so signifikant sparen. Hierzu muss aber schon viel an Daten anfallen, sodass sich die Investition lohnt. Der Commitment Tier ist also vor allem für Unternehmen interessant, die regelmäßig große Datenmengen in Azure Log Analytics verarbeiten. Hier können auch mehreren Workspaces von einem Commitment Tier profitieren, solange sie in einem Cluster zusammengefasst sind.

Zusätzlich helfen Summary Rules und Pre-Aggregation dabei, Daten bereits beim Schreiben zu verdichten. Das spart nicht nur Speicherplatz, sondern beschleunigt auch spätere Abfragen. Besonders bei Dashboards oder Reports mit hohem Query-Volumen ist das ein großer Vorteil.

App Logs und Diagnostic Logs – und was wohin gehört

Application Logs stammen aus der eigenen Anwendung und lassen sich gezielt steuern. Diagnostic Logs hingegen werden von Azure-Diensten wie SQL, Key Vault oder App Service erzeugt. Diese Logs können aktiviert werden und können schnell große Datenmengen erzeugen. Sie sind wichtig, aber nicht immer kritisch. Deshalb empfiehlt es sich, sie in günstigere Tiers zu verschieben oder direkt in Azure Storage Account zu exportieren. Dort können sie bei Bedarf wieder analysiert werden. So bleiben sie verfügbar, ohne dauerhaft Kosten zu verursachen. Eine klare Trennung zwischen App Logs und Diagnostic Logs hilft dabei, den Überblick zu behalten und die richtigen Prioritäten zu setzen.

Source: Microsoft Learn

Fazit

Logging ist ein mächtiges Werkzeug, aber nur, wenn es richtig eingesetzt wird. Wer einfach alles loggt, verliert schnell die Kontrolle über Daten, Kosten und Analysefähigkeit. Wer hingegen gezielt plant, welche Daten wann und wo gespeichert werden, kann mit Logging echten Mehrwert schaffen. Die Kombination aus passenden Tiers, Sampling, Retention-Strategien und einer durchdachten Architektur macht den Unterschied. Ziel ist nicht, möglichst viele Daten zu sammeln, sondern genau die richtigen. Und das zu einem Preis, der nachvollziehbar bleibt.

Wie gehst du aktuell mit Logging in Azure um?

Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.