Elastic vs. OTel Collector

Vor fünf Jahren waren das zwei Lager. Elastic hatte Beats, dann Elastic Agent und Fleet, mit einem Schema (ECS) und einer Verwaltungskonsole, gebaut für ein Ziel. Der OpenTelemetry Collector war die neutrale Alternative. Man wählte eine Seite.

Diese Rahmung ist überholt, und präzise zu sein, warum, ist der grösste Teil der Entscheidung. Elastic hat ECS in die Semantic Conventions von OpenTelemetry eingebracht, liefert eine eigene Distribution des OpenTelemetry Collectors und der SDKs (EDOT) und nimmt OTLP nativ als Ingest-Pfad an. Elastic Observability, das Backend, ist mit beidem zufrieden. Die Wahl, die bleibt — und sie ist real —, betrifft die Erfassungsschicht: Elastic Agent, verwaltet durch Fleet, oder der OpenTelemetry Collector, verwaltet durch eine Control Plane. Sie unterscheiden sich darin, worin sie gut sind, und der Unterschied ist strukturell, kein Feature-Rennen.

Lautet Ihre Frage „wie komme ich weg von Elastic Agent hin zu Collectors”, ist das eine Migration, und die steht Schritt für Schritt in Elastic Agent zu OpenTelemetry migrieren. Dieser Beitrag ist der Vergleich, den Sie lesen, bevor Sie entscheiden, ob Sie das wollen.

Worauf jedes tatsächlich optimiert ist

Elastic Agent + Fleet ist darauf optimiert, eine bekannte Quelle schnell und in der richtigen Form nach Elastic zu bringen. Die Integrationen sind der Aktivposten: „nginx”, „Windows Event Log” oder „AWS CloudTrail” in Kibana auswählen, und Sie bekommen die Collector-Config, das ECS-Feld-Mapping, die Ingest-Pipeline, die Dashboards und oft die Alert-Regeln — als eine installierbare Einheit, zentral von Fleet verwaltet, als Paket versioniert. Das ist ein wirklich reifer Katalog, und nichts in der OpenTelemetry-Welt erreicht seine Breite an fertigen Integrationen.

Der OpenTelemetry Collector ist darauf optimiert, die Verarbeitungsschicht zu besitzen und an kein Ziel gebunden zu sein. Receiver gibt es für die meisten derselben Quellen, aber die Pipeline setzen Sie zusammen: was parsen, was maskieren, was samplen, wohin senden. Der Wert ist, dass diese Zusammensetzung Ihnen gehört, portabel ist und an mehrere Backends auffächern kann. Der Preis ist, dass Sie die Zusammensetzung auch selbst machen.

Das ist der ganze Vergleich in zwei Sätzen. Alles Weitere ist Folge.

Wo sie sich wirklich unterscheiden

• Schema. Elastic Agent emittiert ECS, das Kibana vollständig versteht. Der Collector emittiert OpenTelemetry Semantic Conventions — in die ECS inzwischen hineinkonvergiert, die aber heute nicht identisch sind; ein auf ECS-Feldern gebautes Kibana-Dashboard kann ein Mapping brauchen, wenn es OTel-förmige Daten erhält. Diese Lücke schliesst sich; sie ist nicht geschlossen.
• Verwaltung. Fleet verwaltet Elastic Agents — Enrolment, Policy, Upgrades — aus Kibana heraus, und nur Elastic Agents. Der Collector spricht OpAMP, das ein Protokoll ist und kein Produkt: Den Management-Server betreiben oder kaufen Sie. Fleet ist fertig und hat einen Zweck; OpAMP ist offen und braucht eine Control Plane darüber — OpAMP erklärt.
• Verarbeitung vor dem Egress. Elastics Modell erledigt den Grossteil der Transformation in Ingest-Pipelines auf der Elastic-Seite, nachdem die Daten ankommen. Der Collector tut es im Agenten oder einem Gateway, vor dem Egress. Für die Kosten ist das der Unterschied zwischen „für die Aufnahme zahlen und dann verwerfen” und „verwerfen und dann für die Aufnahme zahlen” — Observability-Kosten beginnen am Rand. Für die Compliance ist es der Unterschied zwischen Maskieren auf dem Host und Maskieren im Cluster.
• Mehrere Backends. Elastic Agent sendet an Elastic. Über Logstash lässt er sich anderswohin überreden, aber die Entwurfsannahme ist ein Ziel. Der Collector fächert per Design auf — Eine Strategie, mehrere Backends. Ist Elastic Ihr einziges Backend, spielt das keine Rolle; ist es eines von dreien, ist es der entscheidende Faktor.
• Lock-in. Ein Bestand, der mit Elastic-APM-Agents instrumentiert und mit Elastic Agent erfasst wird, ist ein guter Bestand — bis zur Verlängerung. Der OTel-Pfad hält Instrumentierung und Erfassung als offene Standards, mit Elastic als austauschbarem Konsumenten. Elastics eigene EDOT-Arbeit ist das Eingeständnis, dass Kunden das inzwischen verlangen.

Was EDOT ändert

Die Elastic Distribution of OpenTelemetry ist Elastics kuratierter Build des Collectors plus SDKs, abgestimmt und supportet für das Senden an Elastic. Sie ist ein echtes Produkt, kein Marketing, und sie verändert das Bild in einer bestimmten Hinsicht: Sie können das OpenTelemetry-Modell übernehmen — Collector, OTLP, Semantic Conventions — und Elastic als Backend behalten, mit einem Anbieter, der für den Support in der Pflicht steht.

Was sie nicht ändert: EDOTs Collector ist weiterhin ein Collector. Er braucht dieselbe Flottendisziplin — Config als Policy, Drift-Erkennung, health-gated Rollouts — wie jeder andere, und Fleet verwaltet ihn nicht. Wählen Sie EDOT, haben Sie die OTel-Seite dieses Vergleichs gewählt, mit einem Elastic-gefärbten Binary und dem Betriebsmodell, das dazugehört.

Wann was wählen

Wenn Sie…	Tendenz
Elastic als einziges Backend betreiben und fertige Integrationen höher gewichten als Flexibilität	Elastic Agent + Fleet
Vor allem bekannte Quellen verschicken (Windows, nginx, Cloud-Audit-Logs) und Dashboards am ersten Tag wollen	Elastic Agent + Fleet
Zwei oder mehr Backends betreiben — oder das erwarten	OpenTelemetry Collector
Maskierung und Volumenreduktion brauchen, bevor Daten den Host verlassen	OpenTelemetry Collector
Anwendungsteams haben, die bereits OTel-SDKs nutzen	OpenTelemetry Collector (oder EDOT)
Das OTel-Modell mit Supportvertrag und Elastic als Ziel wollen	EDOT Collector
Einen gemischten Bestand haben — Elastic Agents auf manchen Hosts, Collectors auf anderen	Beides, von einer Stelle verwaltet

Diese letzte Zeile ist die häufige Antwort der realen Welt, und sie ist nur erträglich, wenn eine Control Plane beides sieht — sonst sind es zwei Konsolen, zwei Drift-Flächen und zwei Antworten auf „was läuft auf diesem Host”.

Die ehrliche Zusammenfassung

Elastic Agent ist das bessere Produkt: mehr Integrationen, mehr fertige Inhalte, eine Konsole. Der OpenTelemetry Collector ist die bessere Schicht: portabel, Verarbeitung vor dem Egress, backend-neutral — und das, wovon inzwischen jeder Anbieter, Elastic eingeschlossen, eine Distribution ausliefert. Wählen Sie das Produkt, wenn Elastic das ganze Bild ist. Wählen Sie die Schicht, wenn es ein Teil davon ist. Und lassen Sie die Wahl nicht standardmässig davon getroffen werden, welcher Agent zufällig zuerst installiert war.