Observability-Stack selbst bauen oder kaufen — vier Kriterien

Die Frage kommt in fast jedem Erstgespräch, und meistens ist sie aufgeladen, bevor jemand sie ausspricht. Der eine hat gehört, kommerzielle APM-Tools seien überteuerter Vendor-Lock-in. Der andere hat gehört, Open Source sei ein Bastelkeller, den am Ende niemand betreibt. Beide haben ein bisschen recht, und beide stellen die falsche Frage. Ob ein Observability-Stack selbst betrieben oder eingekauft wird, hängt nicht an Ideologie, sondern an vier nüchternen Kriterien.

Ausgangslage: Zwei Lager, die dieselbe Frage falsch stellen

Wir haben beide Welten von innen gesehen. Jahrelang als Subunternehmer eines großen APM-Anbieters, quer durch EMEA, in Produktion und mit Bereitschaftstelefon, und in derselben Zeit mit dem LGTM-Stack, der bei uns vom Nebenprojekt zur festen Größe wurde. Gemeint sind damit Loki für Logs, Grafana für die Oberfläche, Tempo für Traces und Mimir für Metriken. Die Kunden reichten vom Mittelständler mit einem Platform-Team von drei Leuten bis zum Konzern mit Dutzenden Entwicklungsteams und eigener Aufsicht im Nacken.

Aus dieser Doppelrolle heraus ist eine Beobachtung konstant: „Open Source gegen kommerziell" ist gar nicht die Streitachse, an der sich die Entscheidung entscheidet. Die echte Achse verläuft woanders, nämlich zwischen selbst bauen und betreiben auf der einen und bequem beim Anbieter einkaufen auf der anderen Seite. Das ist etwas anderes, und es lässt sich mit vier Kriterien entscheiden statt mit Glaubenssätzen.

Was ein selbst betriebener Observability-Stack wirklich kostet

Ein kommerzielles Tool nimmt Betriebsarbeit ab, ein Open-Source-Stack gibt Kontrolle. Das ist der eigentliche Handel, nicht „freie Software gut, teure Software böse". Ein selbst betriebener Grafana-Stack ist kein Sparmodell, er ist eine Verpflichtung. Bezahlt wird nicht die Lizenz, sondern die Leute, die den Stack am Laufen halten, aktualisieren, skalieren und um drei Uhr nachts debuggen, wenn die Ingestion-Pipeline vollläuft.

Umgekehrt kauft sich niemand mit einem kommerziellen APM frei von Verantwortung. Er kauft sich frei von einem Teil des Betriebs, nicht von der Frage, wo seine Daten liegen und wer darauf zugreifen kann. Und „Betrieb" ist beim LGTM-Stack keine Abstraktion: Das sind Upgrades von vier Komponenten in einem Rhythmus, den der Hersteller vorgibt, Retention und Compaction im Objektspeicher, Kapazitätsplanung für Ingester und Querier und ein Monitoring für das Monitoring selbst, weil ein Stack, der still ausfällt, schlimmer ist als keiner.

OpenTelemetry hat die alte Lagerlogik ohnehin unterlaufen. Sind die Anwendungen einmal mit OpenTelemetry instrumentiert, ist die Frage nach dem Backend zweitrangig geworden: Dieselben Traces gehen heute in ein kommerzielles Tool und morgen in Tempo, ohne dass der Code angefasst wird. OpenTelemetry ist die Brücke, kein Lager, und das nimmt der Grundsatzentscheidung viel von ihrem Drama.

Vier Kriterien, an denen die Entscheidung wirklich hängt

Compliance. In regulierten Umgebungen wie Finanzsektor, Gesundheitswesen oder öffentlicher Hand ist die Diskussion oft beendet, bevor sie technisch wird. Verlangt die Aufsicht, dass bestimmte Daten das eigene Rechenzentrum nicht verlassen, fällt ein reines SaaS-Angebot durch, egal wie gut es ist. Deshalb gehören die konkreten Vorgaben früh auf den Tisch, nicht die Feature-Listen.

Datenhoheit. Logs und Traces enthalten oft mehr, als den Verantwortlichen bewusst ist: Request-Payloads, User-IDs, im schlimmsten Fall personenbezogene Daten, die niemand dort ablegen wollte. Landen diese Daten in einer Cloud außerhalb der EU, ist die Frage nach dem Zugriff durch Dritte keine theoretische mehr. Wer europäische Daten schützen muss, baut das in die Architektur ein, nicht nachträglich als Richtlinie obendrauf. Das kann ein Backend im eigenen Rechenzentrum bedeuten, einen Anbieter mit garantiertem EU-Betrieb oder eine Filterung der Daten, bevor sie das Haus verlassen.

Know-how. Die ehrlichste Frage im ganzen Prozess ist, ob das Team heute die Leute hat, um den Stack zu betreiben, nicht ob es sie ausbilden könnte. Wir haben genug Projekte gesehen, in denen ein ambitionierter Open-Source-Stack aufgesetzt wurde und dann verwaiste, weil die zwei Leute, die ihn verstanden, das Team verließen. Ein selbst betriebener Stack ohne dauerhaftes internes Know-how ist ein Risiko, kein Vermögenswert.

Teamstruktur. Gibt es ein Platform-Team, das Observability als Produkt betreiben kann und will, ist Selbstbetrieb oft sinnvoll. Sind es Entwicklungsteams, die Features liefern sollen und Monitoring nebenbei mitschleppen, kauft man besser ein und erspart dem Team den Nebenkriegsschauplatz. Der Preis steht bewusst nicht in dieser Liste: Er kommt zuletzt, und er sieht selten so aus wie in der ersten Rechnung.

Datenhoheit lässt sich in der Pipeline erzwingen, nicht in der Richtlinie

Von den vier Kriterien ist Datenhoheit das einzige, das sich technisch absichern lässt, und zwar unabhängig davon, ob am Ende gebaut oder gekauft wird. Der OpenTelemetry Collector sitzt zwischen den Anwendungen und jedem Backend. Dort lassen sich Attribute löschen oder hashen, bevor ein einziger Span das Haus verlässt. Die Konfiguration gilt für den OpenTelemetry Collector Contrib 0.128 mit Grafana Tempo 2.8 als Backend:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: ${env:MY_POD_IP}:4317

processors:
  attributes/datenhoheit:
    actions:
      - key: http.request.header.authorization
        action: delete
      - key: user.email
        action: delete
      - key: enduser.id
        action: hash
  batch: {}

exporters:
  otlp/tempo:
    endpoint: tempo-distributor.observability:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes/datenhoheit, batch]
      exporters: [otlp/tempo]

Der Attributes-Processor kennt die Aktionen insert, update, upsert, delete, hash, extract und convert. Im Beispiel wird der Authorization-Header gelöscht, die E-Mail-Adresse entfernt und die Nutzerkennung per SHA-1 gehasht, sodass ein Nutzer über mehrere Traces hinweg korrelierbar bleibt, ohne identifizierbar zu sein. Der Receiver bindet auf die Pod-IP aus der Umgebungsvariable MY_POD_IP, so wie es das offizielle Helm-Chart des Collectors vorgibt. Wer den Exporter später gegen einen SaaS-Anbieter tauscht, behält diesen Filter, weil er vor dem Export sitzt.

Damit wird aus der Datenhoheit eine Design-Entscheidung im Collector statt einer Zusicherung im Vertrag. Der Vertrag bleibt trotzdem nötig, aber er ist nicht mehr die einzige Sicherung. Und die Konfiguration ist prüfbar: Wer wissen will, was das Haus verlässt, liest die Liste der Aktionen, nicht die Anlage zum Auftragsverarbeitungsvertrag.

Die Reihenfolge, in der wir die Entscheidung vorbereiten

Zuerst die harten Grenzen: Compliance und Datenhoheit sind Ausschlusskriterien, keine Präferenzen. Was hier nicht geht, geht nicht, egal wie attraktiv der Rest wäre. Diese Klärung dauert in der Regel ein Gespräch mit dem Datenschutz und eines mit der Fachaufsicht, und sie streicht die Optionsliste oft um die Hälfte.

Danach die ehrliche Kapazitätsfrage, wer den Stack in zwei Jahren noch betreibt. Fehlt darauf eine überzeugende Antwort, spricht viel für eingekauften Betrieb, unabhängig davon, ob das Backend am Ende kommerziell oder Open Source ist.

Und in jedem Fall die Instrumentierung mit OpenTelemetry, wo immer es geht. Das entkoppelt die Anwendungen vom Backend und hält die Tür offen, sodass die Backend-Entscheidung aus Wahlfreiheit fällt und nicht aus einem Lock-in heraus. Bauen oder kaufen ist außerdem keine einmalige Ja-Nein-Frage: Die Entscheidung darf pro Datenklasse fallen, kritische Daten im eigenen Stack, unkritische Telemetrie im SaaS.

Was sich ändert, wenn die vier Fragen vor dem Produktnamen kommen

Wir sind oft als Feuerlöscher in Projekte geholt worden, die schon in Schieflage waren, und quer durch Branchen wiederholt sich ein Muster: Man hatte sich für ein Tool entschieden, bevor die vier Fragen geklärt waren. Ein anonymisiertes Beispiel: Ein Team hatte den Selbstbau gewählt, aus guten Gründen, weil Datenhoheit unverhandelbar war. Nur hatte niemand die Teamstruktur mitgedacht. Der Stack lief, aber die Retention war nie sauber konfiguriert, die Storage-Kosten liefen davon, und das Alerting war ein Flickenteppich, weil der Betrieb keinen dauerhaften Eigentümer hatte.

Der umgekehrte Fall ist genauso häufig: ein kommerzielles APM gekauft, weil es schnell Ergebnisse verspricht, und dann monatelang kaum genutzt, weil niemand die Instrumentierung sauber aufgesetzt hatte und die Datenhoheitsfrage erst nach dem Kauf hochkam. Zahlen zu den Folgekosten nennen wir bewusst nicht, weil sie sich zwischen Projekten nicht vergleichen lassen. Qualitativ ist der Unterschied klar: Wo die vier Fragen vor dem Produktnamen geklärt werden, fällt die Entscheidung in Tagen und hält Jahre.

Wo diese Kriterien an Grenzen stoßen

Die vier Kriterien liefern eine Richtung, keine Formel. Sie können sich widersprechen: Datenhoheit spricht für Selbstbetrieb, das fehlende Know-how dagegen, und dann muss jemand entscheiden, welches Risiko das Unternehmen eher trägt. Ein hybrides Setup, kritische Daten im eigenen Stack und unkritische Telemetrie im SaaS, löst den Widerspruch oft, verdoppelt aber die Betriebskomplexität.

Die Filterung im Collector schützt nur, was als Attribut ankommt. Personenbezogene Daten, die in Span-Namen oder Log-Zeilen als Freitext stecken, erwischt der Attributes-Processor nicht; dafür braucht es Disziplin bei der Instrumentierung oder einen Processor mit regulären Ausdrücken, der seinerseits Rechenzeit kostet. Und ein Hash ist keine Anonymisierung im rechtlichen Sinn, wenn die Zuordnung an anderer Stelle rekonstruierbar bleibt.

Schließlich wandert die Selbsteinschätzung beim Know-how oft mit den Personen. Das Team, das heute einen Loki-Cluster skalieren kann, ist in zwei Jahren vielleicht ein anderes, und die Entscheidung von heute steht dann auf Sand.

Das Fazit: Betrieb und Datenhoheit entscheiden, nicht das Logo

Ob ein Observability-Stack selbst betrieben oder eingekauft wird, lässt sich nicht abstrakt beantworten und schon gar nicht entlang der alten Frontlinie zwischen Open Source und kommerziell. Es entscheidet sich an Compliance, Datenhoheit, Know-how und Teamstruktur, und diese vier Fragen gehören an den Anfang, nicht ans Ende. Wer sie ehrlich beantwortet, landet fast von selbst beim passenden Stack.

Wir stellen diese vier Fragen in jedem Erstgespräch, bevor ein Produktname fällt. Wer sie überspringt, landet irgendwann bei jemandem wie uns, der das Feuer löscht.