Ingenieure verabschieden sich von ELK und bauen ihre eigenen Observability-Stacks
Der Stack, der ein Jahrzehnt lang die Logs dominierte
Jahrelang war der ELK-Stack die Standardantwort auf die Frage, wie man Logs verwaltet. Elasticsearch übernahm die Indizierung, Logstash verarbeitete eingehende Daten, und Kibana visualisierte alles in Dashboards. Zusammen bildeten sie eine der am weitesten verbreiteten Observability-Plattformen moderner Infrastruktur.
Inzwischen hat sich etwas verändert. In Engineering-Teams überall verschiebt sich die Praxis: Entwickler experimentieren mit alternativen Stacks rund um OpenTelemetry, OpenSearch und spezialisierte Tracing-Systeme. Dabei geht es um Observability-Pipelines, die besser skalieren und weniger kosten, und nicht nur darum, ELK loszuwerden.
Ein Ingenieur beschrieb, wie er ein solches System in Produktion betreibt und dabei fast eine Milliarde Logs und Spans pro Tag aufnimmt, während die gesamten Infrastrukturkosten überraschend niedrig geblieben seien. Allein diese Behauptung erklärt, warum das Thema Aufmerksamkeit bekommt, denn Observability-Kosten werden für viele zu einem ernsten Problem.
Warum ELK für viele Teams zum Problem wurde
Der ursprüngliche ELK-Stack war leistungsstark, aber nicht für den Maßstab moderner verteilter Systeme gebaut. Microservices haben alles verändert. Statt einer Handvoll Anwendungen, die Logs erzeugen, betreiben Unternehmen heute Hunderte Services, die gleichzeitig Logs, Traces, Metriken und Events produzieren, und die Pipelines müssen plötzlich gewaltige Mengen an Telemetrie schlucken.
In solchen Umgebungen werden ELK-Deployments oft teuer und operativ schwerfällig. Elasticsearch-Cluster wachsen, Logstash-Pipelines werden kompliziert, und mit dem Telemetrie-Volumen steigen die Storage-Kosten.
Viele Ingenieure kommen irgendwann zum gleichen Schluss. ELK funktioniert, aber es zu pflegen kann zu einem Vollzeit-Infrastrukturprojekt werden. Also fingen Teams an, andere Architekturen auszuprobieren.
Der alternative Stack, der immer wieder auftaucht
Eine zunehmend beliebte Ersatzarchitektur kombiniert drei Kernkomponenten: OpenTelemetry für die Telemetrieerfassung, OpenSearch für Storage und Indizierung und Jaeger für verteiltes Tracing.
OpenTelemetry dient dabei als zentrale Telemetrie-Pipeline. Anwendungen schicken Metriken, Logs und Traces durch den OpenTelemetry-Collector, der die Daten an Storage-Systeme wie OpenSearch weiterleitet. Tracing-Daten landen in Jaeger, das darauf spezialisiert ist, Request-Pfade über verteilte Systeme hinweg sichtbar zu machen.
Damit ändert sich die Funktionsweise der Pipeline. Anstelle von Logstash als Verarbeitungsschicht übernehmen OpenTelemetry-Collectors Aufnahme und Routing direkt, und die Architektur wird deutlich einfacher.
Warum OpenTelemetry alles verändert hat
OpenTelemetry ist einer der Hauptgründe, warum neue Observability-Stacks anders aussehen als die alten. Statt separater Logging-Agenten, Metrik-Collectors und Tracing-Bibliotheken gibt es ein einheitliches Instrumentierungs-Framework.
Anwendungen senden Telemetrie in einem konsistenten Format, und Collectors verarbeiten sie und leiten sie an verschiedene Backends weiter. Praktisch heißt das, dass ein System Logs, Metriken und Traces gemeinsam verarbeiten kann.
Ein Ingenieur wies darauf hin, dass OpenTelemetry-Collectors leichtgewichtig genug sind, um im Agent-Modus zu laufen und Logs sowie Telemetrie dorthin weiterzuleiten, wo sie hin müssen. Diese Flexibilität macht es einfacher, eigene Observability-Pipelines zu entwerfen, ohne auf schwergewichtige Ingestion-Tools angewiesen zu sein.
Die OpenSearch-Debatte
OpenSearch taucht in diesen alternativen Stacks oft auf, weil es eine Open-Source-Suchmaschine ähnlich wie Elasticsearch bietet. Das Verhältnis der beiden Technologien ist allerdings kompliziert geworden.
Manche Ingenieure berichten, OpenSearch performe bei Observability-Workloads ausgezeichnet, auch bei gewaltigen Telemetrie-Volumen. Andere beharren darauf, dass Elasticsearch laut unabhängigen Benchmarks weiterhin schneller und leistungsfähiger sei.
Kritiker weisen häufig darauf hin, dass die bloße Verarbeitung von Milliarden Spans noch nicht beweist, dass OpenSearch überlegen ist. Die Performance hängt stark von Cluster-Konfiguration, Query-Mustern und Indizierungsstrategien ab. Die Debatte ist also offen, und genau deshalb probieren Ingenieure weiter unterschiedliche Stacks aus.
Das versteckte Kostenproblem
Dass Teams Alternativen zu ELK erkunden, hat oft weniger mit Performance zu tun als mit Wirtschaftlichkeit. Observability-Daten wachsen schnell. Jeder Request, jeder Log-Eintrag und jeder Trace erzeugt Telemetrie, und mit der Skalierung der Systeme können die Storage-Kosten explodieren.
Manche Ingenieure sagen, sie hätten gewaltige Telemetrie-Volumen mit OpenSearch zu relativ niedrigen Kosten aufnehmen können, besonders mit selbstverwalteten Clustern statt verwalteter Cloud-Angebote.
Dazu gehört allerdings ein wichtiger Vorbehalt. Derselbe Ingenieur, der OpenSearch lobte, warnte davor, den verwalteten OpenSearch-Service von AWS zu nutzen, und nannte ihn extrem teuer. Das zeigt einen breiteren Trend: Ob ein Observability-Stack selbstverwaltet oder als Managed Service läuft, kann die Kosten drastisch verschieben.
Die anderen Tools, die in diesen Stacks auftauchen
Observability-Stacks bleiben selten einfach. Wenn Teams mit Alternativen experimentieren, kommen oft neue Tools in die Pipeline.
Ein Ingenieur erwähnte Vector, ein leichtgewichtiges, in Rust geschriebenes Log-Verarbeitungssystem, als Ersatz für Tools wie Filebeat oder Logstash. In seinem Setup normalisierte Vector die Logs von rund 250 Anwendungen und blieb dabei schnell und ressourcenschonend.
Andere nannten Tracing-Systeme rund um VictoriaMetrics oder andere Storage-Backends für Telemetrie. Dieses Experimentieren zeigt, wie schnell sich das Observability-Ökosystem entwickelt. Teams sind nicht mehr an monolithische Stacks gebunden, sie setzen Pipelines aus spezialisierten Komponenten zusammen.
Der Gegenwind aus der Community
Sobald jemand vorschlägt, etablierte Observability-Tools zu ersetzen, folgt die Kritik. Beim alternativen OpenSearch-Stack stellten manche Ingenieure die Behauptungen des Artikels infrage. Sie argumentierten, Elastic sei weiterhin einer der größten Contributor im OpenTelemetry-Ökosystem und biete eine starke native Integration mit OTLP-Telemetrie-Pipelines.
Andere wiesen darauf hin, dass unabhängige Benchmarks bei bestimmten Workloads oft Elasticsearch vor OpenSearch sehen.
Diese Meinungsverschiedenheiten zeigen vor allem eines: Observability ist kein gelöstes Problem. Es gibt mehrere Wege, Telemetrie-Pipelines zu bauen, und jeder Ansatz hat seine Kompromisse.
Die eigentliche Verschiebung, die stattfindet
Hinter den Debatten über einzelne Tools passiert etwas Größeres. Observability wird modular. Statt eine einzelne monolithische Plattform zu deployen, bauen Teams Pipelines aus spezialisierten Komponenten: OpenTelemetry übernimmt die Instrumentierung, Collectors leiten die Telemetrie-Signale weiter, und unterschiedliche Storage-Engines verarbeiten Logs, Metriken und Traces.
Diese Architektur gibt Teams mehr Kontrolle über Kosten und Skalierbarkeit, verlangt aber auch tiefere Expertise. Wer monolithische Stacks aufgibt, ist selbst dafür verantwortlich, die Pipeline zu entwerfen.
Die Zukunft der Observability-Stacks
Der Aufstieg von OpenTelemetry deutet darauf hin, dass künftige Observability-Plattformen anders aussehen werden als die Stacks der Vergangenheit. Instrumentierungsstandards trennen die Telemetrieerfassung von den Storage-Systemen, und Logs, Metriken und Traces werden zu portablen Signalen statt zu herstellerspezifischen Datenformaten.
Infrastruktur-Teams kombinieren dabei Tools, statt sich auf ein einziges Ökosystem festzulegen. Diese Verschiebung könnte irgendwann den gesamten Observability-Markt umbauen, denn sobald Telemetrie-Pipelines modular sind, lautet die Frage nicht mehr: "Welche Observability-Plattform sollten wir nutzen?" Sie wird zu etwas viel Interessanterem: "Wie entwerfen wir die Pipeline selbst?"