Azure Monitor vs. Loki

Observability als Service oder als eigene Infrastruktur

Azure Monitor und Loki verfolgen zwei grundverschiedene Ansätze für Monitoring und Logging. Beide liefern Einblicke in Systeme, Metriken und Logs. Der entscheidende Unterschied liegt jedoch nicht in der Sichtbarkeit, sondern in der Frage, wer die Kontrolle über Daten, Kosten und Architektur behält.

Observability ist kein Komfort-Feature. Sie entscheidet darüber, wie schnell Systeme verstanden, Fehler analysiert und Vorfälle aufgearbeitet werden können. Wer hier falsche Annahmen trifft, verliert nicht nur Transparenz, sondern langfristig auch Steuerungsfähigkeit.

Azure Monitor: Observability als gemanagter Dienst

Azure Monitor ist Microsofts zentrale Observability-Plattform. Metriken, Logs, Traces und Alerts sind eng integriert und vollständig gemanagt. Für Azure-Workloads funktioniert das reibungslos. Logs fließen automatisch aus VMs, AKS, App Services, Entra ID und vielen weiteren Diensten. Dashboards stehen sofort zur Verfügung, Alerts lassen sich mit wenigen Klicks definieren, Abfragen werden über KQL formuliert.

Der operative Aufwand ist minimal. Infrastruktur für Logging und Monitoring muss nicht geplant, betrieben oder skaliert werden. Observability wird konsumiert – ähnlich wie Compute oder Storage. Für Teams, die schnell produktiv sein wollen oder wenig Betriebsverantwortung übernehmen können, ist das attraktiv.

Diese Bequemlichkeit ist jedoch nicht neutral.

Integration als Grenze

Azure Monitor ist auf Azure optimiert – nicht auf Offenheit. KQL ist mächtig, aber proprietär. Wer sich darauf einlässt, bindet Analyse, Dashboards und Wissen an ein spezifisches Abfragemodell. Logs liegen in Microsofts Datenplattform, Retention, Zugriff und Abrechnung folgen dem Azure-Preismodell.

Gerade bei steigenden Logmengen wird das relevant. Abrechnung erfolgt nach ingestierten Daten, Retention-Dauer und Abfragen. Security-Events, Audit-Logs oder Debug-Logs in hoher Frequenz lassen die Kosten schnell steigen – oft erst sichtbar, wenn Observability bereits geschäftskritisch ist.

Ein späterer Ausstieg ist möglich, aber aufwendig. Daten müssen exportiert, Abfragen neu formuliert und Dashboards neu aufgebaut werden. Observability wird so vom unterstützenden Werkzeug zum strukturellen Lock-in.

Loki: Logs als Infrastruktur, nicht als Produkt

Loki steht bewusst auf der anderen Seite. Open Source, reduziert im Funktionsumfang, eng verzahnt mit Kubernetes und dem Grafana-Ökosystem. Logs werden nicht vollständig indexiert wie bei klassischen Log-Systemen, sondern über Labels erschlossen. Der eigentliche Log-Inhalt bleibt weitgehend unindiziert.

Dieser Ansatz hat Konsequenzen. Abfragen funktionieren anders, Analyse erfordert saubere Label-Strategien. Gleichzeitig sinken Storage- und Index-Kosten drastisch. Loki skaliert horizontal, ist speicher­effizient und eignet sich besonders für hohe Logvolumina aus Kubernetes-Workloads.

Der Preis dafür ist Betrieb. Loki muss geplant, betrieben, überwacht und gesichert werden. Dafür liegt die Kontrolle vollständig beim Betreiber.

Datenhoheit und Portabilität

Der entscheidende Unterschied zwischen Azure Monitor und Loki ist die Datenhoheit. Loki kann überall laufen: On-Premises, in Kubernetes, in jeder Cloud, auch hybrid. Storage ist austauschbar – von lokalem Object Storage bis zu S3-kompatiblen Backends. Retention-Regeln sind selbst definiert, Kosten transparent kalkulierbar.

Logs bleiben Logs. Sie werden nicht zu einem proprietären Analyseprodukt mit unklarem Preismodell. Abfragen mit LogQL sind offen, reproduzierbar und portabel. Dashboards in Grafana lassen sich migrieren, Versionieren und wiederverwenden.

Gerade in Plattform-Szenarien ist das entscheidend. Observability-Daten werden hier nicht nur für Betrieb genutzt, sondern für Security-Analysen, Audits, Incident-Reviews und Compliance-Nachweise. Diese Daten aus der Hand zu geben, ist eine strategische Entscheidung.

Kosten als Architekturtreiber

Azure Monitor glänzt bei Convenience. Für rein Azure-zentrierte Setups mit moderatem Logvolumen ist das oft ausreichend. Sobald Logs jedoch zur zentralen Datenquelle werden, kippt das Modell. Abfrage- und Retention-Kosten werden zum Risikofaktor – nicht, weil Observability unnötig wäre, sondern weil sie plötzlich wirtschaftlich begrenzt wird.

Loki behandelt Logs als Infrastruktur. Kosten entstehen primär durch Storage und Betrieb, nicht durch jeden Zugriff oder jede Abfrage. Das macht das Modell langfristig kalkulierbar. Observability wird nicht eingeschränkt, weil sie „zu teuer" wird.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

Azure Monitor ist sinnvoll für:

• klar Azure-zentrierte Workloads
• moderate Logvolumina
• Teams mit Fokus auf schnelle Umsetzung
• Szenarien ohne langfristige Observability-Strategie

Loki ist sinnvoll für:

• Kubernetes als zentrale Plattform
• hohe Logvolumina
• Anforderungen an Kostenkontrolle
• Security-, Audit- und Compliance-Use-Cases
• Architekturen mit Multi-Cloud- oder Hybrid-Perspektive

Fazit

Observability entscheidet darüber, wie gut Systeme beherrschbar bleiben. Sie ist kein Komfort-Feature – sie ist ein Machtfaktor im Betrieb.

Azure Monitor optimiert auf Konsum und Integration. Loki optimiert auf Kontrolle und Kalkulierbarkeit.

Der Unterschied ist nicht primär technisch. Er ist strategisch: Konsumiert man Observability – oder betreibt man sie bewusst als Teil der eigenen Plattform.