OpenTelemetry im IT-Betrieb: Fünf Architekturentscheidungen, die Incident und Change spürbar beschleunigen

In vielen IT-Organisationen ist Observability noch immer ein Thema der Plattform- oder Entwicklerteams. Im Tagesgeschäft von Service Management, Betrieb und Major Incident Management kommt davon oft zu wenig an. Tickets verweisen auf Dashboards, Dashboards auf Logs, Logs auf einzelne Container, und am Ende fehlt trotzdem der belastbare Zusammenhang zwischen Anfrage, betroffener Komponente, Deployment und Auswirkung auf den Service. Genau an dieser Stelle wird OpenTelemetry interessant, nicht als neues Tool-Logo, sondern als gemeinsamer technischer Standard für Telemetriedaten.

OpenTelemetry unterstützt mit Traces, Metrics und Logs genau die Signalarten, die im Betriebsalltag gebraucht werden. Besonders relevant für den Incident-Fall sind Traces, weil sie den Weg einer Anfrage durch mehrere Services sichtbar machen. Dazu kommen Resource-Attribute, mit denen sich der Produzent der Telemetrie eindeutig beschreiben lässt, etwa Service-Name, Version, Umgebung, Kubernetes-Kontext oder Host. Das klingt zunächst nach Technikdetail. Praktisch entscheidet es jedoch darüber, ob ein Betriebsteam eine Störung in Minuten eingrenzt oder sich durch widersprüchliche Namen, unklare Umgebungen und lückenhafte Exportpfade arbeitet.

Wer OpenTelemetry im Unternehmen einführt oder bereinigt, sollte deshalb nicht mit der Frage beginnen, welches Backend schöner aussieht. Entscheidend sind fünf Architekturentscheidungen, die später Incident, Change und Ursachenanalyse deutlich einfacher machen.

1. Den Service sauber definieren, bevor die erste Instrumentierung breit ausgerollt wird

Eine der unterschätztesten Schwächen in vielen Observability-Programmen ist Namenschaos. OpenTelemetry weist ausdrücklich darauf hin, dass service.name den logischen Namen des Service repräsentiert und ohne explizite Festlegung sonst schnell bei unknown_service landet. Für den Betrieb ist das fatal. Wenn unterschiedliche Teams dieselbe Anwendung mal als Produktnamen, mal als Repository, mal als Container-Label und mal als Squad-Namen ausgeben, lassen sich Incidents nur schwer sauber korrelieren.

Die saubere Entscheidung lautet daher: Ein Service ist im Observability-Modell eine klar benannte fachlich oder technisch verantwortete Einheit, und dieser Name wird verbindlich in allen Umgebungen durchgezogen. Dazu gehört auch, Regeln für service.version und Namenskonventionen für Hilfsdienste, Batch-Jobs oder Gateways festzulegen. Erst wenn diese Grundlage sitzt, lohnt sich der breite Rollout. Sonst entsteht nur mehr Telemetrie, aber keine bessere Steuerbarkeit.

Für Service Owner ist das kein Schönheitsdetail. Es ist die Voraussetzung dafür, dass ein Incident-Ticket später eindeutig mit einer Service-Verantwortung, einem Deployment und einem Change-Fenster verknüpft werden kann.

2. Resource-Attribute als Betriebsinventar behandeln, nicht als technische Dekoration

OpenTelemetry beschreibt Ressourcen als die Entität, die Telemetrie erzeugt. Im Kubernetes-Betrieb können das etwa Prozessname, Pod, Namespace und Deployment sein. Zusätzlich lassen sich Attribute wie deployment.environment.name setzen. Genau diese Daten sind im Betriebsalltag Gold wert, werden aber oft nur halb gepflegt.

Wer Telemetrie ernsthaft für Incident und Problem Management nutzen will, sollte Resource-Attribute wie ein Mini-Inventar behandeln. Ein Trace ohne saubere Umweltinformationen beantwortet eben nicht die Frage, ob ein Fehler nur in Staging auftritt, nur in einer bestimmten Region oder nur nach einem bestimmten Rollout. Ein Metric ohne konsistente Service- und Umgebungsattribute hilft bei Eskalationen ebenfalls wenig, weil die Daten zwar vorhanden sind, aber nicht belastbar zusammengeführt werden können.

Praxistauglich ist ein Pflichtsatz von Attributen pro Workload-Klasse, zum Beispiel service.name, service.version, deployment.environment.name, Namespace, Cluster-Kontext und gegebenenfalls Cloud- oder Host-Informationen. Das ist keine akademische Übung. Es macht Change-Folgen schneller sichtbar und verbessert auch die Rückfragequalität im Service Desk, weil nicht mehr nur „die API ist langsam“ im Raum steht, sondern ein klar identifizierbarer Betriebsbezug.

3. Den Collector ins Betriebsmodell aufnehmen, statt jede Anwendung direkt irgendwohin exportieren zu lassen

Die OpenTelemetry-Dokumentation empfiehlt in produktiven Umgebungen ausdrücklich den Einsatz eines Collectors neben dem Service, weil dieser zusätzliche Aufgaben wie Retries, Batching, Verschlüsselung oder die Filterung sensibler Daten übernehmen kann. Genau das ist der Punkt, an dem aus Observability-Instrumentierung ein belastbarer Betriebsbaustein wird.

Viele Organisationen lassen Anwendungen direkt in verschiedene Backends senden, historisch gewachsen und je nach Team unterschiedlich. Das erhöht die Kopplung, vervielfacht Konfigurationsfehler und macht Änderungen an Zielsystemen unnötig riskant. Mit einem Collector entsteht dagegen eine steuerbare Schicht zwischen Anwendung und Auswertung. Dort lassen sich Exportpfade standardisieren, sensible Attribute filtern, Sampling-Entscheidungen kontrollieren und neue Ziele ergänzen, ohne jede Applikation erneut anzufassen.

Für den IT-Betrieb ist noch etwas anderes wichtig: Der Collector gehört damit selbst in das Betriebsmodell. Er braucht Verantwortlichkeiten, Konfigurationskontrolle, Monitoring und eine klare Change-Logik. Wer ihn nur als technisches Nebenthema behandelt, verschiebt die Komplexität unsichtbar an eine neue Stelle. Wer ihn bewusst betreibt, gewinnt einen zentralen Hebel für Resilienz und Governance.

4. Vorab festlegen, welche Attribute und Events wirklich betriebsrelevant sind

Traces bestehen nicht nur aus Laufzeiten. Spans können Attribute, Events, Status und Beziehungen enthalten. Die Trace-Dokumentation beschreibt Span Events als strukturierte Punkte in der Zeit und Attribute als Metadaten zum Vorgang. Genau darin liegt Nutzen und Risiko zugleich. Ohne Leitplanken schieben Teams alles Mögliche in die Telemetrie: interne IDs, Freitext, Kundendaten oder Debug-Hinweise, die später niemand verantworten will.

Deshalb sollte jedes Unternehmen vor dem breiten Rollout definieren, welche Metadaten für den Betrieb wirklich gebraucht werden. Beispiele sind HTTP-Route, Zielsystem, Fehlertyp, Queue-Name, Mandantenklasse oder fachlicher Vorgangstyp. Gleichzeitig muss festgelegt werden, was nicht in Spans, Logs oder Events landen darf. Der Collector ist laut Projektdokumentation gerade auch deshalb sinnvoll, weil er sensible Daten filtern kann. Diese Möglichkeit sollte organisatorisch genutzt werden.

Der praktische Gewinn ist enorm. Wenn Attribute standardisiert und begrenzt sind, lassen sich Incident-Timelines, Eskalationspfade und wiederkehrende Fehlermuster viel besser auswerten. Wenn dagegen jeder Dienst seine eigene Telemetrie-Sprache spricht, bleibt die Ursachenanalyse mühsam, selbst bei modernster Plattform.

5. OTLP-Verhalten und Telemetrieverlust als echtes Betriebsrisiko behandeln

Das OTLP-Protokoll wird oft nur als Transportweg betrachtet. Die Spezifikation ist für den Betrieb aber interessanter. Sie beschreibt klare Regeln für Erfolg, Teilerfolg, retrybare und nicht retrybare Fehler. Server können also Daten teilweise akzeptieren, Signale verwerfen oder explizit mitteilen, dass ein Client später erneut senden soll. Genau diese Mechanik entscheidet darüber, wie belastbar Telemetrie unter Last oder in Störungssituationen tatsächlich ist.

Für Betriebsteams folgt daraus eine klare Anforderung: Telemetriepipelines brauchen eigene Überwachung und eigene Schwellwerte. Wenn Spans, Logs oder Metrics wegen Überlastung, Fehlkonfiguration oder Verbindungsproblemen verloren gehen, ist das nicht nur ein Schönheitsfehler im Monitoring. Es verschlechtert direkt die Diagnosefähigkeit im Incident. Besonders kritisch ist das in Phasen hoher Last, wenn die Datenlage ohnehin fragil wird und Teams sich gleichzeitig am stärksten auf Observability verlassen.

Praxistauglich ist deshalb ein kleines Betriebsset an Kennzahlen: Exportfehler, abgewiesene Daten, Warteschlangen im Collector, Konfigurationsänderungen, Zielsystem-Latenz und der Anteil von Services mit funktionsfähiger Kontextpropagierung. Wer diese Sicht nicht aufbaut, merkt Telemetrieverlust oft erst dann, wenn im Major Incident genau die entscheidenden Zusammenhänge fehlen.

Was IT-Betrieb und Service Management in den nächsten 90 Tagen konkret tun sollten

• Service-Namensstandard festziehen: Ein verbindliches Modell für service.name, Versionen und Hilfsdienste definieren.
• Pflichtattribute pro Workload festlegen: Umgebung, Version, Plattform- und Laufzeitkontext nicht optional behandeln.
• Collector-Zielbild beschließen: Klären, wo gesammelt, gefiltert, gepuffert und exportiert wird und wer diese Schicht betreibt.
• Attribut-Governance einführen: Erlaubte, nützliche und verbotene Felder sauber dokumentieren.
• Telemetriepipeline monitoren: Exportfehler und Datenverlust explizit als Betriebskennzahlen führen.

OpenTelemetry entfaltet seinen eigentlichen Wert nicht dann, wenn möglichst viele Services irgendwie instrumentiert sind. Der Nutzen entsteht dann, wenn Telemetrie im Incident-Fall dieselbe Ordnungslogik abbildet wie Verantwortung, Change, Deployment und Betriebsführung. Genau deshalb ist OpenTelemetry heute kein reines Entwicklerwerkzeug mehr, sondern eine Architekturentscheidung für den IT-Betrieb.

Quellen

• OpenTelemetry Docs: Überblick über unterstützte Signale wie Traces, Metrics und Logs
• OpenTelemetry Docs: Traces, Spans, Attribute, Events und Kontextpropagierung
• OpenTelemetry Docs: Ressourcen und die Bedeutung von service.name sowie Umgebungsattributen
• OpenTelemetry Specification: Resource Semantic Conventions für Services, Umgebungen und Plattformkontext
• OpenTelemetry Collector: Gründe für Collector-Einsatz wie Retries, Batching, Verschlüsselung und Datenfilterung
• OTLP Specification: Transport, Teilfehler, Retry-Verhalten und Liefermechanik