Eine Strategie, viele Backends

Die meisten Unternehmen ab einer gewissen Grösse betreiben drei oder vier Observability-Backends gleichzeitig. Splunk, weil sich das SOC vor zehn Jahren darauf standardisiert hat. Sentinel, weil es mit E5 kam und das Security-Team es Microsoft-nativ wollte. Grafana, weil das Plattform-Team es mag und es günstig ist. Dynatrace, weil eine geschäftskritische Anwendung während eines Transformationsprogramms onboardet wurde und niemand sie anfasst.

Das wird meist als Wildwuchs beschrieben, und die empfohlene Lösung heisst Konsolidierung. In der Praxis scheitern Konsolidierungsprojekte überwiegend, weil jedes dieser vier einen echten Eigentümer mit einem echten Grund hat — und „nimm stattdessen mein Werkzeug” ist kein Argument, das gegen eine Compliance-Pflicht oder eine bis 2029 laufende Verlängerung gewinnt.

Die pragmatische Position lautet: Mehrere Backends sind dauerhaft, und das zu lösende Problem ist nicht, wie viele Sie haben — es ist, wie oft Sie dieselben Daten erfassen.

Das eigentliche Problem: N Agents pro Host

Gehen Sie in einem solchen Bestand auf einen Host und zählen Sie die Agents. Ein Splunk Universal Forwarder, der Azure Monitor Agent, ein Prometheus Node Exporter, ein Dynatrace OneAgent. Vier Prozesse, vier Konfigurationsmechanismen, vier Upgrade-Zyklen, vier Sätze Credentials — die alle im Wesentlichen dieselben Dateien und dasselbe /proc lesen.

Die Kosten davon sind konkret:

• Sie bezahlen dieselben Daten mehrfach. Dieselbe Log-Zeile wird von zwei oder drei Anbietern unabhängig erfasst, übertragen und aufgenommen.
• Hosts werden doppelt gezählt. Mehrere Plattformen rechnen pro überwachtem Host ab. Zwei Agents, die dieselbe Maschine melden, können zwei abrechenbare Hosts erzeugen — ein reiner Verschwendungsposten, den man leicht übersieht.
• Der Ressourcen-Fussabdruck vervielfacht sich auf Maschinen, die für den Workload dimensioniert wurden, nicht für das Monitoring.
• Nichts ist konsistent. Jeder Agent hat eine eigene Vorstellung davon, wie ein Host heisst — Korrelation über Backends hinweg heisst also, drei Namensschemata abzugleichen.
• Jede Backend-Änderung ist eine Flottenänderung, weil die Erfassung ans Ziel geschweisst ist.

Einmal erfassen, einmal verarbeiten, auffächern

Die Alternative ist ein einziger Erfassungspfad pro Host und Auffächerung an dessen Ende. Ein OpenTelemetry Collector liest die Dateien und die Host-Metriken; eine einzige Pipeline erledigt die gemeinsame Arbeit — Parsing, Anreicherung, Redaction; und mehrere Exporter senden an mehrere Ziele.

service:
  pipelines:
    logs:
      receivers: [filelog, journald, otlp]
      processors: [resourcedetection, transform/redact, batch]
      exporters: [splunk_hec, otlp/grafana, otlphttp/archive]

Drei Eigenschaften zählen hier und verdienen es, ausgesprochen zu werden:

• Ein Lesen, ein Parsen, eine Redaction. Die teure und sicherheitsrelevante Arbeit passiert einmal — eine Maskierungsregel kann also nicht auf dem Weg zu einem Backend korrekt angewendet und auf dem Weg zu einem anderen vergessen werden.
• Ziele sind unabhängig. Ein Backend hinzuzufügen, zu entfernen oder zu ersetzen ist eine Exporter-Änderung, keine flottenweite Agent-Operation.
• Auffächern verdoppelt nicht den Aufwand, aber es verdoppelt die Daten — und das hat Kosten und eine Korrektheitsfrage, gleich im Anschluss.

Die vier Fallen

Auffächern hat vorhersagbare Fehlermodi. Alle vier sind vermeidbar und alle vier sind häufig:

• Zwei Erfassungs-Agents für dieselbe Quelle betreiben. Der klassische Fehler während einer Migration: den alten Anbieter-Agenten weiter die Datei tailen lassen und einen Collector ergänzen, der dieselbe Datei tailt. Jetzt wird der Host doppelt gezählt und jede Log-Zeile existiert nachgelagert zweimal. Verschieben Sie die Erfassung, und fächern Sie dann von einer Stelle aus auf — Dual-Shipping ohne Duplikate.
• Alles überallhin schicken. Auffächern heisst nicht, dass jedes Ziel den vollen Stream bekommt. Sicherheitsdatensätze gehören ins SIEM; ausschweifende Debug-Logs der Anwendung nicht — und sie dorthin zu legen ist der Weg, auf dem sich eine Sentinel-Rechnung verdoppelt. Teilen Sie per Attribut auf und schicken Sie jedem Ziel das, wofür es da ist: Route Telemetry by Attribute (englisch).
• Zielspezifische Anforderungen ignorieren. Backends wollen Unterschiedliches: einen Splunk-Index und Sourcetype, Sentinels Tabellenform, ein Grafana-Cloud-Tenant-Label. Das ist zielspezifische Verarbeitung auf einem Zweig, kein Grund für getrennte Erfassung.
• Ein Credential-Satz für alles. Jedes Ziel braucht ein eigenes Credential, und eines zu rotieren sollte nicht heissen, jeden Host anzufassen — ein Argument dafür, Ziel-Credentials zentral zu halten statt inline im YAML pro Node (Secrets verwalten (englisch)).

Governance folgt der Auffächerung

Sobald eine Pipeline vier Backends speist, die vier Teams gehören, werden manche Fragen organisatorisch statt technisch:

• Wer darf ein Ziel hinzufügen? Ein Exporter zu einem neuen SaaS-Endpunkt ist eine Egress-Entscheidung und sollte nicht etwas sein, das jeder Engineer ungesehen in eine Config schreibt.
• Wem gehört das Volumen einer Route? Verdreifacht sich die Route des SOC, wessen Budget ist das und wer erfährt davon? Durchsatz pro Route macht das beantwortbar — echten Durchsatz sehen.
• Was hindert das Problem eines Ziels daran, allen zum Problem zu werden? Ein Backend, das keine Daten mehr annimmt, erzeugt Backpressure. Queue-Verhalten und Retry-Grenzen pro Exporter entscheiden, ob daraus ein lokales Problem wird oder ein Pipeline-Stillstand — Collector-High-Availability.

Wo die vier Backends vier verschiedenen Tenants oder Geschäftsbereichen dienen statt vier Funktionen, wird daraus die vollständige Mandantenfähigkeitsfrage — Multi-Tenant-Collector-Architektur.

Der strategische Nutzen, den niemand einplant

Der Grund, das zu tun, ist Effizienz. Der Grund, warum es sich als wichtig erweist, ist Wahlfreiheit.

Ist die Erfassung einmal vom Ziel entkoppelt, ist ein fünftes Backend eine Konfigurationsänderung — und, wichtiger noch, eines zu entfernen ebenfalls. Die Evaluation, die Sie nie rechtfertigen konnten, wird zu einer Route auf einen Testendpunkt für zwei Wochen. Die Verlängerungsverhandlung ändert vollständig ihren Charakter, wenn die ehrliche Antwort auf „was bräuchte es, um zu gehen” lautet „ein Exporter-Block und vierzehn Tage” statt „achtzehn Monate und jeder Host”.

Das ist dasselbe Argument wie in Das Ende des Vendor-Lock-in — nur durch die Hintertür eines Kostensenkungsprojekts erreicht.

Wo anfangen

1. Zählen Sie die Agents auf einem repräsentativen Host. Das ist meist die Folie, die das Projekt genehmigt bekommt.
2. Wählen Sie das unstrittigste Backend — meist das des Plattform-Teams — und verlegen Sie dessen Erfassung auf einen Collector, während die anderen unangetastet bleiben.
3. Ergänzen Sie ein zweites Ziel an derselben Pipeline statt eines zweiten Agenten. Prüfen Sie, dass beide Backends übereinstimmendes Volumen sehen, bevor Sie etwas entfernen.
4. Bauen Sie dann Agents einzeln ab, Quelle für Quelle, während die Erfassungsschicht konstant bleibt.
5. Teilen Sie den Stream nach Wert auf, sobald die Auffächerung funktioniert, sodass jedes Backend erhält, wofür es da ist, statt alles.