Irgendwann in fast jedem Projekt steht die Frage im Raum, ob ein kommerzielles APM oder ein Open-Source-Stack die richtige Wahl ist. Der eine Teil des Teams will das Open-Source-Zeug nehmen, weil es doch kostenlos ist. Ein paar Meetings später will ein anderes Team im selben Unternehmen bloß nichts selbst betreiben und lieber etwas Fertiges kaufen. Beide glauben, sie diskutieren über Open Source gegen kommerziell, dabei diskutieren sie über etwas anderes und merken es nicht.
Ausgangslage: Beide Seiten von innen gesehen
Wir haben die letzten Jahre auf beiden Seiten verbracht. Jahrelang als Subunternehmer rund um AppDynamics, in mehr als dreißig Unternehmen quer durch EMEA, oft wöchentlich am nächsten Standort. In den Projekten danach zunehmend im LGTM-Stack, also Loki, Grafana, Tempo und Mimir, plus OpenTelemetry für die Instrumentierung.
Wir kennen die Hochglanz-Dashboards aus der Anbieter-Demo, und wir kennen das Gefühl, um drei Uhr nachts einen Ingester zu debuggen, der keine Daten mehr annimmt. Aus dieser Doppelrolle heraus ist die Achse „Open Source gegen kommerziell" die falsche. Die eigentliche Frage lautet: selbst betreiben oder bequem einkaufen.
Was ein kommerzielles APM abnimmt und was nicht
Ein kommerzielles APM ist nicht „einfach nur teuer und dafür fertig". Es nimmt den Betrieb des Backends ab, die Skalierung, die Updates, den Support mit Telefonnummer, und bei den großen Anbietern auch einen Agenten, der Java- oder .NET-Anwendungen ohne Konfiguration bis auf Methodenebene sichtbar macht. Es nimmt nicht das Verständnis des eigenen Systems ab.
Wir haben genug Projekte gesehen, in denen das teure Produkt monatelang keinen Mehrwert brachte, weil niemand wusste, welche Fragen es beantworten sollte. Ein Vertrag mit Datadog oder AppDynamics ersetzt keine Bestandsaufnahme, keine Priorisierung und keine Naming-Konvention. Und er beantwortet nicht die Frage, wo die Daten liegen und wer darauf zugreifen kann; die gehört an den Anfang der Architektur, nicht in ein Review drei Monate vor dem Go-Live.
Was an einem selbst betriebenen Stack kostenlos ist
Die Entscheidung „kostenlos" ist eine Geschichte, die sich viele Teams selbst erzählen. Grafana kostet keine Lizenz. Der Betrieb kostet Menschen. Der Ingester, der nachts umkippt, kostet Menschen. Die Retention-Policy, die niemand konfiguriert hat, kostet irgendwann eine überraschende Storage-Rechnung, nur eben nicht beim Anbieter, sondern in der eigenen Cloud.
Kostenlos ist an dem Stack die Software, sonst nichts. Ein selbst betriebener LGTM-Stack braucht Leute, die das Prometheus-Datenmodell verstehen, die wissen, warum Cardinality ein Problem ist, also die Zahl unterscheidbarer Zeitreihen, die Speicher und Abfragezeit treibt, und die einen Loki-Cluster skalieren können. Mit zwei solchen Leuten im Team ist das machbar. Mit einem Team, das primär Produktfeatures liefern soll, entsteht ein zweiter Vollzeitjob, den keiner wollte.
Betrieb heißt beim LGTM-Stack konkret: Upgrades von vier Komponenten, Retention und Compaction im Objektspeicher, Kapazitätsplanung für Ingester und Querier, Bereitschaft für den Fall, dass die Ingestion stockt, und ein Monitoring für das Monitoring selbst. Wer das nicht einplant, hat nicht gespart, sondern die Rechnung nur verschoben.
Woran wir die Betriebsentscheidung festmachen
Fragt uns ein Kunde, was er nehmen soll, geben wir keine Produktempfehlung ab, bevor vier Dinge geklärt sind. Erstens Team und Know-how: wer den Stack in zwei Jahren betreibt, nicht wer ihn heute begeistert aufbaut. Zweitens Compliance und Datenhoheit, dazu gleich mehr, weil das oft das entscheidende Kriterium ist.
Drittens die Kritikalität des Systems. Bei einem internen Werkzeug kann man experimentieren; bei einem Zahlungssystem mit 24/7-SLA will man Support, den man anrufen kann, und keinen GitHub-Issue, der seit acht Monaten offen ist. Viertens die Teamstruktur: Bei fünfzehn Teams wird das Betriebsmodell wichtiger als das Werkzeug, weil jemand Standards durchsetzen und vergleichbare Instrumentierung sicherstellen muss.
Was in dieser Liste bewusst fehlt, ist der Preis als erstes Kriterium. Er kommt zuletzt, und er sieht selten so aus, wie er in der ersten Rechnung steht. Die Lizenz eines kommerziellen Produkts ist eine Zeile im Angebot; die Personalkosten für den Selbstbetrieb verteilen sich auf drei Kostenstellen und tauchen in keinem Vergleich auf, bis jemand sie zusammenrechnet.
Datenhoheit beendet die Diskussion oft, bevor Features zählen
Bei einem Kunden im regulierten Umfeld mit europäischen Daten wurde wochenlang über Features geredet: welches Produkt Traces besser korreliert, wer die schönere Oberfläche für verteiltes Tracing hat. Als die Frage aufkam, wo die Telemetriedaten physisch liegen und wer theoretisch Zugriff hat, war eine ganze Reihe von SaaS-Angeboten mit einem Schlag raus.
Observability-Daten sind nicht harmlos. In Traces stecken URLs, teils Parameter, teils Identifikatoren; in Logs steckt bei schlechter Disziplin auch mal ein Token oder eine Mailadresse. Wer das in eine SaaS außerhalb der EU kippt, trifft eine Datenschutzentscheidung, ob er will oder nicht. Genau hier kippt die Balance in der Praxis oft Richtung Selbstbetrieb, nicht aus Ideologie, sondern weil „im eigenen Rechenzentrum" bei manchen Kunden nicht verhandelbar ist.
Die Filterung im Collector, die dieses Risiko begrenzt, beschreiben wir im Artikel zur Bauen-oder-kaufen-Entscheidung dieser Serie; hier genügt die Feststellung, dass sie unabhängig vom Backend funktioniert und deshalb keine der beiden Optionen ausschließt.
OpenTelemetry macht die Backend-Entscheidung umkehrbar
In den meisten Diskussionen wird OpenTelemetry als „das Open-Source-Ding" einsortiert, als gehöre es ins Grafana-Lager. Das ist ein Denkfehler. OpenTelemetry ist kein Lager, sondern der Standard, der die Lagermauer einreißt: Die Anwendung wird einmal instrumentiert und weiß nicht, wohin die Daten am Ende gehen. Das entscheidet der Collector per Konfiguration.
Wie umkehrbar das ist, zeigt eine Collector-Konfiguration, die dieselben Traces parallel an ein selbst betriebenes Tempo und an einen kommerziellen Anbieter schickt. So lässt sich ein Produkt wochenlang mit echten Daten bewerten, ohne den eigenen Stack abzuschalten, und der Rückweg ist eine gelöschte Zeile. Die Konfiguration gilt für den OpenTelemetry Collector 0.128 und Grafana Tempo 2.8:
receivers:
otlp:
protocols:
grpc:
endpoint: ${env:MY_POD_IP}:4317
processors:
batch: {}
exporters:
otlp/tempo:
endpoint: tempo-distributor.observability:4317
tls:
insecure: true
otlphttp/anbieter:
endpoint: https://<OTLP-ENDPUNKT-DES-ANBIETERS>
headers:
Authorization: "Bearer <API-TOKEN>"
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/tempo, otlphttp/anbieter]Der OTLP/HTTP-Exporter braucht nur die Basis-URL des Anbieters; der Header mit dem Zugangstoken kommt aus den gemeinsamen HTTP-Client-Einstellungen des Collectors. Der Receiver bindet auf die Pod-IP aus der Umgebungsvariable MY_POD_IP, so wie es das offizielle Helm-Chart des Collectors vorgibt. Eine Pipeline darf an mehrere Exporter liefern, jeder bekommt dieselben Daten. Fällt die Entscheidung für den Anbieter, verschwindet otlp/tempo aus der Liste; fällt sie dagegen, verschwindet otlphttp/anbieter. Der Anwendungscode bleibt in beiden Fällen unangetastet.
Was sich ändert, wenn die Instrumentierung neutral bleibt
Wir haben Kunden mit proprietären Agenten gesehen, tief im Code, in jeder Klasse verdrahtet. Ein Produktwechsel hieß dort: alles neu instrumentieren, über Monate. Mit OpenTelemetry als Instrumentierungsschicht ist die Entscheidung für ein Backend reversibel geworden: klein anfangen, später umentscheiden, sogar zwei Backends parallel bespielen, etwa Metriken günstig selbst halten und Traces bei einem Anbieter, der die Oberfläche besser kann.
Zahlen zum Aufwand eines Wechsels nennen wir nicht, weil sie von der Codebasis abhängen und sich nicht übertragen lassen. Qualitativ ist die Trennung eindeutig: Sie macht aus einer Glaubensfrage eine nüchterne Betriebsentscheidung, die sich revidieren lässt, wenn sich Team, Budget oder Aufsicht ändern. Der parallele Export macht aus der Produktbewertung einen Testlauf mit den eigenen Daten statt einer Folienpräsentation, und der Rückbau ist eine Zeile in der Collector-Konfiguration.
Wo OpenTelemetry noch an Grenzen stößt
OpenTelemetry ist an manchen Stellen noch rau. Die automatische Instrumentierung ist je nach Sprache unterschiedlich reif, die Konfiguration des Collectors kann kleinteilig werden, und ein hochoptimierter kommerzieller Agent liefert bei bestimmten Sprachen und Frameworks noch tiefere Einblicke ohne Konfigurationsaufwand. Wer maximale Automatik will, ist mit einem fertigen Agenten teils schneller am Ziel. Das ist ein Reifegradthema, das jedes Jahr kleiner wird, aber heute noch real ist.
Der parallele Export verdoppelt außerdem den Netzwerkverkehr und die Batch-Puffer im Collector, und er setzt voraus, dass der Anbieter OTLP nativ annimmt. Anbieter mit eigenem Ingest-Format brauchen einen spezifischen Exporter aus der Contrib-Distribution, der nicht jede Semantik eins zu eins abbildet. Auch Sampling-Entscheidungen müssen für beide Ziele gleich gelten, sonst vergleicht man zwei verschiedene Datenmengen. Und die Umkehrbarkeit gilt für die Daten, nicht für die Arbeit darauf: Dashboards, Alarmregeln und Gewohnheiten der Teams wandern beim Backend-Wechsel nicht automatisch mit.
Das Fazit: Die Frage heißt betreiben oder einkaufen
Selbst betreiben oder einkaufen ist die Frage, an der wirklich etwas hängt: Kosten, Verantwortung, Datenhoheit, Nachtschichten. „Kommerzielles APM oder Open-Source-Stack" ist nur die Verpackung, in der diese Frage meistens ankommt. Wer mit OpenTelemetry instrumentiert, trennt die Erzeugung der Daten von ihrer Verarbeitung und kann die Verpackung später wechseln.
Wir haben auf beiden Seiten gute Projekte gesehen und auf beiden Seiten Totalschäden; der Unterschied lag nie am Logo auf dem Dashboard, sondern an der ehrlichen Einschätzung des Betriebsmodells. Genau diese Einschätzung erarbeiten wir mit Kunden, bevor ein Produktname fällt.