Obseria vs. Elastic Observability

Funktionsvergleich

Obseria als Elastic Alternative: die Kurzfassung

Elastic Observability ist aus dem ELK-Stack hervorgegangen und gehört bis heute zu den am weitesten verbreiteten Grundlagen für Log-Analyse. Inzwischen deckt die Lösung Logs, Metriken, APM, Synthetic Monitoring, Real User Monitoring und KI-gestützte Analysen auf Basis von Elasticsearch ab. Obseria adressiert dieselben Kernbereiche mit einer OpenTelemetry-nativen Plattform rund um ein indexfreies Lakehouse. Wenn Sie eine Elastic Alternative prüfen, entscheiden meist vier Fragen: Wie möchten Sie bezahlen, wie viel vom Stack wollen Sie selbst betreiben, wie werden Daten gespeichert und abgefragt, und wo müssen sie liegen? Dieser Artikel vergleicht beide Plattformen anhand dieser Punkte, gestützt auf die öffentlichen Preisseiten und die Dokumentation von Elastic, Stand Oktober 2026.

Preismodell: pro GB oder pro Signal

Elastic bietet drei Bereitstellungsvarianten mit unterschiedlichen kommerziellen Modellen. Elastic Cloud Serverless ist nutzungsbasiert: Laut Preisseite zahlen Sie pro ingestiertem GB und pro aufbewahrtem GB und Monat, dazu Egress oberhalb eines Freikontingents. Observability Serverless gibt es in zwei Stufen. Logs Essentials umfasst Log-Analyse, Dashboards, Integrationen und Alerts; Complete ergänzt SLOs, Machine Learning, KI-gestütztes Parsing, agentische KI, Workflow-Automatisierung und private Konnektivität. Synthetische Browser-Tests, das Elastic Managed LLM, Cross-Project Search und Workflow-Ausführungen werden als Add-ons abgerechnet. Elastic Cloud Hosted wird nach den Ressourcen des Deployments berechnet, selbst betriebene Subscriptions nach Knoten und RAM. Der Support-Umfang hängt von der Subscription-Stufe ab.

Das Serverless-Modell ist transparent und passt gut zu Teams, die in GB Log-Volumen denken. Hosted und Self-Managed belohnen Teams, die Cluster gut dimensionieren können, denn die Kosten folgen der bereitgestellten Hardware und nicht den tatsächlich abgefragten Daten.

Obseria rechnet pro Signal statt pro GB ab und erhebt keine Gebühren für Hosts oder Nutzer:

• Logs, Spans und RUM-Web-Events: 0,060 $ pro Million ingestiert und 0,540 $ pro Million gespeichert, bei 30 Tagen Aufbewahrung.
• Metrik-Datenpunkte: 0,020 $ pro Million ingestiert und 0,180 $ pro Million gespeichert, bei 13 Monaten Aufbewahrung.
• Synthetische API-Checks: 0,20 $ pro Tausend Ausführungen; Agent Credits für Obseria Intelligence: 0,60 $ pro Credit.
• In Obseria Pipeline gefilterte Daten kosten nur die Ingestion. Dashboards, Alerting, SLOs, Automatisierung, API, CLI, MCP-Server und SSO/RBAC sind für unbegrenzt viele Nutzer enthalten.

Da ein Modell Gigabytes und das andere Events zählt, braucht ein fairer Vergleich Ihre eigenen Zahlen: durchschnittliche Größe eines Log-Eintrags, Span-Volumen und Metrik-Kardinalität. Große, ausführliche Log-Zeilen sprechen eher für eine Abrechnung pro Event, viele sehr kleine Einträge eher für eine Abrechnung pro GB.

Datenmodell, Speicherung und Abfragen

Elastic speichert Telemetrie in Elasticsearch-Indizes, organisiert als Data Streams. Index Lifecycle Management verschiebt Daten durch Hot-, Warm-, Cold- und Frozen-Tiers, ergänzt um Searchable Snapshots auf Object Storage. Mappings, Ingest Pipelines und das neuere Feature Streams steuern, wie Rohdaten geparst werden. Diese Architektur ist für Volltextsuche äußerst leistungsfähig und gibt erfahrenen Teams feine Kontrolle über Performance und Kosten. Sie bedeutet aber auch, dass jemand Mappings, Shard-Größen und Lifecycle-Policies verantwortet, es sei denn, Sie nutzen Serverless, wo Elastic den Großteil davon übernimmt.

Für Abfragen bietet Elastic ES|QL, eine Pipe-basierte Abfragesprache, sowie KQL und die Query DSL. ES|QL hat die Ad-hoc-Analyse von Logs in Kibana deutlich zugänglicher gemacht.

Obseria Lake ist ein indexfreies Lakehouse mit Schema-on-Read. Logs, Metriken, Spans, Profile, RUM-Events und Security-Signale landen in einem Speicher im Petabyte-Maßstab; Felder werden erst zur Abfragezeit interpretiert, sodass keine Mappings oder Shards zu planen sind. Feldbasierte Datenschutzregeln steuern, wer welche Attribute sieht. Obseria Pipeline filtert, reichert an, maskiert PII und routet Daten bereits beim Ingest. Abfragen laufen in OQL über alle Signale hinweg, ergänzt um PromQL und SQL:

fetch logs
| filter service == "payments"
| summarize count(), by:{level}

OpenTelemetry und Portabilität

Elastic setzt inzwischen klar auf OpenTelemetry. Die Dokumentation beschreibt produktionsreife OTel-Unterstützung über die Elastic Distribution of OpenTelemetry (EDOT) mit eigenem Collector und Sprach-SDKs, und Elastic trägt aktiv zum Upstream-Projekt bei. Die eigenen APM-Agenten sowie Elastic Agent mit Fleet stehen weiterhin zur Verfügung.

Obseria ist OpenTelemetry-nativ: OTLP ist das primäre Ingest-Protokoll, die Semantic Conventions bilden das Datenmodell, und Sie können Ihre Daten jederzeit per OTLP exportieren. Mit vorhandenen OTel SDKs sehen Teams in der Regel innerhalb von 15 Minuten den ersten Trace. Der Obseria Agent wird einmal pro Host installiert und erfasst Metriken, Logs, Traces, Profile und Security-Signale; Obseria TopoGraph bildet Anwendungen und Infrastruktur automatisch ab.

In der Praxis akzeptieren beide Plattformen Standard-OTLP. Sind Ihre Services mit Upstream- oder EDOT-SDKs instrumentiert, beschränkt sich ein Wechsel des Backends weitgehend auf neue Exporter-Endpunkte. Echte Migrationsarbeit steckt in Dashboards, Alerts und gespeicherten Abfragen.

KI und Ursachenanalyse

Elastic kombiniert bewährte Machine-Learning-Jobs zur Anomalieerkennung mit dem Elastic AI Assistant, der Retrieval-Augmented Generation über Telemetrie und internes Wissen nutzt. In Serverless sind ML, KI-gestütztes Parsing und agentische KI Teil der Stufe Complete; das Elastic Managed LLM wird pro Token abgerechnet.

Obseria Intelligence verbindet kausale, prädiktive und generative KI. Agentische Ursachenanalysen durchlaufen den TopoGraph und die Daten in Obseria Lake und liefern eine Beweiskette, die Ihr Team Schritt für Schritt nachvollziehen kann. Ein Agent Credit kostet 0,60 $, und Kundendaten werden niemals zum Training von KI-Modellen verwendet.

Bereitstellung, Datenresidenz und Compliance

Hier liegt eine echte Stärke von Elastic: Sie können die Lösung selbst betreiben, on-premises oder in jeder Cloud, oder Elastic Cloud auf AWS, Google Cloud und Azure in zahlreichen Regionen nutzen, darunter europäische. Für Organisationen, die alles im eigenen Rechenzentrum halten müssen, ist selbst betriebenes Elastic eine bewährte Option.

Obseria speichert Daten in der EU (Frankfurt, Dublin), im Vereinigten Königreich (London) oder in Ihrem eigenen Cloud-Konto (BYOC). Obseria ist nach ISO 27001, 27017 und 27018, SOC 2 Type II, BSI C5 für die EU-Region und TISAX zertifiziert und unterstützt DORA, NIS2 und DSGVO mit automatischer PII-Maskierung, feldbasierten Zugriffsrechten, Audit-Logs und 99,95 % SLA. Eine On-Premises-Installation bietet Obseria nicht an.

Migration von Elastic zu Obseria

1. Parallel per OpenTelemetry senden: Ergänzen Sie Ihren EDOT- oder Upstream-Collector um einen OTLP-Exporter und schicken Sie während der Evaluierung dieselben Daten an beide Plattformen.
2. Gespeicherte Suchen und Dashboards übertragen: Beginnen Sie mit den Ansichten, die Ihre Bereitschaft täglich nutzt; ES|QL-Pipelines lassen sich gut in OQL-Pipes übersetzen.
3. Shipper schrittweise ablösen: Ersetzen Sie Beats- oder Elastic-Agent-Inputs Service für Service durch den Obseria Agent oder Collector-Receiver.

Die 14-tägige Testphase erfordert keine Kreditkarte und reicht meist aus, um Kosten und Abfrageverhalten an einem repräsentativen Workload zu vergleichen.

Welches Tool passt zu Ihnen?

Der Wechsel in drei Schritten

1. Telemetrie parallel senden. Richten Sie Ihren EDOT- oder OpenTelemetry-Collector auf beide Backends aus und vergleichen Sie Daten, Kosten und Abfrageergebnisse.
2. Zentrale Ansichten nachbauen. Bauen Sie gespeicherte Suchen, Dashboards und Alerts, auf die Ihre Bereitschaft angewiesen ist, in OQL, PromQL oder SQL nach.
3. Datenerfassung umstellen. Ersetzen Sie Beats- und Elastic-Agent-Inputs durch den Obseria Agent oder Collector-Receiver und legen Sie den alten Cluster still.