Observability-Strategie: Monitoring-Kosten senken ohne Sichtbarkeit zu verlieren

Monitoring-Kosten entstehen nicht durch das Beobachten selbst, sondern durch die Art, wie Daten gespeichert und abgefragt werden. Eine durchdachte Observability-Strategie mit klarer Labeling-Hierarchie, getrennten Retention-Stufen und einem einheitlichen Stack kann die laufenden Kosten erheblich senken – ohne dabei Diagnosefähigkeit zu verlieren. Dieser Beitrag zeigt, wie das in der Praxis funktioniert.

Das Wichtigste in Kürze

• Der größte Kostentreiber im Monitoring ist unkontrolliertes Log-Volumen mit vollständiger Indizierung – nicht die Tool-Lizenz selbst.
• Grafana Loki speichert Logs komprimiert in Object Storage und indexiert nur Labels; bei hohem Log-Volumen ist das deutlich günstiger als Volltext-Indizierung.
• Eine Labeling-Strategie muss vor der Migration stehen – sie entscheidet über Abfragegeschwindigkeit und Betriebskosten.
• Unterschiedliche Retention-Stufen für Debug-Logs, Anwendungs-Logs und Compliance-Logs vermeiden unnötige Speicherkosten.
• OpenTelemetry als Instrumentierungsstandard verhindert Vendor-Lock-in und macht spätere Tool-Wechsel ohne Neuinstrumentierung möglich.

Was Observability von Monitoring unterscheidet – und warum das die Kosten treibt

Monitoring stellt vordefinierte Fragen: Ist der Service erreichbar? Liegt die Fehlerrate über einem Schwellenwert? Observability geht weiter: Sie erlaubt es, beliebige Fragen zu stellen, die man vorher nicht kennen konnte – zum Beispiel warum eine spezifische Automation in einer bestimmten Kontogruppe deutlich länger läuft als in allen anderen, ohne dass ein Alert ausgelöst wurde.

Der Unterschied ist kein Marketingbegriff. Er hat konkrete technische Konsequenzen: Echte Observability erfordert Logs, Metriken und Traces, die miteinander korrelierbar sind. Systeme, die nur aggregierte Metriken vorhalten, stoßen beim Debugging komplexer, verteilter Architekturen an klare Grenzen – weil sie Fragen nur beantworten können, die jemand vorher gestellt hat.

Der Kostenpunkt entsteht, weil Observability bedeutet, viele Daten über längere Zeiträume vorzuhalten. Wer dabei nicht differenziert, zahlt für Debug-Output, der nach 24 Stunden wertlos ist, denselben Preis wie für Compliance-Logs, die gesetzlich für Jahre aufzubewahren sind. Die erste Kostenstrategie ist deshalb immer eine Retention-Strategie, bevor es um Tools geht.

Warum Monitoring-Kosten in wachsenden Systemen unkontrolliert steigen

Log-Volumen als primärer Kostentreiber

In den meisten Produktionssystemen erzeugen wenige Services den Großteil des Log-Volumens: API-Gateway, Authentifizierungsservice, Datenbank-Proxy und – sofern vorhanden – Message-Broker wie Kafka oder RabbitMQ. Diese Services loggen bei hohem Durchsatz jede einzelne Transaktion, häufig mit mehr Feldern als für Diagnose und Compliance tatsächlich notwendig wäre.

Wenn diese Logs vollständig und ohne Kompression in einem Index landen, skalieren die Kosten linear mit dem Traffic. Bei ELK-Stack-Setups bedeutet das: Wächst das Log-Volumen durch mehr Nutzer oder mehr laufende Kampagnen, wachsen auch die Betriebskosten – durch mehr Storage, mehr Shard-Verwaltung und höheren RAM-Bedarf für die Elasticsearch-Knoten. Wer das nicht aktiv begrenzt, zahlt für dasselbe Monitoring jeden Monat mehr, ohne mehr Diagnosetiefe zu gewinnen.

Ein häufig übersehener Hebel: Nicht jeder Log-Level muss dieselbe Lebensdauer haben. Debug-Logs, die nur während der Entwicklung oder bei akuten Incidents gebraucht werden, nach 7 bis 14 Tagen zu löschen, reduziert das Volumen im Langzeitstapel oft erheblich, ohne jemals einen Audit zu behindern.

Tool-Fragmentierung als versteckter Kostentreiber

Viele Teams haben über Zeit einzelne Werkzeuge eingeführt: ein APM-Tool für Performance-Metriken, einen separaten Logging-Stack, ein weiteres System für Uptime-Monitoring, ein gesondertes Tool für Distributed Tracing. Jedes dieser Werkzeuge trägt eigene Lizenz- oder Speicherkosten, eigenen Wartungsaufwand und eigene Onboarding-Kosten für neue Teammitglieder.

Noch gewichtiger als die direkten Kosten ist das Korrelationsproblem: Wenn eine E-Mail-Kampagne verzögert ausgeliefert wird, muss ein Techniker manuell zwischen verschiedenen Dashboards wechseln und Zeitstempel abgleichen. Korrelierte Observability – ein Stack, der Logs, Metriken und Traces verbindet – verkürzt die Diagnosezeit erheblich und senkt damit den tatsächlichen Betriebsaufwand pro Incident.

Einblicke aus dem Betrieb vieler Systeme zeigen: Der Umstieg auf einen einheitlichen Stack spart nicht nur Lizenzkosten, sondern vor allem Zeit. Entwickler, die nicht zwischen fünf Tabs wechseln müssen, lösen Probleme schneller – das hat direkten Einfluss auf die mittlere Zeit bis zur Problemlösung.

Die drei Säulen einer kosteneffizienten Observability-Strategie

Logs: Label-basiertes Speichern statt Volltext-Indizierung

Grafana Loki unterscheidet sich von Elasticsearch in einem zentralen Punkt: Loki indexiert keine Inhalte, sondern nur Labels – Metadaten wie Service-Name, Umgebung, Region oder Kritikalitätsstufe. Die eigentlichen Log-Zeilen werden komprimiert als Chunks in Object Storage abgelegt, typischerweise AWS S3, Google Cloud Storage oder Azure Blob Storage. Object Storage ist pro Gigabyte deutlich günstiger als Elasticsearch-Indices, die für schnellen Zugriff auf Festplatten mit höherem Durchsatz angewiesen sind.

Das hat eine wichtige Konsequenz für Abfragen: Loki selektiert zuerst anhand der Labels alle relevanten Log-Streams und durchsucht dann nur diese Streams nach dem gesuchten Muster. Labels sind damit die wichtigste Designentscheidung. Zu wenige Labels zwingen bei jeder Abfrage zur Durchsuchung großer Datenmengen. Zu viele Labels – oder Labels mit hoher Kardinalität wie User-IDs – erzeugen eine Kardinalities-Explosion, die Performance und Speicherbedarf gleichermaßen treiben.

Eine pragmatische Labeling-Hierarchie für mittlere bis große Systeme:

• environment – production, staging, development
• service – api, worker, scheduler, integration-service
• region – für geografisch verteilte Systeme und DSGVO-Nachweise relevant
• criticality – critical, standard, debug

Labels tragen ausschließlich Werte mit niedrigem Kardinalitätspotenzial. User-IDs, Request-IDs oder Order-IDs gehören nicht in Labels, sondern als Felder in die strukturierte Log-Zeile selbst. Diese Regel klingt einfach, wird aber in der Praxis regelmäßig gebrochen – weil Labels intuitiv wie Tags aussehen und Entwickler sie entsprechend einsetzen.

Metriken: Kardinalität im Griff behalten

Metriken sind im Betrieb günstig – eine Zeitreihe mit einer Messung pro Minute belastet kaum Ressourcen. Das Problem liegt in Umfang und Kardinalität: Teams erzeugen oft Hunderte von Metriken, von denen im Regelbetrieb nur wenige Dutzend abgefragt werden. Das allein ist kein Problem, solange die Kardinalität kontrolliert bleibt.

Teuer werden Metriken, wenn Labels mit hoher Kardinalität verwendet werden. Eine User-ID oder eine Order-ID als Metrik-Label erzeugt eine neue Zeitreihe pro Wert. Prometheus und kompatible Systeme skalieren dabei nicht linear: Hohe Kardinalität bei Metriken ist einer der häufigsten Gründe für unerwartet hohen Speicherbedarf und langsame Abfragen in Produktionssystemen.

Für Marketing-Automation-Systeme sind folgende Metriken kardinalitätssicher und trotzdem aussagekräftig:

• E-Mail-Delivery-Rate, aggregiert nach Kampagnentyp oder Sendedomain – nicht nach einzelner Kampagnen-ID
• Automation-Trigger-Latenz nach Automation-Kategorie, nicht nach einzelner Automation-ID
• API-Response-Zeiten nach Endpunkt-Gruppe, nicht nach vollem Pfad
• Queue-Länge und Verarbeitungsrate für asynchrone Worker

Der Unterschied zwischen "Kampagnentyp" und "Kampagnen-ID" als Label klingt klein, ist aber entscheidend: Ein System mit tausend Kampagnen pro Jahr erzeugt bei falscher Wahl tausend Zeitreihen statt einer Handvoll – mit entsprechend höherem Speicher- und Abfragebedarf.

Traces: Wann Distributed Tracing den Aufwand rechtfertigt

Distributed Tracing zeigt, wie eine Anfrage durch mehrere Services läuft – mit exakten Zeitstempeln für jeden Schritt. Für einfache Monolithen ist Tracing oft überdimensioniert. Sinnvoll wird es, wenn mehr als drei Services an einer typischen Anfrage beteiligt sind, wenn Latenzprobleme auftreten, deren Ursache unklar bleibt, oder wenn externe Abhängigkeiten – E-Mail-Provider, Payment-Gateways, CRM-APIs – regelmäßig Probleme verursachen, ohne dass klar ist, auf welcher Seite der Flaschenhals liegt.

OpenTelemetry ist heute der De-facto-Standard für Tracing-Instrumentierung. Es bietet SDKs für alle gängigen Programmiersprachen, ist vendor-neutral und erlaubt es, das Backend zu wechseln – zwischen Jaeger, Grafana Tempo, Zipkin oder einem Cloud-nativen Service –, ohne die Anwendung neu zu instrumentieren. Wer heute mit OpenTelemetry instrumentiert, muss bei einem Tool-Wechsel nicht neu anfangen.

Welches Tool-Setup passt in welcher Situation?

So planst du die Migration von ELK auf Loki – Schritt für Schritt

Migrations-Projekte scheitern selten an der Technik, häufig aber daran, dass kein klares Ziel formuliert wurde. Die folgende Reihenfolge hat sich bewährt.

1. Labeling-Strategie dokumentieren – bevor der erste Log ins neue System fließt. Welche Services gibt es? Welche Umgebungen? Welche Retention-Stufen sind fachlich und rechtlich notwendig?
2. Retention-Regeln festlegen – Debug-Logs nach 7 bis 30 Tagen, Anwendungs-Logs nach 90 Tagen, Compliance-relevante Logs nach den gesetzlichen Vorgaben aufbewahren.
3. Einen Pilotservice auswählen – am besten einen Service mit mittlerem Log-Volumen, der nicht direkt geschäftskritisch ist, zum Beispiel ein Reporting-Service oder ein Batch-Worker.
4. Parallelbetrieb einrichten – für 2 bis 4 Wochen laufen altes und neues System gleichzeitig. Abfragen im neuen System gegen das alte validieren.
5. Dashboards und Alerts migrieren – LogQL unterscheidet sich von Elasticsearch Query DSL. Zeit für Team-Schulungen einplanen, bevor weitere Services folgen.
6. Service für Service migrieren – nach vollständiger Validierung des Pilots, jeweils mit Parallelbetrieb über einige Wochen.
7. Altes System abschalten – erst wenn alle Services migriert sind, das Team in LogQL routiniert arbeitet und Alerts vollständig übertragen wurden.

Typische Fehler und Grenzen der Strategie

Labeling-Strategie als Nachgedanke behandeln

Das häufigste Problem: Die Labeling-Strategie wird erst definiert, nachdem die ersten Services bereits schreiben. Rückwirkende Änderungen erzwingen entweder eine Neuingestion aller betroffenen Logs oder akzeptieren inkonsistente Strukturen im selben Stack. Beides ist aufwändig. Eine Stunde Planungsarbeit vor der Migration spart Tage an Korrekturaufwand danach.

Retention-Policies zu aggressiv oder zu lax setzen

Im DACH-Raum unterliegen Logs, die aus geschäftlichen Transaktionen entstehen und personenbezogene Daten enthalten können, denselben Anforderungen wie die Daten selbst. Wer Logs zu früh löscht, hat bei einem Compliance-Audit kein Material. Wer alles unbegrenzt speichert, schleppt unnötige Datenschutzrisiken mit sich. Wer DSGVO-konformes E-Mail-Marketing mit ActiveCampaign aufbaut, sollte dabei auch die Log-Retention-Anforderungen für Auftragsverarbeitungsnachweise berücksichtigen – die Anforderungen überschneiden sich.

Keinen Betriebsplan nach der Migration haben

Grafana Loki und Prometheus brauchen laufende Wartung: regelmäßige Updates, Kapazitätsplanung bei wachsendem Log-Volumen, Monitoring der Monitoring-Infrastruktur selbst. Teams, die nach der Migration keinen Betriebsplan haben, bauen sich denselben Schuldenposten auf, den sie mit der Migration eigentlich auflösen wollten.

Wann Loki nicht die richtige Wahl ist

Loki ist für pattern-basiertes Filtering über Labels optimiert, nicht für flexible Volltextsuche ohne Label-Kontext. Wer primär unstrukturierte Volltextsuche über lange Zeiträume benötigt – etwa für Compliance-Audits, bei denen beliebige Suchbegriffe ohne bekannte Label-Eingrenzung abgefragt werden – arbeitet mit Elasticsearch effizienter.

Wer außerdem noch kein Team hat, das Grafana-Infrastruktur betreiben kann, sollte nüchtern prüfen, ob der Wechsel Kosten senkt oder nur verschiebt: Managed Services kosten mehr pro Gigabyte, erzeugen aber keinen eigenen Operations-Aufwand. Eigenbetrieb spart Lizenzkosten, erfordert aber Operations-Kapazität, die realistisch eingeplant werden muss – sonst entsteht nur eine neue Form von technischem Schuldenaufbau.

Und schließlich: Wer gerade erst mit einem Monitoring-System beginnt, sollte nicht mit einer Migration starten. Der erste Schritt ist eine funktionierende Observability – auf welchem Stack auch immer. Optimierungen kommen, wenn der Stack läuft und das Team weiß, was es braucht.

Häufige Fragen

Ist OpenTelemetry stabil genug für den Produktionseinsatz?

Ja. OpenTelemetry hat stabile Versionen seiner Core-APIs und SDKs für die gängigsten Sprachen veröffentlicht. Die Traces-Spezifikation gilt als stabil; Metrics und Logs sind ebenfalls in stabilen Versionen verfügbar. Viele Cloud-Anbieter unterstützen OTLP nativ als Ingestion-Protokoll, sodass kein separater Collector zwingend notwendig ist. OpenTelemetry ist kein experimentelles Projekt mehr.

Wie viele Labels sollte ein Log-Entry in Loki tragen?

Grafana empfiehlt so wenige Labels wie möglich, so viele wie nötig. Als Faustregel gelten fünf bis acht Labels pro Log-Stream als gut handhabbar. Mehr als zehn Labels pro Stream signalisieren oft, dass Metadaten fälschlicherweise als Labels modelliert werden, statt als Felder in der strukturierten Log-Zeile zu stehen – ein häufiger Anfängerfehler, der erst bei wachsendem Log-Volumen als Kostenproblem sichtbar wird.

Wie lange müssen Logs nach DSGVO aufbewahrt werden?

Die DSGVO nennt keine feste Aufbewahrungsfrist für Logs. Maßgeblich ist, wie lange die zugrundeliegende Datenverarbeitung nachgewiesen werden muss. Für Auftragsverarbeitungsverträge nach Art. 28 DSGVO empfiehlt sich eine Dokumentation für die Dauer der Zusammenarbeit plus drei Jahre. Debug-Logs ohne Personenbezug unterliegen dem Grundsatz der Datensparsamkeit: so kurz wie fachlich notwendig, nicht länger.

Lohnt sich eine Migration, wenn bereits ein ELK-Stack betrieben wird?

Das hängt vom Log-Volumen und vom Team-Know-how ab. Unterhalb einiger Dutzend Gigabyte pro Monat ist der Migrationsaufwand selten durch Einsparungen gedeckt. Oberhalb dieser Schwelle – insbesondere wenn das Volumen weiter wächst – kann eine Migration langfristig erheblich günstiger ausfallen. Entscheidend ist, ob dein Team LogQL erlernen kann und wer den neuen Stack im Regelbetrieb verantwortet.

Was unterscheidet Observability von klassischem Monitoring?

Monitoring prüft, ob bekannte Bedingungen erfüllt sind: Uptime über einem Schwellenwert, Fehlerrate unter einem bestimmten Prozentsatz. Observability erlaubt es, unbekannte Fragen über das Systemverhalten zu stellen, ohne vorab definiert zu haben, was du suchen willst. Das erfordert mehr Daten – und genau deshalb ist Kostenmanagement ein zentraler Bestandteil jeder Observability-Strategie.

Eine Observability-Strategie zahlt sich nicht am ersten Tag aus. Der erste konkrete Schritt – Labeling-Strategie festlegen und einen Pilotservice in den neuen Stack einbinden – dauert oft weniger als eine Woche. Wer dort sauber arbeitet, legt ein Fundament, das mit dem System mitwächst, ohne die Kosten proportional mitzuziehen. Für Teams, die dabei auch die Zustellbarkeit ihrer E-Mail-Kampagnen im Blick behalten wollen, zeigt dieser Beitrag zur E-Mail-Zustellbarkeit, welche Parameter im Marketing-System besonders relevant sind.