Kein Tool rettet den Überblick, wenn Services überall anders heißen

Observability wird im IT-Betrieb oft als Werkzeugfrage verkauft: neues Dashboard, neuer Collector, neue Traces, bessere Alerts. Der eigentliche Bruch entsteht aber viel früher. Wenn Services in Logs, Metriken, Traces, Tickets und Katalogen unterschiedlich heißen, sieht ein System im Ernstfall nicht wie ein zusammenhängender Service aus, sondern wie ein Stapel technischer Einzelspuren. Für ITSM- und IT-Management-Generalisten ist das der Punkt, an dem Observability vom Spezialistenthema zur Betriebssteuerung wird.

OpenTelemetry ist ein offenes Projekt der Cloud Native Computing Foundation. Es stellt Standards, Werkzeuge und Schnittstellen bereit, um Telemetriedaten wie Metriken, Logs und Traces einheitlicher zu erfassen und weiterzuleiten. Wichtig ist dabei nicht nur, dass Daten gesammelt werden. Entscheidend ist, ob diese Daten später im Incident, im Service Review oder im Kapazitätsgespräch dieselbe Sprache sprechen wie der Betrieb.

Der Service muss zuerst erkennbar sein

Die OpenTelemetry-Dokumentation beschreibt Ressourcen als Entitäten, die Telemetriedaten erzeugen, und nennt service.name als zentrale Service-Identität. Das klingt klein, ist aber betrieblich groß. Wenn derselbe Kundenzugang in einem Trace als frontend, im Log als web-app-prod, im Ticket als „Kundenportal“ und im Servicekatalog als „Digital Access“ geführt wird, entstehen vier Wahrheiten. Im ruhigen Tagesgeschäft fällt das kaum auf. Im Major Incident kostet es Zeit, weil Teams zuerst übersetzen müssen, was eigentlich zusammengehört.

Für ITSM-Prozesse ist diese Namensdisziplin kein kosmetisches Detail. Incident Management braucht eindeutige Zuordnung, Problem Management sucht Muster über mehrere Ereignisse hinweg, Change Enablement bewertet Risiken an konkreten Services und Service Level Management muss erklären können, welche Nutzererfahrung betroffen war. Uneinheitliche Servicenamen zerschneiden genau diese Kette.

Semantische Konventionen sind Betriebsregeln, keine Entwicklerdekoration

OpenTelemetry spricht von Semantic Conventions, also gemeinsamen Regeln für Attribute, Namen und Strukturen. Sie sollen verhindern, dass jedes Team dieselben Dinge anders benennt. Für Entwickler wirkt das zunächst wie ein technischer Standard. Für ITSM ist es eher eine Governance-Frage: Welche Attribute sind Pflicht? Welche Team-, Plattform-, Umgebungs- und Serviceinformationen müssen mitlaufen? Wer entscheidet, wenn ein Service umbenannt wird? Wie wird verhindert, dass neue Templates alte Namensfehler kopieren?

Gerade Plattformteams sollten diese Fragen nicht in einzelnen Repositories verstecken. Wenn Observability über mehrere Produktgruppen, Cloud-Konten oder Dienstleister hinweg funktionieren soll, braucht sie eine gemeinsame Betriebsgrammatik. Dazu gehört ein überschaubarer Satz an Pflichtfeldern, ein klarer Umgang mit Umgebungen wie Produktion, Test und Staging, nachvollziehbare Owner-Informationen und eine Verbindung zum Servicekatalog.

Der Collector löst keine Datenpolitik

Der OpenTelemetry Collector kann Telemetriedaten empfangen, verarbeiten und an unterschiedliche Backends weitergeben. Das ist praktisch, weil Organisationen nicht jede Anwendung direkt an jedes Analysewerkzeug koppeln müssen. Trotzdem ersetzt der Collector keine fachliche Entscheidung darüber, welche Daten nützlich, zulässig und bezahlbar sind. Wer alles ungefiltert einsammelt, produziert nicht automatisch bessere Erkenntnisse. Er produziert oft höhere Kosten, unklare Verantwortlichkeit und Dashboards, die im Incident zu breit statt zu hilfreich sind.

Für den Betrieb ist deshalb eine einfache Frage entscheidend: Welche Telemetriedaten helfen bei welcher Entscheidung? Ein Major Incident braucht andere Signale als ein monatliches Service Review. Ein Compliance-Nachweis braucht andere Aufbewahrung und andere Felder als ein Performance-Tuning. Eine gute Observability-Strategie trennt diese Zwecke, statt jeden Messwert gleich wichtig wirken zu lassen.

Servicekatalog und Telemetrie dürfen nicht getrennt laufen

Viele Organisationen pflegen einen Servicekatalog, während Observability-Daten in einem separaten Werkzeugkosmos entstehen. Genau dort entsteht Reibung. Der Katalog weiß, wer verantwortlich ist, welche Kritikalität gilt und welche Business-Funktion betroffen ist. Die Telemetrie weiß, wo gerade Latenz, Fehler oder ungewöhnliche Last auftreten. Wenn beide Welten nicht über gemeinsame Identitäten verbunden sind, bleibt ausgerechnet im Störungsfall wertvoller Kontext liegen.

Ein sauberer Ansatz beginnt nicht mit einem großen Datenmodell. Praktisch reicht oft ein begrenzter Satz stabiler Zuordnungen: Service-ID, Service-Name, Team oder Owner, Umgebung, Kritikalität und wichtige Abhängigkeiten. Diese Felder müssen in Templates, Deployment-Pipelines und Katalogpflege zusammenpassen. Sonst entsteht ein Portal mit schönen Einträgen und daneben ein Observability-System, das dieselben Services unter anderen Namen sieht.

Provider und SaaS-Dienste gehören in dieselbe Sprache

ITSM-Teams betreiben selten nur eigene Anwendungen. SaaS-Dienste, Cloud-Services, Managed Plattformen und Dienstleister sind Teil der Nutzererfahrung. Genau deshalb reicht es nicht, nur interne Microservices sauber zu instrumentieren. Wenn ein Checkout, ein Identitätsdienst oder ein internes Portal von externen Komponenten abhängt, müssen diese Abhängigkeiten in Telemetrie, Katalog und Incident-Prozess wiedererkennbar sein.

Das bedeutet nicht, dass jeder Provider dieselbe Tiefe liefern kann. Es bedeutet aber, dass die Organisation einheitlich festlegen muss, wie externe Abhängigkeiten benannt, bewertet und in Reviews aufgenommen werden. Sonst werden Provider-Störungen in Dashboards als Randnotiz sichtbar, während Service Owner im Management erklären müssen, warum ein angeblich grüner interner Service für Nutzer trotzdem nicht funktioniert hat.

Der Startpunkt ist ein Namens- und Attribut-Review

Ein realistischer Einstieg ist kein Vollumbau der Observability-Landschaft. Sinnvoller ist ein Review an drei bis fünf kritischen Services. Stimmen die Servicenamen in Telemetrie, CMDB oder Servicekatalog, Tickets, Deployment-Pipelines und Statuskommunikation überein? Gibt es klare Owner? Sind Produktions- und Testsignale sauber unterscheidbar? Tauchen zentrale Abhängigkeiten in Traces oder Logs überhaupt sichtbar auf? Werden Attribute so verwendet, dass ein neues Team sie ohne Spezialwissen verstehen kann?

Aus diesem Review entsteht eine kleine Betriebsnorm: erlaubte Namensmuster, Pflichtattribute, Ausnahmen, Änderungsprozess und Verantwortlichkeit. Diese Norm gehört in Templates, Plattform-Guidelines und Service-Onboarding. Sie sollte auch regelmäßig gegen reale Incidents geprüft werden. Wenn ein Team während einer Störung wieder manuell Begriffe übersetzen musste, ist das ein Hinweis auf fehlende Standardisierung, nicht auf mangelnde Dashboard-Kenntnis.

Observability braucht Eigentum

Der wichtigste Punkt ist Verantwortlichkeit. Observability-Daten entstehen in Entwicklung, Plattform, Betrieb und Security zugleich. Ohne Owner wird daraus ein Werkzeugpark mit guter Absicht und schwacher Steuerung. ITSM kann hier helfen, weil es bereits an Rollen, Services, Changes, Incidents und Reviews denkt. Die Aufgabe besteht nicht darin, jedes technische Detail zu besitzen. Die Aufgabe besteht darin, die gemeinsame Sprache zu sichern, damit technische Signale im Betrieb entscheidbar werden.

Wer Observability so versteht, fragt vor dem nächsten Toolkauf anders: Sind unsere Services eindeutig benannt? Haben Telemetriedaten einen Bezug zum Servicekatalog? Wissen wir, welche Attribute wirklich Pflicht sind? Gibt es Konsequenzen, wenn Teams Standards nicht einhalten? Erst wenn diese Fragen beantwortet sind, wird aus Telemetrie ein belastbares Betriebsinstrument. Sonst bleibt Observability ein teures Suchfenster mit beeindruckenden Kurven und zu wenig gemeinsamer Bedeutung.

Quellen: OpenTelemetry-Dokumentation zu Semantic Conventions, Resources, Collector und Signals; CNCF-Projektseite zu OpenTelemetry.