Ingenieure verabschieden sich leise von ELK - und bauen ihre eigenen Observability-Stacks
"Ingenieure verabschieden sich leise 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 eine Frage.
Wie verwaltet man Logs?
Elasticsearch übernahm die Indizierung. Logstash verarbeitete eingehende Daten. Kibana visualisierte alles in Dashboards. Zusammen bildeten sie eine der am weitesten verbreiteten Observability-Plattformen in moderner Infrastruktur.
Aber etwas hat sich verändert.
In Engineering-Teams überall passiert eine leise Verschiebung. Entwickler experimentieren mit alternativen Stacks rund um OpenTelemetry, OpenSearch und spezialisierte Tracing-Systeme. Das Ziel ist nicht nur, ELK zu ersetzen – es geht darum, Observability-Pipelines zu bauen, die besser skalieren und weniger kosten.
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 Gespräch an Aufmerksamkeit gewinnt.
Weil Observability-Kosten zu einem ernsten Problem werden.
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 ausgelegt.
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. Observability-Pipelines müssen plötzlich gewaltige Mengen an Telemetrie aufnehmen.
In solchen Umgebungen werden ELK-Deployments oft teuer und operativ schwerfällig.
Elasticsearch-Cluster wachsen groß. Logstash-Pipelines werden kompliziert. Die Storage-Kosten steigen, während die Telemetrie-Volumen wachsen.
Viele Ingenieure kommen irgendwann zum selben Schluss.
ELK funktioniert.
Aber es zu pflegen kann zu einem Vollzeit-Infrastrukturprojekt werden.
Deshalb begannen Teams, mit anderen Architekturen zu experimentieren.
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.
Jaeger für verteiltes Tracing.
OpenTelemetry fungiert als zentrale Telemetrie-Pipeline. Anwendungen senden Metriken, Logs und Traces durch den OpenTelemetry-Collector. Von dort leitet der Collector die Daten an Storage-Systeme wie OpenSearch weiter.
Tracing-Daten fließen in Jaeger, das sich darauf spezialisiert hat, Request-Pfade über verteilte Systeme hinweg zu visualisieren.
Dieser Ansatz verändert, wie Observability-Pipelines funktionieren.
Statt sich auf Logstash als Verarbeitungsschicht zu verlassen, übernehmen OpenTelemetry-Collectors Aufnahme und Routing direkt.
Und das vereinfacht die Architektur erheblich.
Warum OpenTelemetry alles verändert hat
OpenTelemetry ist einer der Hauptgründe, warum neue Observability-Stacks anders aussehen als ältere.
Statt separater Logging-Agenten, Metrik-Collectors und Tracing-Bibliotheken bietet OpenTelemetry ein einheitliches Instrumentierungs-Framework.
Anwendungen senden Telemetrie in einem konsistenten Format.
Collectors verarbeiten diese Telemetrie und leiten sie an verschiedene Backends weiter.
In der Praxis bedeutet das, dass ein System mehrere Observability-Signale verarbeiten kann.
Logs.
Metriken.
Traces.
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, maßgeschneiderte 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.
Aber die Beziehung zwischen den beiden Technologien ist kompliziert geworden.
Manche Ingenieure argumentieren, dass OpenSearch bei Observability-Workloads extrem gut performt, selbst bei der Verarbeitung gewaltiger 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 nicht automatisch beweist, dass OpenSearch überlegen ist.
Die Performance hängt stark von Cluster-Konfiguration, Query-Mustern und Indizierungsstrategien ab.
Mit anderen Worten: Die Debatte ist nicht entschieden.
Und genau deshalb experimentieren Ingenieure weiterhin mit unterschiedlichen Stacks.
Das versteckte Kostenproblem
Ein Grund, warum Teams Alternativen zu ELK erkunden, hat weniger mit Performance zu tun als mit Wirtschaftlichkeit.
Observability-Daten wachsen schnell.
Jeder Request, jeder Log-Eintrag und jeder Trace erzeugt Telemetrie. Wenn Systeme skalieren, können die Storage-Kosten explodieren.
Manche Ingenieure sagen, es sei ihnen gelungen, gewaltige Telemetrie-Volumen mit OpenSearch zu relativ niedrigen Kosten aufzunehmen – besonders beim Betrieb selbstverwalteter Cluster statt verwalteter Cloud-Angebote.
Aber es gibt einen wichtigen Vorbehalt.
Derselbe Ingenieur, der OpenSearch lobte, warnte auch davor, AWS' verwalteten OpenSearch-Service zu nutzen, und beschrieb ihn als extrem teuer.
Diese Warnung verdeutlicht einen breiteren Trend.
Der Unterschied zwischen selbstverwalteten Observability-Stacks und Managed Services kann die Kosten drastisch beeinflussen.
Die anderen Tools, die in diesen Stacks auftauchen
Observability-Stacks bleiben selten einfach.
Während Teams mit Alternativen experimentieren, kommen oft neue Tools in die Pipeline.
Ein Ingenieur erwähnte den Einsatz von Vector, einem leichtgewichtigen, in Rust geschriebenen Log-Verarbeitungssystem, als Ersatz für Tools wie Filebeat oder Logstash. In seinem Setup übernahm Vector die Log-Normalisierung für rund 250 Anwendungen, blieb dabei aber schnell und ressourcenschonend.
Andere erwähnten Tracing-Systeme rund um VictoriaMetrics oder unterschiedliche Telemetrie-Storage-Backends.
Dieses Experimentieren zeigt, wie schnell sich das Observability-Ökosystem weiterentwickelt.
Teams sind nicht mehr an monolithische Stacks gebunden.
Sie stellen Pipelines aus spezialisierten Komponenten zusammen.
Der Gegenwind aus der Community
Immer wenn jemand vorschlägt, etablierte Observability-Tools zu ersetzen, kommt schnell Kritik auf.
Im Fall des alternativen OpenSearch-Stacks stellten manche Ingenieure die Behauptungen des Artikels infrage. Kritiker argumentierten, dass Elastic weiterhin einer der größten Contributor im OpenTelemetry-Ökosystem sei und eine starke native Integration mit OTLP-Telemetrie-Pipelines biete.
Andere wiesen darauf hin, dass unabhängige Benchmarks bei bestimmten Workloads oft zeigen, dass Elasticsearch besser abschneidet als OpenSearch.
Diese Meinungsverschiedenheiten verdeutlichen eine wichtige Realität.
Observability ist kein gelöstes Problem.
Es gibt mehrere Wege, Telemetrie-Pipelines zu bauen, und jeder Ansatz hat Kompromisse.
Die eigentliche Verschiebung, die stattfindet
Trotz der Debatten über einzelne Tools passiert in Engineering-Teams 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 Telemetrie-Signale weiter.
Unterschiedliche Storage-Engines verarbeiten Logs, Metriken und Traces.
Diese Architektur gibt Teams mehr Kontrolle über Kosten und Skalierbarkeit.
Aber sie erfordert auch tiefere Expertise.
Denn sobald Sie monolithische Stacks aufgeben, sind Sie 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 sehr anders aussehen werden als die Stacks der Vergangenheit.
Instrumentierungsstandards trennen die Telemetrieerfassung von den Storage-Systemen.
Logs, Metriken und Traces werden zu portablen Signalen statt zu herstellerspezifischen Datenformaten.
Und Infrastruktur-Teams experimentieren mit Kombinationen von Tools, statt sich auf ein einziges Ökosystem festzulegen.
Diese Verschiebung könnte irgendwann den gesamten Observability-Markt neu gestalten.
Denn sobald Telemetrie-Pipelines modular werden …
Die Frage lautet nicht mehr: "Welche Observability-Plattform sollten wir nutzen?"
Sondern wird zu etwas viel Interessanterem.
"Wie entwerfen wir die Pipeline selbst?"