Die Observability-Signale

Die Observability-Signale

0:00 Am Ende von Modul eins stand eine Liste mit fünf Fragen, die sich heute nicht beantworten lassen. Jetzt geht es darum, welche Art von Daten diese Fragen beantworten kann. OpenTelemetry nennt diese Datenarten Signale, und es sind weniger, als man zunächst vermutet — im Kern drei. Die Kunst besteht nicht darin, alle drei zu sammeln.

0:19 Sie besteht darin, für jede Frage das passende zu wählen, denn jedes Signal hat einen anderen Preis und einen anderen Blickwinkel. Wer das falsche wählt, zahlt doppelt und erfährt trotzdem nichts.

Die Observability-Signale

0:32 Dieses Modul ist das begriffliche Fundament für alles Weitere. Wir schauen uns zuerst die drei tragenden Signale an, danach die ergänzenden — und dabei sehr genau auf den Reifegrad, denn der entscheidet, was Sie heute einplanen dürfen und was noch Beobachtung bleibt. Zum Schluss ordnen wir Ihre fünf Fragen aus Modul eins den Signalen zu. Das ist die Vorlage für die Instrumentierung ab Modul fünf.

Metriken, Traces und Logs

0:55 Fangen wir mit den drei Signalen an, die heute stabil sind und die Produktion tragen. Sie klingen vertraut — Metriken und Logs kennt jeder, Traces zumindest dem Namen nach. Interessant wird es dort, wo sich die drei überschneiden, denn genau dort werden in der Praxis die falschen Entscheidungen getroffen. Schauen wir uns deshalb an, was jedes einzelne tatsächlich leistet.

1:17 Die Definitionen sind bewusst knapp gehalten. Ein Trace ist der Weg einer Anfrage durch die Anwendung. Eine Metrik ist eine zur Laufzeit erfasste Messung. Ein Log ist die Aufzeichnung eines Ereignisses. Und ein Span ist die einzelne Arbeitseinheit innerhalb eines Trace — merken Sie sich diesen Begriff, wir verwenden ihn ab jetzt ständig.

1:36 Stellen Sie sich ein Paket vor, das verschickt wird: Die Metrik sagt Ihnen, wie viele Pakete heute unterwegs waren, der Trace zeigt den Weg eines bestimmten Pakets über alle Stationen, und das Log ist der Vermerk, den eine einzelne Station hinterlassen hat. Diese Schichtung zeigt, wie weit der Blick jeweils reicht. Metriken betrachten viele Vorgänge über die Zeit — sie sind die Vogelperspektive.

1:59 Traces betrachten genau einen Vorgang, aber über alle beteiligten Dienste hinweg. Und Logs betrachten genau ein Ereignis an genau einer Stelle. Je weiter oben, desto mehr Kontext und desto weniger Detail. Der praktische Wert liegt darin, dass Sie sich in dieser Reihenfolge durch eine Störung bewegen: Sie sehen in der Metrik, dass etwas nicht stimmt, finden im Trace, wo es passiert, und lesen im Log, was genau passiert ist.

2:24 Diese Tabelle ist deshalb interessant, weil die Schwächenspalte kein Mangel ist, sondern eine Konsequenz. Eine Metrik verliert den Einzelfall, weil sie aggregiert — das ist genau der Grund, warum sie günstig ist. Ein Trace kann nichts über die Gesamtheit sagen, weil er ein Einzelfall ist. Und ein Log lässt sich schlecht vergleichen, weil es Text ist und keine Zahl.

2:46 Daraus folgt die eigentliche Botschaft: Die Schwäche jedes Signals ist die Stärke eines anderen. Nicht die Auswahl entscheidet über Ihre Analysefähigkeit, sondern die Fähigkeit, zwischen den dreien zu wechseln. Der erste Punkt ist ein Klassiker, dem wir in Modul vierzehn ein eigenes Kapitel widmen: Die Latenz wird als Mittelwert erfasst, und der Mittelwert verdeckt genau die Fälle, die interessant sind.

3:09 Der zweite ist teuer — Logs als Ersatz für Metriken zu zählen, ist technisch möglich und kostet ein Vielfaches. Der dritte ist ärgerlich: Traces liegen vor, aber ohne Attribute lässt sich nicht nach ihnen suchen; wie Sie das vermeiden, klären wir in Modul vier. Und der vierte ist der strukturelle: Jedes Signal landet in einem eigenen Werkzeug, ohne gemeinsame Bezeichner. Dann ist der Wechsel zwischen den Signalen unmöglich.

Ergänzende Signale und Ereignisse

3:34 Neben den drei tragenden Signalen gibt es weitere, über die Sie in Artikeln und auf Konferenzen stolpern werden. Sie sind nützlich zu kennen — aber nicht alle sind schon dafür gedacht, dass man Betriebskonzepte darauf aufbaut. Genau diese Unterscheidung machen wir jetzt, denn sie hat unmittelbare Folgen für Ihre Planung.

3:53 Drei Begriffe, die Sie einordnen sollten. Baggage ist kontextbezogene Information, die zwischen Signalen weitergegeben wird — ein kleiner Rucksack, den die Anfrage mitnimmt. Wie nützlich und wie heikel das ist, sehen wir in Modul sieben. Ein Event ist in OpenTelemetry eine besondere Form des Log Records, also kein eigenes viertes Signal, auch wenn es manchmal so dargestellt wird.

4:16 Und Profiles zeichnen den Ressourcenverbrauch auf Codeebene auf — sie zeigen, wo Rechenzeit und Speicher tatsächlich verbraucht werden. Im September 2026 stehen sie in der öffentlichen Alpha. Reifegrad klingt nach einer Fußnote, ist aber eine handfeste Planungsgröße. Die ersten drei Signale sind auf Spezifikationsebene stabil und tragen Produktion — darauf können Sie bauen. Baggage ist ebenfalls stabil, aber inhaltlich heikel, dazu später mehr.

4:43 Profiles lohnen als Ausblick, nicht als Fundament. Besonders wichtig ist der letzte Punkt, den viele übersehen: Eine stabile Spezifikation heißt nicht, dass jede Sprachimplementierung ebenfalls stabil ist. Das sind zwei verschiedene Aussagen, und es lohnt sich, im Zweifel auf der Statusseite nachzusehen statt zu vermuten.

5:04 Diese vier Felder sind eine Landkarte für die Frage: Worauf darf ich mich heute verlassen? Links oben steht das Fundament — Traces, Metrics und Logs über OTLP. Rechts oben Baggage: technisch stabil, aber mit Vorsicht zu verwenden, weil es über Vertrauensgrenzen wandert. Links unten Profiles, noch in Entwicklung. Und rechts unten das Feld, das in der Praxis am häufigsten übersehen wird: einzelne Instrumentierungen und Collector-Komponenten mit uneinheitlichem Reifegrad.

5:32 Sie können also eine stabile Spezifikation nutzen und trotzdem eine experimentelle Komponente einsetzen, ohne es zu merken. Der erste Punkt ist eine sehr menschliche Falle: Ein Signal wird eingeführt, weil es neu ist, nicht weil eine Frage offen war. Das kostet Betriebsaufwand ohne Gegenwert. Der zweite ist ein echter Verwechslungsfehler — Span Events und eigenständige Logs sehen ähnlich aus, und wer beides erzeugt, verdoppelt das Volumen.

5:59 Der dritte ist der Reifegrad, den wir gerade besprochen haben. Und der vierte deutet auf Modul sieben voraus: Baggage als bequemer Transportweg für Anwendungsdaten. Das funktioniert erstaunlich gut — bis die Daten bei jemandem landen, der sie nicht sehen sollte.

Signalauswahl nach Fragestellung

6:15 Jetzt wird es praktisch. Wir haben die Signale, wir haben aus Modul eins die Fragen — bleibt die Zuordnung. Dafür gibt es eine einfache Regel, die Sie sich für den Rest des Seminars merken können, und ein paar Fälle, in denen sie nicht ausreicht. Genau die sind die interessanten. Die Regel lautet: Wie oft und wie stark fragt nach einer Metrik. Warum in diesem einen Fall fragt nach einem Trace. Was genau passiert ist fragt nach einem Log.

6:41 Damit sind die meisten Fälle abgedeckt. Spannend wird es bei Fragen, die keines der drei allein beantwortet — und davon gibt es mehr, als man denkt. Für die braucht es die Verbindung über gemeinsame Bezeichner. Merken Sie sich diesen Begriff: Die Fähigkeit, von einem Signal zum anderen zu springen, entsteht nicht von selbst.

7:01 Sie wird in Modul vier vorbereitet und in Modul fünfzehn eingelöst. Lesen Sie diese Tabelle von hinten: Die Spalte mit dem Grund erklärt, warum die Zuordnung so ausfällt. Anteile über viele Vorgänge sind ein Aggregat, also eine Metrik. Ein einzelner Weg ist ein Trace. Ein Detail zu einem Ereignis ist ein Log. Besondere Aufmerksamkeit verdient die vierte Zeile: Die Frage nach den betroffenen Filialen sieht harmlos aus, funktioniert aber nur, wenn die Filiale als Attribut mit begrenztem Wertebereich vorliegt.

7:32 Wäre es eine unbegrenzte Kennung, würde genau diese Frage Ihr Metriksystem sprengen. Das ist die Brücke zu Modul zwölf, wo wir über Kardinalität sprechen. Diese vier Punkte sind eine Wirtschaftlichkeitsrechnung. Metriken sind günstig, weil sie aggregieren — und verlieren dabei genau das, was sie günstig macht: den Einzelfall.

7:52 Traces zeigen den Einzelfall und wachsen deshalb mit jeder Anfrage; das ist der Grund, warum wir in Modul zehn über Sampling reden müssen. Logs sind im Speicher teuer und im Vergleich schwach. Und dann der Punkt, der in Budgetdiskussionen fast immer untergeht: Die Verbindung der Signale kostet fast nichts und bringt am meisten.

8:11 Sie besteht im Wesentlichen aus konsequenter Benennung. Sie nehmen jetzt Ihre fünf Fragen aus Modul eins und ordnen jeder ein Signal zu — mit schriftlicher Begründung, denn die Begründung ist der eigentliche Lerneffekt. Eine Faustregel hilft beim Einstieg: Fragen mit „welche" und „wie viele" führen fast immer auf Metriken, Fragen mit „warum" auf Traces.

8:32 Wichtiger als die Zuordnung selbst ist aber der Sonderfall: Suchen Sie die Frage heraus, die sich mit einem einzelnen Signal nicht klären lässt. Für die bestimmen Sie, welche Kombination nötig ist — und genau das ist die anspruchsvolle Stelle. Der erste Punkt ist bequem und deshalb verbreitet: Alles wird als Log erfasst, weil das Framework es ohnehin schreibt. Das Ergebnis ist eine teure Textsammlung.

8:56 Der zweite ist gefährlicher — der Einzelfall wird aus Metriken rekonstruiert, indem man immer feinere Labels hinzufügt. Damit sprengen Sie die Kardinalität, und zwar zuverlässig. Der dritte Punkt ist der stille: Die Kombination bleibt aus, weil Trace-ID und Log nichts Gemeinsames tragen. Und der vierte ist der folgenreichste — die Signalwahl fällt implizit mit der Werkzeugwahl. Dann hat nicht Ihre Frage entschieden, sondern ein Einkaufsprozess.

Übung

9:23 In der Übung machen wir aus der Fragenliste eine Anforderung, mit der sich arbeiten lässt. Das ist der Punkt, an dem aus Nachdenken etwas Konkretes wird: eine Vorlage für die Spans, Metriken und Attribute, die wir ab Modul fünf tatsächlich bauen. Das klingt nach Papierarbeit und ist der Übergang von der Analyse zur Umsetzung: Ab hier wissen Sie, welches Signal Sie erzeugen müssen und welche Attribute daran hängen.

9:46 Ohne diesen Schritt beginnt die Instrumentierung mit einem Bauchgefühl. Zwei Ergebnisse sollen entstehen. Erstens: Zu jeder Frage steht Signal und Begründung fest. Zweitens — und das ist der anspruchsvollere Teil: Für die Frage, die ein Signal allein nicht löst, ist der Verknüpfungspunkt benannt. Ich verrate Ihnen vorab, dass dieser Punkt fast immer eine gemeinsame Kennung ist.

10:09 Merken Sie sich das für Modul vier, denn dort legen wir fest, wie diese Kennungen heißen und wo sie herkommen. Wer diese Übung sauber macht, spart sich später eine ganze Reihe von Umbauten. Der rote Faden ist die Bewegung von der Frage zur technischen Anforderung. Im ersten Schritt wählen Sie das tragende Signal und begründen es — die Begründung zwingt Sie, die Frage noch einmal genau zu lesen.

10:33 Im zweiten prüfen Sie, welche Attribute die Frage überhaupt beantwortbar machen; das ist der Schritt, der in der Praxis fast immer fehlt und später als vermisstes Attribut auffällt. Im dritten suchen Sie den Sonderfall heraus, und im vierten legen Sie fest, über welche Kennung die Signale verbunden werden. Das Ergebnis ist die Arbeitsvorlage für die Instrumentierung.

10:53 Die erste Falle ist die Begründung „das haben wir immer so gemacht" — sie ist keine Begründung, sondern eine Gewohnheit. Die zweite ist der Klassiker: Attribute werden erst beim Auswerten vermisst, weil sie beim Entwerfen niemanden interessiert haben. Die dritte ist subtil — für die Verknüpfung wird eine fachliche Nummer gewählt, etwa eine Bon-Nummer, die aber nicht in allen Diensten vorliegt.

11:16 Nehmen Sie dafür die technische Trace-ID. Und die vierte: Die Liste entsteht, wird aber nie gegen die spätere Instrumentierung geprüft. Genau das tun wir in Modul fünf — dort sehen Sie, wie viel der Agent Ihnen schon abnimmt.