Die fehlende Schicht

Zeichnen Sie die Architektur fast jedes Observability-Stacks, und Sie erhalten zwei Kästchen: Dinge, die Telemetrie erzeugen, und eine Plattform, die sie speichert und abfragt. Ein Agent verbindet sie. Das ist das ganze Bild, und es ist seit zwanzig Jahren das ganze Bild.

Zeichnen Sie nun die Architektur einer beliebigen anderen Datendomäne in Ihrer Organisation. Transaktionsdaten gehen nicht direkt von der Anwendung ins Warehouse — es gibt Ingestion, Validierung, Transformation, Routing. Nachrichtengetriebene Systeme haben Broker. Selbst die bescheidene Web-Ebene hat einen Reverse Proxy davor, weil niemand will, dass Clients direkt mit Applikationsservern sprechen.

Observability hat diesen Schritt übersprungen. Nicht aus einem guten architektonischen Grund — aus einem kommerziellen. Dieser Beitrag handelt davon, warum die Schicht fehlt, was ihre Abwesenheit kostet und warum sie jetzt kommt, ob geplant oder nicht.

Wenn Sie die Mechanik wollen — woraus eine Pipeline besteht und wie man eine betreibt —, beginnen Sie mit Was ist eine Telemetrie-Pipeline. Dieser Beitrag ist die Begründung, warum es die Schicht überhaupt gibt.

Warum sich die Schicht nie gebildet hat

Der Agent kam vom Backend-Anbieter. Diese eine Tatsache erklärt das meiste.

Wer Splunk kaufte, bekam Forwarder. Datadog gab Ihnen den Datadog Agent. New Relic gab Ihnen seinen APM-Agenten, Elastic gab Ihnen Beats. In jedem Fall wurde die Erfassungsschicht von dem gebaut, verschenkt und gepflegt, der den Speicher verkaufte — und sie war auf dessen Ingest optimiert, in dessen Vertrag eingepreist und über dessen Konsole konfiguriert.

Diese Anordnung ist sehr bequem und still folgenreich. Sie bedeutet:

• Erfassung war nie eine Entwurfsentscheidung. Sie wählten keinen Agenten; Sie erbten einen, als Sie ein Backend wählten.
• Niemand hatte einen Anreiz, weniger zu schicken. Die Organisation, die Ihre Erfassungsschicht baute, rechnet nach empfangenen Gigabytes ab. Da steckt keine Verschwörung dahinter — nur ein fehlender Druck in Richtung Reduktion.
• Die Schicht hatte keine eigenständige Existenz, also bildeten sich keine Standards um sie, also blieb jeder Anbieter-Agent mit jedem anderen inkompatibel, also hiess ein Backend-Wechsel, jeden Host anzufassen.

Vergleichen Sie die Datenbankwelt, die dasselbe durchlief und anders herauskam. Anwendungen betteten früher anbieterspezifische Client-Logik ein und sprachen direkt mit einer Datenbank. Die Mittelschicht bildete sich, weil die Kopplung im Grossen unerträglich wurde — und sobald sie existierte, wurde sie zum Ort von Caching, Pooling, Routing und Zugriffskontrolle.

Observability ist an dem Punkt, an dem die Kopplung unerträglich geworden ist — rund zwanzig Jahre später.

Was die fehlende Schicht kostet

Die Abwesenheit ist nicht abstrakt. Sie zeigt sich als vier wiederkehrende, teure Symptome:

• Die Kosten entscheidet, wer die Logs erzeugt. Das Volumen wird am Rand durch die Log-Anweisung einer Entwicklerin gesetzt und am Monatsende auf einer Rechnung entdeckt. Nichts dazwischen greift ein. Backend-seitige Kontrollen — Aufbewahrungsstufen, Sampling, Index-Policies — wirken alle auf Daten, die Sie bereits übertragen und deren Aufnahme Sie bereits bezahlt haben.
• Compliance ist rückwirkend. Ob Kundendaten das Netzwerk verliessen, entschied das, wozu der Agent konfiguriert war — Monate bevor jemand die Frage stellte. Die danach verfügbaren Kontrollen sind Zugriffskontrollen auf eine Kopie, die die Grenze längst überschritten hat.
• Backend-Migration bedeutet Neuinstrumentierung. Die teuerste Eigenschaft der Zwei-Kästchen-Architektur. Zu ändern, wo Telemetrie gespeichert wird, sollte eine Routing-Änderung sein; ohne Mittelschicht ist es ein flottenweiter Agententausch.
• Es gibt keinen Ort für übergreifende Logik. Jede Organisation will irgendwann dasselbe — dieses Feld überall maskieren, Health-Checks überall verwerfen, jeden Datensatz mit dem zuständigen Team taggen. Ohne gemeinsame Schicht wird jedes davon zu N Implementierungen in N Services, und eine davon ist immer falsch.

Jedes Symptom wird lokal behandelt: ein Kostenprojekt, eine Compliance-Prüfung, ein Migrationsprojekt. Es ist dieselbe strukturelle Lücke, die sich viermal zeigt.

Was die Schicht tatsächlich ist

Eine Telemetrie-Pipeline ist eine Ebene zwischen Produzenten und Backends, die vier Entscheidungen besitzt:

• Was erfasst wird, einheitlich, ohne dass jedes Team es neu erfindet.
• Was darin steckt, wenn es hinausgeht — Redaction und Anreicherung als Policy statt als Kommentar im Code-Review.
• Wie viel davon es gibt — Filterung, Sampling und Aggregation vor dem Egress angewendet, wo sie günstig sind, statt nach der Aufnahme, wo sie es nicht sind.
• Wohin es geht — pro Datensatz, per Attribut, an ein Ziel oder mehrere.

Der Grund, warum OpenTelemetry für dieses Argument zählt, ist nicht das SDK. Es ist, dass OTLP und der Collector die Mittelschicht ohne Erlaubnis eines Anbieters baubar gemacht haben — ein offenes Wire-Format und eine offene, programmierbare Komponente im Pfad. Der Standard hat die Nachfrage nach der Schicht nicht erzeugt; die Nachfrage war da. Er hat entfernt, was ihre Entstehung verhinderte.

Der Einwand, den man ernst nehmen sollte

„Das ist bloss eine weitere Komponente, die betrieben werden will, und sie sitzt im kritischen Pfad meiner Observability-Daten.”

Das stimmt, und es ist der ehrliche Preis. Eine Pipeline-Ebene kann ausfallen, braucht ein eigenes Verfügbarkeitskonzept und schafft eine Stelle, an der eine schlechte Config Datensätze verwirft, die Sie gebraucht hätten — weshalb Vorschau an echten Daten und gestaffelte Rollouts hier mehr zählen als bei den meisten Infrastrukturen. Collector-High-Availability behandelt, was ein ordentlicher Betrieb umfasst.

Das Gegenargument lautet nicht, dass die Kosten klein wären. Es lautet, dass Sie bereits eine grössere Version davon zahlen — verteilt und unsichtbar: die Kopplungssteuer bei jeder Migration, die Compliance-Exposition, die Sie nicht sehen, und das Volumen, das niemand steuert. Eine Mittelschicht macht diese Kosten explizit und zentral, und genau das macht sie beherrschbar.

Was mitzunehmen ist

Wenn Ihr Architekturdiagramm zwei Kästchen und einen Pfeil hat, fehlt die Schicht nicht — sie ist implizit, verteilt über jede Agent-Config auf jedem Host, niemandem gehörend und von Ihrem Backend-Anbieter optimiert.

Sie explizit zu machen verlangt kein Big-Bang-Projekt. Es verlangt, eine Komponente in den Pfad zu setzen, die Sie kontrollieren, und dann Entscheidungen nacheinander hineinzuverlagern: erst Volumen, dann Redaction, dann Routing. Jede davon ist für sich wertvoll, und zusammen sind sie die Ebene.