Splunk Enterprise → OpenTelemetry

Splunk ist eine wirklich leistungsstarke Plattform, und für viele Teams hat sie sich ihren Platz verdient. Aber zwei Dinge treiben Teams dazu, sich den Ausgang zu suchen: die aufnahmebasierte Rechnung, die mit jedem Gigabyte steigt, das Sie indexieren, und der Forwarder-Bestand – eine Flotte von Universal Forwardern und HEC-Endpoints, die nur Splunk sprechen und nur Splunk füttern.

Die gute Nachricht ist, dass der Wegzug von Splunk nicht länger ein Rip-and-Replace bedeutet. Mit OpenTelemetry können Sie eine herstellerneutrale Collection-Ebene unter Ihre bestehende Pipeline legen, Splunk als eines von mehreren Zielen weiterlaufen lassen und das Volumen kürzen, für dessen Indexierung Sie zahlen – alles, bevor Sie sich auf einen vollständigen Cutover festlegen. Dieser Leitfaden begeht die Migration von Ende zu Ende, einschliesslich, wie Sie Parität validieren und zurückrollen.

Zuerst: welches „Splunk” migrieren wir?

„Splunk zu OpenTelemetry” ist mehrdeutig, und vorab konkret zu werden erspart Ihnen einen Scoping-Fehler. Dieser Leitfaden befasst sich mit der Splunk-Enterprise-Ingestion – der Pipeline, die Daten in Splunk-Indexer bringt. Wissen Sie, welche Komponenten Sie tatsächlich betreiben:

• Universal Forwarder (UF) – der leichtgewichtige Agent, der Dateien und Windows-Event-Logs tailt und weiterleitet. Das ist das Grösste, was OTel ersetzt.
• Heavy Forwarder (HF) – eine vollständige Splunk-Instanz, die für Routing, Filtern und Parsing vor der Indexierung verwendet wird. Ihre Filter-/Route-Logik bildet sich auf Collector-Processors ab.
• HTTP Event Collector (HEC) – der Token-basierte HTTP-Ingest-Endpoint. Sowohl eine Source, die Sie ersetzen können (Apps pushen stattdessen OTLP), als auch ein Ziel, das Sie behalten (der splunk_hec-Exporter des Collectors schreibt daran).
• Splunk Connect for Kubernetes – der alte Helm-basierte K8s-Log-/Metrik-Collector, End-of-Support seit Januar 2024. Splunks eigener Ersatz ist der OTel-basierte Splunk OpenTelemetry Collector for Kubernetes – auf K8s ist selbst Splunks Antwort bereits OpenTelemetry.
• Splunk Distribution of the OpenTelemetry Collector – Splunks eigener signierter OTel-Collector-Build. Wenn Sie ihn bereits betreiben, sind Sie teilweise schon auf OTel; die Processor- und Routing-Arbeit dieses Leitfadens gilt weiterhin, Sie tauschen nur den Exporter.

Eine weitere Abgrenzung: Splunk Enterprise (selbstverwaltete Log-Plattform) ist ein anderes Produkt als Splunk Observability Cloud (das APM-/Metrik-SaaS mit SignalFx-Abstammung). Dieser Leitfaden zielt auf die Splunk-Enterprise-Ingestion. Die Pipeline-Mechanik überträgt sich auf Observability Cloud, aber die Receiver und Metrik-Konventionen unterscheiden sich.

Wenn Sie die Argumentation aus der Vogelperspektive wollen, warum das überhaupt möglich ist, beginnen Sie mit Vendor-Lock-in mit OpenTelemetry reduzieren und was OpenTelemetry ersetzen kann und was nicht. Dieser Beitrag ist das Splunk-spezifische Playbook.

Was zu OpenTelemetry migriert – und was nicht

OTel ersetzt die Ingest- und Forwarding-Ebene. Es ersetzt nicht Splunks Index, seine Suche oder SPL – die bleiben in Splunk, wenn Sie es behalten, oder werden neu aufgebaut, wenn Sie gehen:

Splunk-Fähigkeit	Zu OTel migrieren?	Anmerkungen
Datei-/WinEventLog-Collection	Ja	filelog- / windowseventlog-Receiver ersetzen den Universal Forwarder.
HEC-Ingestion aus Apps	Ja	Apps emittieren OTLP an den Collector; oder HEC behalten und den splunk_hec-Receiver hinzufügen.
Syslog-Ingestion	Ja	syslog-Receiver (RFC 3164 / 5424).
HF-Parsing / -Routing (props/transforms)	Ja	transform- / filter-Processors (OTTL) und der routing-Connector.
Index-Time-Feldextraktion	Oft	Als Processors nachbauen; einige SPL-Time-Extraktionen bleiben suchseitig.
Indexierung & Speicherung	Nein	Splunk-Indexer, oder ein Ersatz-Backend. Keine OTel-Angelegenheit.
SPL-Suchen & gespeicherte Suchen	Nein	Die Query-Sprache ist backend-spezifisch; neu aufbauen, wenn Sie Splunk verlassen.
Dashboards & Reports	Nein	Im neuen Backend neu aufbauen, oder Splunk dafür behalten.
Alerts / geplante Suchen	Nein	Separat zum Alerting des neuen Backends migrieren.

Die Splunk-Bausteine auf ihre OTel-Äquivalente abbilden

Der Grossteil der Migration ist eine Eins-zu-eins-Substitution. Jede Splunk-Collection-Komponente hat ein OpenTelemetry-Gegenstück:

Splunk	OpenTelemetry-Äquivalent
Universal Forwarder (Dateien, WinEventLog)	OTel Collector mit den filelog- / windowseventlog-Receivern (plus journald für systemd-Journals)
HTTP Event Collector (HEC)	OTLP-Receiver (gRPC + HTTP)
Syslog-Input (TCP/UDP)	syslog-Receiver (RFC 3164 / 5424)
props.conf / transforms.conf (SEDCMD, Feldextraktion)	transform- / filter- / attributes-Processors (OTTL)
Heavy-Forwarder-Routing	Collector-routing-Connector + mehrere Exporter
Splunk-Indexer (Ziel)	splunk_hec-Exporter – oder ein beliebiges OTLP-Backend

Beachten Sie die letzte Zeile. Der splunk_hec-Exporter bedeutet, dass der OTel Collector über HEC direkt in Ihre bestehenden Splunk-Indexer schreiben kann. Sie müssen Splunk nicht verlassen, um OpenTelemetry einzuführen – Sie stellen OTel zuerst davor und entscheiden über das Backend später. Diese Entkopplung ist der ganze Trick.

So sieht das zentral verwaltet aus – Collector-Sources einmal konfiguriert statt eine Forwarder-Config pro Host:

Schritt 1 – Collectors neben den Forwardern aufstellen

Fassen Sie die Forwarder noch nicht an. Stellen Sie OTel Collectors neben ihnen bereit, die dieselben Log-Sources lesen. Ein minimaler Filelog-zu-Splunk-Collector sieht so aus:

receivers:
  filelog:
    include: [/var/log/*.log]
    start_at: end

exporters:
  splunk_hec:
    token: "${SPLUNK_HEC_TOKEN}"
    endpoint: "https://splunk.internal:8088/services/collector"
    source: "otel-collector"

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [splunk_hec]

An diesem Punkt hat sich für Ihre Nutzer nichts geändert – Daten landen weiterhin in Splunk, in denselben Indizes – aber die Collection-Ebene ist jetzt offen. Jede Verbesserung von hier an ist eine, die Sie aus einem Universal Forwarder heraus nicht machen konnten.

Schritt 2 – Dual-Shipping und Vergleich

Fügen Sie einen zweiten Exporter hinzu. Schreiben Sie weiter nach Splunk 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 Splunk weiterhin das System of Record ist.

exporters:
  splunk_hec:
    token: "${SPLUNK_HEC_TOKEN}"
    endpoint: "https://splunk.internal:8088/services/collector"
  otlphttp/candidate:
    endpoint: "https://backend.internal:4318"

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

Das ist der Schritt, den ein proprietärer Forwarder schlicht nicht machen kann: einen Stream an zwei Backends zugleich senden. Das ist es, was eine Splunk-Migration zu einem graduellen, umkehrbaren Prozess statt eines Stichtags macht.

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

Hier zahlt sich die Migration aus. Splunk rechnet nach aufgenommenem Volumen ab, und ein grosser Anteil dessen, was Sie indexieren, ist Rauschen, das Sie nie durchsuchen. In einem Forwarder konnten Sie mit props.conf 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 Indexer 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 Aufnahme, Indexierung und Aufbewahrung Sie Splunk (oder ein beliebiges Backend pro GB) nicht zahlen. 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. Das clientseitig, vor dem Egress, zu tun, wird in PII-Maskierung in Logs behandelt.

Schritt 4 – Die Flotte verwalten, nicht YAML von Hand bearbeiten

Hier ist der Haken, den niemand erwähnt: Splunk gibt Ihnen einen Deployment Server, um die Forwarder-Flotte zentral zu verwalten (jeder UF wird mit dem Deployment-Client ausgeliefert, der bei ihm nach Hause telefoniert). Rohe OTel Collectors haben kein Äquivalent – von Haus aus synchronisieren Sie YAML von Hand über jeden Node, was ein Schritt rückwärts in der Verwaltbarkeit gegenüber Splunks Deployment Server ist.

Akzeptieren Sie diesen Handel nicht. Verwalten Sie die Collector-Flotte von einer Control Plane aus, die OpAMP spricht. LinkMesh ist eine selbstgehostete: 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 Deployment-Server-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 Event-Zählungen pro Source/Index zwischen Splunk 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 Sourcetype, den der UF sammelte, einen passenden Receiver hat, einschliesslich Windows-Event-Logs und etwaiger Scripted Inputs.
• Parsing – stichprobenartig prüfen, dass Timestamps, Severities und wichtige extrahierte Felder korrekt landen (OTTL-Parsing unterscheidet sich von props.conf; 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 Suchen es erwarten.
• 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.
• 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.
• Downstream-Inputs – richten Sie die 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 Universal Forwarder am Laufen (oder leicht wieder aktivierbar) durch das gesamte Validierungsfenster. Deinstallieren Sie nicht am ersten Tag.
• Routen Sie unabhängig. Der Splunk-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 splunk_hec wieder zur Pipeline hinzu, und Sie sind mit einem Config-Push wieder vollständig auf Splunk.
• 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 splunk_hec aus der Pipeline (oder behalten Sie ihn für eine Teilmenge von Daten, die Sie wirklich in Splunk haben wollen) und legen Sie die Universal Forwarder 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 offenen Standards verwaltet, 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 Forwardern bereitstellen, die über splunk_hec nach Splunk 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 Forwarder als Ihr Sicherheitsnetz weiterhin an Ort und Stelle sind.
5. Umsteigen – den Exporter umlegen, wenn die Parität hält; die Forwarder nach einem Beobachtungszeitraum Stream für Stream stilllegen.

Sie können alle fünf mit rohen OTel Collectors und viel YAML durchführen, oder Sie verwalten die Flotte von einer selbstgehosteten 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.