Bildquelle: Pexels / Jakub Zerdzicki / https://www.pexels.com/photo/analyzing-financial-data-on-multiple-screens-36496955/
OpenTelemetry skaliert nur mit sauberer Service-Identität, Ressourcenkontext und abgestuftem Sampling
Viele Teams bekommen OpenTelemetry technisch erstaunlich schnell zum Laufen. Erste Spans erscheinen im Backend, Dashboards wachsen, und im Architekturboard entsteht das gute Gefühl, dass Observability damit im Kern gelöst sei. Genau dort beginnt oft das Missverständnis. Der operative Wert von Tracing entsteht nicht dadurch, dass überhaupt viele Daten ankommen. Er entsteht dann, wenn ein Incident-Team unter Zeitdruck zuverlässig erkennen kann, welcher Service betroffen ist, aus welcher Umgebung die Signale stammen, welche Anfrage wirklich kritisch war und warum genau diese Trace im System geblieben ist. Ohne gemeinsame Service-Identität, saubere Resource-Attribute und eine bewusste Sampling-Strategie kippt OpenTelemetry schnell von Orientierung zu Datenrauschen.
Für Leser ohne tiefen Telemetrie-Hintergrund: OpenTelemetry ist ein offenes Framework für Metriken, Logs und Traces. Es hilft Teams dabei, Beobachtungsdaten aus Anwendungen und Plattformen in einheitlicher Form zu erzeugen und weiterzuleiten. Relevant wird das überall dort, wo Störungen nicht mehr an einem einzelnen Server hängen, sondern über viele Services, Plattformen und Abhängigkeiten laufen. Gerade deshalb reicht es nicht, nur Instrumentierung einzuschalten. Entscheidend ist, ob die Daten später noch betriebstauglich lesbar sind.
Warum die Service-Identität der eigentliche Anfang ist
Die OpenTelemetry-Dokumentation zu Resources beschreibt sie als Beschreibung der Entität, die Telemetrie erzeugt. Das klingt abstrakt, ist im Alltag aber sehr konkret. Sobald zwei Teams denselben Dienst unterschiedlich benennen, unterschiedliche Environment-Werte pflegen oder ein Teil der Spans ohne belastbaren Ressourcenkontext ins Backend läuft, zerfällt die spätere Auswertung. Dann sieht ein Incident Commander zwar Aktivität, aber keine verlässliche gemeinsame Wahrheit.
Besonders wichtig ist dabei das Attribut service.name. In den semantischen Konventionen ist es als Pflichtfeld für Service-Identität fest verankert. Genau diese Eindeutigkeit wird in der Praxis oft unterschätzt. Ein Service darf nicht je nach Sprache, Deployment-Pipeline oder Teamgewohnheit mal als checkout, mal als checkout-service und mal als shop-checkout auftauchen. Solche Varianten wirken harmlos, bis Dashboards, Alert-Regeln, SLO-Auswertungen und Eskalationspfade auf unterschiedlichen Namen basieren. Dann wird jede Ursachenanalyse unnötig langsamer.
Dasselbe gilt für die Umgebung. Wenn deployment.environment.name oder vergleichbarer Ressourcenkontext unklar, unvollständig oder inkonsistent bleibt, vermischen sich Vorfallbilder aus Produktion, Test oder Staging schneller als vielen Teams lieb ist. In ruhigen Zeiten fällt das kaum auf. Unter Eskalationsdruck führt es dagegen zu genau den Fragen, die niemand im Major Incident haben will: Ist dieser Fehler überhaupt aus Produktion, ist die Latenzspitze regional begrenzt, und welche Owner-Gruppe ist jetzt wirklich zuständig?
Semantische Konventionen sind kein Schönheitsprogramm
OpenTelemetry pflegt semantische Konventionen nicht aus pedantischer Normliebe, sondern damit Daten über Sprachen, Frameworks und Plattformen hinweg interpretierbar bleiben. Für den Betrieb heißt das: Wer Telemetrie nur lokal pro Team wachsen lässt, bekommt oft zwar viele Signale, aber keine gemeinsame Sprache. Ein Plattformteam denkt in Service-Namen, ein Entwicklungsteam in Repositorys, das Incident-Board in Business-Funktionen und das SRE-Team in Kubernetes-Workloads. Ohne bewusst gepflegte Abbildung zwischen diesen Ebenen bleiben Traces zwar sichtbar, aber im Störfall nicht führungsfähig.
Genau deshalb lohnt es sich, die Resource- und Naming-Regeln als Governance-Thema zu behandeln. Nicht im Sinne eines schweren Gremiums, sondern als gepflegte Betriebsbasis. Welche Attribute sind für jeden Service Pflicht? Wer gibt neue Namensmuster frei? Wie werden Umbenennungen kontrolliert ausgerollt, damit historische Auswertungen nicht brechen? Und welche Felder müssen in Gateways, Hintergrundjobs, APIs und Worker-Prozessen identisch funktionieren? Diese Fragen wirken unspektakulär. Sie entscheiden aber darüber, ob Observability später zur Abkürzung oder zum zusätzlichen Interpretationsproblem wird.
Sampling ist eine Führungsentscheidung, keine reine Sparmaßnahme
Mindestens ebenso kritisch ist Sampling. Die OpenTelemetry-Grundlagenseiten beschreiben klar den Unterschied zwischen Head Sampling und Tail Sampling. Head Sampling entscheidet früh, also bevor der vollständige Ablauf einer Trace bekannt ist. Tail Sampling trifft die Auswahl später anhand des fertigen Kontexts. Technisch ist das schnell erklärt. Operativ steckt darin eine Grundsatzfrage: Welche Spuren muss das Unternehmen immer sehen, welche nur bei Fehlern, welche abhängig von Kritikalität und welche eher stichprobenartig?
Viele Teams behandeln Sampling zuerst als Kostenhebel. Das ist nicht falsch, aber als alleinige Logik zu kurz. Wer überall dieselbe Rate ansetzt, spart zwar Volumen, verliert aber unter Umständen genau die falschen Traces. Das offizielle OpenTelemetry-Demo zeigt inzwischen sogar ein Beispiel, in dem die Ressourceneigenschaft service.criticality für intelligentes Tail Sampling genutzt wird. Die Idee dahinter ist betriebsnah: geschäftskritische Services dürfen dichter beobachtet werden als Nebenfunktionen, weil Ausfallkosten, Eskalationsrelevanz und Untersuchungsbedarf unterschiedlich hoch sind.
Damit verschiebt sich Sampling aus der Bastelzone in die Betriebssteuerung. Plötzlich geht es nicht mehr nur um Collector-Konfiguration, sondern um Prioritäten. Welche Customer-Facing-Services werden immer vollständig gesammelt? Welche Plattformkomponenten reichen mit reduzierter Quote? Welche Fehlerbilder müssen auch bei geringer Grundrate sicher im Datensatz bleiben? Und welcher Owner verantwortet die Nachschärfung, wenn ein Incident zeigt, dass genau die falschen Traces fehlen? Diese Fragen gehören nicht allein in ein YAML-File, sondern in dieselbe Führungsschicht wie Alerting, Eskalation und SLO-Design.
Was Teams vor der nächsten OTel-Ausweitung festziehen sollten
Wer OpenTelemetry aus Pilotzonen in einen belastbaren Regelbetrieb bringen will, sollte vor dem nächsten Instrumentierungs-Schub drei Dinge sauber festziehen. Erstens braucht jeder produktive Service eine verbindliche Identität mit konsistentem service.name, klaren Umgebungsattributen und nachvollziehbarer Owner-Zuordnung. Zweitens sollten semantische Pflichtfelder dokumentiert und in SDK-, Collector- oder Plattformstandards verankert werden, damit nicht jedes Team seinen eigenen Attribut-Dialekt erfindet. Drittens braucht Sampling eine abgestufte Logik nach Kritikalität, Fehlerbild und Untersuchungswert statt einer pauschalen Einheitsquote.
Erst wenn diese Grundlagen stehen, lohnt sich die nächste Stufe mit schöneren Dashboards, breiteren Rollouts oder feineren Tracing-Analysen wirklich. Sonst vervielfacht OpenTelemetry vor allem Datenvolumen und Auswertungsvarianten. Das Problem zeigt sich dann nicht in der Demo, sondern genau im unpassendsten Moment: wenn mehrere Teams gleichzeitig auf dieselbe Störung schauen und trotzdem keine gemeinsame Erklärung finden.
Unterm Strich ist OpenTelemetry kein Toolprojekt, das mit dem Einsammeln erster Spans erledigt wäre. Es ist eine Betriebsdisziplin. Wer Service-Identität, Ressourcenkontext und Sampling bewusst zusammenführt, bekommt aus Traces echte Entscheidungsunterstützung. Wer diese Basis überspringt, sammelt zwar Beobachtungsdaten, aber im Ernstfall oft zu wenig belastbare Orientierung.
