Elastic Agent → OpenTelemetry

Der Elastic Stack ist eine leistungsfähige, weit verbreitete Observability- und Logging-Plattform, und für viele Teams hat er sich seinen Platz verdient. Zwei Dinge treiben Teams dazu, sich speziell die Collection-Ebene anzusehen: die Kosten, die mit Ingestion und Speicherung skalieren, während das Datenvolumen wächst, und der Agent-Bestand – eine Flotte von Beats und Fleet-verwalteten Elastic Agents, die Elastics Protokoll sprechen und grösstenteils Elasticsearch und nichts anderes füttern.

Die gute Nachricht ist, dass die Modernisierung der Collection nicht länger ein Rip-and-Replace bedeutet. Mit OpenTelemetry können Sie eine herstellerneutrale Collection-Ebene unter Ihre bestehende Pipeline legen, Elasticsearch und Kibana als eines von mehreren Zielen weiterlaufen lassen und das Volumen kürzen, für dessen Indexierung Sie zahlen – alles, bevor Sie sich auf irgendetwas festlegen. Elastic selbst liefert inzwischen einen eigenen Collector-Build unter dem Dach der Elastic Distributions of OpenTelemetry (EDOT), und Elasticsearch hat einen OTLP-fähigen Ingest-Pfad, dies ist also eine unterstützte Richtung, kein Hack. Die umfassendere Argumentation finden Sie in Vendor-Lock-in mit OpenTelemetry reduzieren; dieser Beitrag ist das Elastic-spezifische Playbook.

Zuerst: welches „Elastic” migrieren wir?

„Elastic zu OpenTelemetry” ist mehrdeutig, und vorab konkret zu werden erspart Ihnen einen Scoping-Fehler. Dieser Leitfaden befasst sich mit der Collection-Ebene – den Agents, die Daten in Elasticsearch bringen. Wissen Sie, welche Komponenten Sie tatsächlich betreiben:

• Beats – die Einzweck-Shipper: Filebeat (Logs), Metricbeat (Metriken), Packetbeat, Auditbeat, Winlogbeat, Heartbeat. Das ist das Grösste, was OTel ersetzt.
• Elastic Agent – der vereinheitlichte Agent, der die Beats hinter einem Binary und einer Policy bündelt und separate Beats-Installationen ersetzt.
• Fleet – die Kibana-basierte Control Plane, die Elastic Agents zentral verwaltet (Policies, Enrollment, Upgrades). Ihre Rolle bildet sich auf eine OpAMP-Control-Plane ab.
• Ingest Pipelines – Elasticsearch-seitige Processors (grok, dissect, enrich). Ein Teil dieses Parsings verlagert sich zu Collector-Processors; ein Teil bleibt indexseitig.
• EDOT Collector – Elastics eigener unterstützter OTel-Collector-Build, Teil der Elastic-Distributions-of-OpenTelemetry-(EDOT-)Familie neben den EDOT-SDKs. Wenn Sie ihn bereits betreiben, sind Sie teilweise schon auf OTel; die Processor- und Routing-Arbeit dieses Leitfadens gilt weiterhin, Sie wählen nur den Exporter.

Eine Abgrenzung: Dies zielt auf selbstverwaltete oder Elastic Cloud Ingestion in Elasticsearch/Kibana. Wenn Sie die Argumentation aus der Vogelperspektive wollen, warum das überhaupt möglich ist, beginnen Sie mit was OpenTelemetry ersetzen kann und was nicht.

Was zu OpenTelemetry migriert – und was nicht

OTel ersetzt die Collection- und Forwarding-Ebene. Es ersetzt nicht Elasticsearchs Index, Kibanas UI oder ES|QL – die bleiben in Elastic, wenn Sie es behalten, oder werden neu aufgebaut, wenn Sie gehen:

Elastic-Fähigkeit	Zu OTel migrieren?	Anmerkungen
Datei-/Log-Collection (Filebeat)	Ja	Der filelog-Receiver ersetzt Filebeat.
Host-/System-Metriken (Metricbeat)	Ja	hostmetrics (+ kubeletstats) ersetzen Metricbeats System-Module.
Windows-Event-Logs (Winlogbeat)	Ja	windowseventlog-Receiver.
Syslog-Ingestion	Ja	syslog-Receiver (RFC 3164 / 5424).
APM (Elastic-APM-Agents)	Meist	OTel-SDKs / Auto-Instrumentierung emittieren OTLP; Span- und Service-Benennung validieren.
Ingest-Pipeline-Parsing (grok, dissect)	Oft	Als transform- / filter-Processors (OTTL) nachbauen; ein Teil bleibt indexseitig.
Fleet-Flottenmanagement	Ja (als OpAMP)	Zentrales Agent-Management bildet sich auf eine OpAMP-Control-Plane ab, nicht auf Elastic Fleet.
Indexierung & Speicherung	Nein	Elasticsearch, oder ein Ersatz-Backend. Keine OTel-Angelegenheit.
ES / ES|QL / KQL-Queries	Nein	Die Query-Sprache ist backend-spezifisch; neu aufbauen, wenn Sie Elastic verlassen.
Kibana-Dashboards	Nein	Im neuen Backend neu aufbauen, oder Kibana dafür behalten.
Watcher / Kibana-Alerting	Nein	Separat zum Alerting des neuen Backends migrieren.

Die Faustregel: OTel bewältigt Collection (Logs, Metriken, Traces) und Flottenmanagement (über OpAMP) sauber. Elastic-spezifische Produkte – ES|QL, Kibana-Dashboards, Watcher – sind nichts, was Sie „migrieren”; Sie behalten sie, ersetzen sie oder legen sie still.

Die Elastic-Bausteine auf ihre OTel-Äquivalente abbilden

Der Grossteil der Migration ist eine Eins-zu-eins-Substitution. Jeder Beat- und Elastic-Agent-Input hat ein OpenTelemetry-Gegenstück:

Elastic	OpenTelemetry-Äquivalent
Filebeat (Dateien, Container)	OTel Collector mit dem filelog-Receiver
Metricbeat (System, Module)	hostmetrics- + kubeletstats- + prometheus-Receiver
Winlogbeat (WinEventLog)	windowseventlog-Receiver
Syslog-Input	syslog-Receiver (RFC 3164 / 5424)
Elastic-APM-Agents	OTel-SDKs / Auto-Instrumentierung, die OTLP emittieren
Ingest Pipelines (grok, dissect, enrich)	transform- / filter- / attributes-Processors (OTTL)
Fleet (zentrales Agent-Management)	OpAMP-Control-Plane
Elasticsearch (Ziel)	elasticsearch-Exporter – oder ein beliebiges OTLP-Backend

Beachten Sie die letzten beiden Zeilen – sie sind die Schlupflöcher. Der elasticsearch-Exporter des Collectors schreibt direkt in Ihr bestehendes Elasticsearch-Cluster, Sie müssen den Elastic Stack also nicht verlassen, um OpenTelemetry einzuführen – Sie stellen OTel zuerst davor und entscheiden über das Backend später. Und Fleets zentrales Management bildet sich auf OpAMP ab, Sie verlieren die Flottenkontrolle also nicht, wenn Sie den Elastic Agent fallen lassen; Sie verlagern sie auf einen offenen Standard. Diese Entkopplung ist der ganze Trick.

So sieht das in der Praxis aus – Collector-Sources zentral konfiguriert statt eine Beat-Config pro Host:

Schritt 1 – Collectors neben den Beats aufstellen

Fassen Sie die Beats oder Elastic Agents noch nicht an. Stellen Sie OTel Collectors neben ihnen bereit, die dieselben Sources lesen, und exportieren Sie über den elasticsearch-Exporter nach Elasticsearch. Ein minimaler Filelog-zu-Elasticsearch-Collector sieht so aus:

receivers:
  filelog:
    include: [/var/log/*.log]
    start_at: end
  hostmetrics:
    collection_interval: 30s
    scrapers: { cpu: , memory: , disk: , network: , load: }

exporters:
  elasticsearch:
    endpoints: ["https://elasticsearch.internal:9200"]
    logs_index: "otel-logs"

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [elasticsearch]
    metrics:
      receivers: [hostmetrics]
      exporters: [elasticsearch]

(Eine Anmerkung, falls Sie dies über LinkMesh verwalten: Sein eingebautes Elasticsearch-Ziel trägt Logs und Traces; Host-Metriken werden typischerweise stattdessen an ein Metrik-Backend wie Prometheus oder Grafana Cloud geroutet.)

An diesem Punkt hat sich für Ihre Nutzer nichts geändert – Daten landen weiterhin in Elasticsearch, und Kibana fragt sie weiterhin ab – aber die Collection-Ebene ist jetzt offen. Jede Verbesserung von hier an ist eine, die Sie aus einem Beat heraus nicht machen konnten.

Schritt 2 – Dual-Shipping und Vergleich

Fügen Sie einen zweiten Exporter hinzu. Schreiben Sie weiter nach Elasticsearch und beginnen Sie, denselben Stream an ein Kandidaten-OTLP-Backend zu schreiben (Grafana Loki, einen OTLP-nativen Store oder Object Storage). Jetzt können Sie sie Seite an Seite auf echten Produktionsdaten vergleichen – Suchen, Dashboards, Alert-Coverage – mit null Risiko, weil Elasticsearch weiterhin das System of Record ist.

exporters:
  elasticsearch:
    endpoints: ["https://elasticsearch.internal:9200"]
    logs_index: "otel-logs"
  otlphttp/candidate:
    endpoint: "https://backend.internal:4318"

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [elasticsearch, otlphttp/candidate]

Das ist der Schritt, den ein proprietärer Beat schlicht nicht machen kann: einen Stream an zwei Backends zugleich senden. Das ist es, was eine Elastic-Migration in einen graduellen, umkehrbaren Prozess statt eines Stichtags verwandelt.

Schritt 3 – Das Volumen kürzen, für dessen Indexierung Sie zahlten

Hier zahlt sich die Migration aus. Elastic-Kosten skalieren mit Ingestion und Speicherung, und ein grosser Anteil dessen, was Sie indexieren, ist Rauschen, das Sie nie durchsuchen. In einem Beat konnten Sie mit processors ein wenig tun; in einem OTel Collector können Sie viel tun, an einem Ort, den Sie kontrollieren.

Verwerfen Sie Sub-INFO-Logs, bevor sie je einen Index erreichen:

processors:
  filter/drop_debug:
    logs:
      log_record:
        - 'severity_number < SEVERITY_NUMBER_INFO'

Samplen Sie einen hochvolumigen Stream mit geringem Wert auf einen repräsentativen Anteil herunter:

processors:
  probabilistic_sampler:
    sampling_percentage: 20

Jeder am Collector verworfene Record ist ein Record, für dessen Ingestion, Indexierung und Aufbewahrung Sie nicht zahlen – in Elasticsearch oder einem beliebigen Backend pro GB. Das ist der einzelne grösste Hebel in der gesamten Migration – siehe Observability-Kosten senken für das vollständige Filter-/Sample-/Route-Playbook. Sie können ausserdem sensible Felder maskieren, bevor sie den Host verlassen – Kartennummern, E-Mails, Tokens – was Payloads verkleinert und PII gleichzeitig aus dem Backend heraushält, behandelt in PII-Maskierung in Logs.

Schritt 4 – Die Flotte mit OpAMP verwalten, nicht mit Fleet

Hier ist der Haken, den es zu benennen lohnt: Das gesamte Wertversprechen des Elastic Agent ist Fleet – zentrale Policies, Enrollment, Upgrades aus Kibana. Lassen Sie den Elastic Agent zugunsten roher OTel Collectors fallen, und Sie verlieren das, synchronisieren YAML von Hand über jeden Node – ein Schritt rückwärts in der Verwaltbarkeit.

Akzeptieren Sie diesen Handel nicht. Fleets Aufgabe bildet sich direkt auf OpAMP ab, das offene Protokoll zur Verwaltung einer Agent-Flotte. LinkMesh ist eine selbstgehostete OpAMP-Control-Plane: Richten Sie jeden Collector mit einem Token darauf, dann bauen Sie Sources, Processors und Routes in einer visuellen UI auf. Sie rendert und validiert die Config und rollt sie an die richtigen Nodes aus – die Fleet-Erfahrung, aber für OTel Collectors nach offenem Standard, und mit Durchsatz pro Kante, sodass Sie das gerade eingesparte Volumen sehen können. Weil sie pro Collector abgerechnet wird, nicht pro GB, ist das Tool, das Ihren Ausbruch aus der Volumen-Preisgestaltung verwaltet, nicht selbst nach Volumen bemessen. Jede Config-Änderung ist versioniert und auditierbar, GitOps-artig – siehe GitOps für Collector-Config.

Parität validieren, bevor Sie umsteigen

Dual-Shipping entrisikt die Migration nur, wenn Sie tatsächlich prüfen, dass die beiden Streams übereinstimmen. Bevor Sie irgendetwas entfernen, arbeiten Sie eine Validierungs-Checkliste ab:

• Volumen – vergleichen Sie Dokument-/Event-Zählungen pro Source zwischen Elasticsearch und dem Kandidaten über dasselbe Fenster. Eine grosse Lücke bedeutet eine verworfene Source oder einen zu aggressiven Filter.
• Vollständigkeit – bestätigen Sie, dass jeder Input, den ein Beat oder Elastic Agent sammelte, einen passenden Receiver hat, einschliesslich Windows-Event-Logs und etwaiger Custom-Module.
• Parsing – stichprobenartig prüfen, dass Timestamps, Severities und wichtige extrahierte Felder korrekt landen (OTTL-Parsing unterscheidet sich von grok-/dissect-Ingest-Pipelines; das ist die häufigste Lücke).
• Attribution – verifizieren Sie, dass die Resource-Attribute service.name, Host und Environment vorhanden sind, damit Daten so abfragbar sind, wie Ihre Dashboards und Suchen es erwarten.
• Sampling – bestätigen Sie, dass gesamplete Streams 100 % der Fehler und Security-Events behalten; nur die hochvolumige Mehrheit mit geringem Wert sollte ausgedünnt werden.
• Verworfene Telemetrie – prüfen Sie die eigenen internen Metriken des Collectors auf abgelehnte oder verworfene Records; ein stiller Exporter-Fehler sieht aus wie „weniger Rauschen”, bis ein Incident kommt.
• Downstream-Inputs – richten Sie die Kibana-Dashboards und Alerts, die am wichtigsten sind, gegen den Kandidaten neu aus (oder bauen Sie sie neu) und bestätigen Sie, dass sie sich füllen und auslösen.
• Fehlerverhalten – starten Sie einen Collector neu und kappen Sie eine Backend-Verbindung; bestätigen Sie, dass der Collector puffert und ohne Datenverlust oder Verklemmen fortsetzt.

Einen Rollback-Plan haben

Weil Sie Dual-Shipping betrieben haben, ist Rollback eingebaut – aber machen Sie ihn explizit, bevor Sie irgendetwas umlegen:

• Halten Sie die Beats / Elastic Agents am Laufen (oder leicht wieder aktivierbar) durch das gesamte Validierungsfenster. Deinstallieren Sie nicht am ersten Tag.
• Routen Sie unabhängig. Der Elasticsearch-Exporter und der Kandidaten-Exporter sind separate Blöcke; das Entfernen des einen berührt nie den anderen, sodass Sie einen einzelnen Stream zurückrollen können.
• Definieren Sie Erfolgsschwellen vorab – z. B. „Volumen innerhalb von 2 %, alle Prioritäts-Alerts feuern, keine Parsing-Regressionen für 7 Tage” – sodass der Cutover eine Entscheidung ist, kein Bauchgefühl.
• Behalten Sie die Fähigkeit umzuleiten. Falls der Kandidat sich fehlverhält, fügen Sie den elasticsearch-Exporter wieder zur Pipeline hinzu, und Sie sind mit einem Config-Push wieder vollständig auf Elastic.
• Stilllegen erst nach einem vereinbarten Beobachtungszeitraum – typischerweise ein bis zwei volle Geschäftszyklen nach dem Cutover, nicht in dem Moment, in dem Parität zum ersten Mal richtig aussieht.

Schritt 5 – Nach Ihrem eigenen Zeitplan umsteigen

Wenn sich das Kandidaten-Backend bewährt hat – Dashboards stimmen überein, Alerts feuern, die Suchen, auf die Ihr Team angewiesen ist, funktionieren – legen Sie den Exporter um. Entfernen Sie den elasticsearch-Exporter (oder behalten Sie ihn für eine Teilmenge von Daten, die Sie wirklich in Elastic haben wollen) und legen Sie die Beats und Elastic Agents Stream für Stream still. Weil Instrumentierung und Collection jetzt OTLP und OTel sind, gibt es nichts neu zu instrumentieren; es ist eine Exporter-Änderung.

Und die Migration ist wirklich fertig, nicht halbfertig: Ihre Telemetrie spricht jetzt ein offenes Protokoll, Ihre Agents werden auf einem offenen Standard verwaltet (OpAMP, nicht Fleet), und die nächste Backend-Entscheidung – falls es je eine gibt – ist ein weiterer Exporter-Block, kein weiteres einjähriges Projekt.

Die Migration in fünf Schritten

1. Substituieren – OTel Collectors neben den Beats bereitstellen, die über den elasticsearch-Exporter nach Elasticsearch exportieren. Für Nutzer ändert sich nichts.
2. Dual-Shipping – ein Kandidaten-OTLP-Backend hinzufügen und auf Live-Daten vergleichen.
3. Verfeinern – am Collector filtern, samplen und maskieren, um das Ingestion-Volumen zu kürzen.
4. Validieren & Rollback behalten – die Parität gegen die obige Checkliste prüfen, wobei die Beats als Ihr Sicherheitsnetz weiterhin an Ort und Stelle sind.
5. Umsteigen – den Exporter umlegen, wenn die Parität hält; die Beats und Elastic Agents nach einem Beobachtungszeitraum Stream für Stream stilllegen, wobei das Flottenmanagement nun auf OpAMP läuft.

Sie können alle fünf mit rohen OTel Collectors und viel YAML durchführen, oder Sie verwalten die Flotte von einer selbstgehosteten OpAMP-Control-Plane und ersparen sich das Handsynchronisieren. So oder so ist das Lock-in auf der Collection-Ebene in dem Moment weg, in dem Ihre Daten OTLP sprechen.