OpenTelemetry lernen

Kapitel 1. Der Stand der modernen Beobachtbarkeit

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Geschichte ist nicht die Vergangenheit, sondern eine Karte der Vergangenheit, die aus einem bestimmten Blickwinkel gezeichnet wurde, um dem modernen Reisenden nützlich zu sein.

Henry Glassie, US-Historiker¹

In diesem Buch geht es um die schwierigen Probleme, die mit großen verteilten Computersystemen verbunden sind, und darum, wie OpenTelemetry zur Lösung dieser Probleme beitragen kann.

Die moderne Softwareentwicklung ist besessen von der Erfahrung der Endnutzer, und die Endnutzer verlangen eine blitzschnelle Leistung. Umfragen zeigen, dass Nutzer/innen E-Commerce-Websites, die länger als zwei Sekunden zum Laden brauchen, abbrechen. Du hast wahrscheinlich schon viel Zeit damit verbracht, die Leistung deiner Anwendung zu optimieren und zu debuggen, und wenn es dir wie uns geht, bist du frustriert darüber, wie unelegant und ineffizient dieser Prozess sein kann. Entweder gibt es nicht genug Daten oder zu viele, und die Daten, die es gibt, können voller Ungereimtheiten oder unklarer Messungen sein.

Die Ingenieure müssen auch strenge Anforderungen an die Betriebszeit erfüllen. Das bedeutet, dass Probleme erkannt und behoben werden müssen, bevor sie zu einer Kernschmelze führen, und nicht erst, wenn das System fehlschlägt. Und es bedeutet, schnell von der Triage zur Entschärfung überzugehen. Um das zu erreichen, brauchst du Daten.

Aber du brauchst nicht nur irgendwelche Daten; du brauchst korrelierte Daten - Daten, die bereits organisiert sind und von einem Computersystem analysiert werden können. Wie du sehen wirst, waren Daten mit einem solchen Organisationsgrad bisher nicht ohne weiteres verfügbar. Da die Systeme immer größer und heterogener geworden sind, ist es sogar noch schwieriger geworden, die Daten zu finden, die du für die Analyse eines Problems brauchst. Was früher wie die Suche nach der Nadel im Heuhaufen war, ist heute eher die Suche nach der Nadel im Nadelhaufen.

OpenTelemetry löst dieses Problem. Indem OpenTelemetry einzelne Logs, Metriken und Traces in ein kohärentes, einheitliches Informationsdiagramm umwandelt, schafft OpenTelemetry die Grundlage für die nächste Generation von Observability-Tools. Und da die Softwarebranche OpenTelemetry bereits auf breiter Front einsetzt, wird diese nächste Generation von Tools gerade entwickelt, während wir diese Zeilen schreiben.

The Times They Are A-Changin'

Technologie kommt in Wellen. Während wir dies im Jahr 2024 schreiben, erlebt der Bereich der Beobachtbarkeit seinen ersten richtigen Tsunami seit mindestens 30 Jahren. Du hast dir einen guten Zeitpunkt ausgesucht, um dieses Buch in die Hand zu nehmen und eine neue Perspektive zu gewinnen!

Das Aufkommen von Cloud Computing und nativen Cloud-Anwendungssystemen hat zu seismischen Verschiebungen in der Praxis der Entwicklung und des Betriebs komplexer Software-Systeme geführt. Was sich jedoch nicht geändert hat, ist, dass Software auf Computern läuft, und du musst verstehen, was diese Computer tun, um deine Software zu verstehen. So sehr die Cloud auch versucht hat, die grundlegenden Einheiten der Datenverarbeitung zu abstrahieren, unsere Einsen und Nullen verwenden immer noch Bits und Bytes.

Egal, ob du ein Programm auf einem multiregionalen Kubernetes-Cluster oder einem Laptop ausführst, du wirst dir die gleichen Fragen stellen:

• "Warum ist es so langsam?"
• "Was verbraucht so viel Arbeitsspeicher?"
• "Wann hat das Problem angefangen?"
• "Wo ist die Ursache dafür?"
• "Wie bringe ich das in Ordnung?"

Der Astronom und Wissenschaftskommunikator Carl Sagan sagte: "Man muss die Vergangenheit kennen, um die Gegenwart zu verstehen."² Das trifft hier auf jeden Fall zu: Um zu verstehen, warum ein neuer Ansatz zur Beobachtbarkeit so wichtig ist, musst du zunächst die traditionelle Beobachtbarkeitsarchitektur und ihre Grenzen kennen.

Das mag wie eine Zusammenfassung von rudimentären Informationen aussehen! Aber das Chaos um die Beobachtbarkeit gibt es schon so lange, dass die meisten von uns einen ganzen Haufen Vorurteile entwickelt haben. Auch wenn du ein Experte bist - vor allem, wenn du ein Experte bist - ist es wichtig, eine neue Perspektive einzunehmen. Beginnen wir diese Reise mit der Definition einiger Schlüsselbegriffe, die wir in diesem Buch verwenden werden.

Beobachtbarkeit: Wichtige Begriffe zum Kennenlernen

Zunächst einmal, was ist Beobachtbarkeit beobachten? Für die Zwecke dieses Buches beobachten wir verteilte Systeme. Ein verteiltes System ist ein System, dessen Komponenten sich auf verschiedenen vernetzten Computern befinden, die miteinander kommunizieren und ihre Aktionen koordinieren, indem sie sich gegenseitig Nachrichten übermitteln.³ Es gibt viele Arten von Computersystemen, aber das sind die, auf die wir uns konzentrieren.

Was gilt als verteilt?

Verteilte Systeme sind nicht nur Anwendungen, die in der Cloud laufen, Microservices oder Kubernetes-Anwendungen. Makroservices oder "Monolithen", die eine serviceorientierte Architektur nutzen, Client-Anwendungen, die mit einem Backend kommunizieren, sowie mobile und Web-Anwendungen sind alle in gewisser Weise verteilt und profitieren von der Beobachtbarkeit.

Auf der höchsten Ebene besteht ein verteiltes System aus Ressourcen und Transaktionen:

Ressourcen

Diese sind alle physischen und logischen Komponenten, aus denen ein System besteht. Physische Komponenten wie Server, Container, Prozesse, Arbeitsspeicher, CPU und Netzwerkkarten sind alle Ressourcen. Logische Komponenten wie Clients, Anwendungen, API-Endpunkte, Datenbanken und Lastverteiler sind ebenfalls Ressourcen. Kurz gesagt: Ressourcen sind alles, woraus das System tatsächlich besteht.

Transaktionen

Dabei handelt es sich um Anfragen, die die Ressourcen, die das System benötigt, um im Auftrag des Nutzers zu arbeiten, orchestrieren und nutzen. Normalerweise wird eine Transaktion von einem echten Menschen ausgelöst, der darauf wartet, dass die Aufgabe erledigt wird. Beispiele für Transaktionen sind das Buchen eines Fluges, das Anfordern einer Mitfahrgelegenheit oder das Laden einer Webseite.

Wie können wir diese verteilten Systeme beobachten? Das können wir nicht, es sei denn, sie senden Telemetrie aus. Telemetrie ist Daten, die beschreiben, was dein System tut. Ohne Telemetrie ist dein System nur eine große Blackbox voller Geheimnisse.

Viele Entwickler finden das Wort Telemetrie verwirrend. Es ist ein überladener Begriff. Wir unterscheiden in diesem Buch und bei der Systemüberwachung im Allgemeinen zwischen Benutzertelemetrie und Leistungstelemetrie:

Benutzertelemetrie

Bezieht sich auf auf Daten darüber, wie ein Nutzer über einen Client mit einem System interagiert: Schaltflächenklicks, Sitzungsdauer, Informationen über den Host-Rechner des Clients und so weiter. Du kannst diese Daten nutzen, um zu verstehen, wie Nutzer mit einer E-Commerce-Website interagieren, oder um die Verteilung der Browserversionen beim Zugriff auf eine webbasierte Anwendung zu ermitteln.

Leistungstelemetrie

wird nicht in erster Linie zur Analyse des Nutzerverhaltens verwendet, sondern liefert den Betreibern statistische Informationen über das Verhalten und die Leistung der Systemkomponenten. Leistungsdaten können in einem verteilten System aus verschiedenen Quellen stammen und bieten Entwicklern einen "Brotkrumenpfad", dem sie folgen können, um Ursache und Wirkung zu verbinden.

Einfacher ausgedrückt, sagt dir die Nutzertelemetrie, wie lange jemand mit dem Mauszeiger über die Schaltfläche "Kasse" in einer E-Commerce-Anwendung gefahren ist. Die Leistungstelemetrie sagt dir, wie lange es gedauert hat, bis die Schaltfläche "Kasse" überhaupt geladen wurde und welche Programme und Ressourcen das System dabei verbraucht hat.

Hinter der Benutzer- und Leistungstelemetrie verbergen sich verschiedene Arten von Signalen. Ein Signal ist eine bestimmte Form der Telemetrie. Ereignisprotokolle sind eine Art von Signal. Systemmetriken sind eine andere Art von Signal. Kontinuierliche Profilerstellung ist eine andere. Diese Signalarten dienen jeweils einem anderen Zweck und sind nicht wirklich austauschbar. Du kannst nicht alle Ereignisse, die eine Benutzerinteraktion ausmachen, allein aus den Systemmetriken ableiten, und du kannst die Systemauslastung nicht allein aus den Transaktionsprotokollen ableiten. Du brauchst mehrere Arten von Signalen, um dein System als Ganzes zu verstehen.

Jedes Signal besteht aus zwei Teilen: der Instrumentierung - dem Code, der Telemetriedaten sendet - in den Programmen selbst und einem Übertragungssystem , das die Daten über das Netzwerk an ein Analysetool sendet, wo die eigentliche Beobachtung stattfindet.

Dabei gibt es eine wichtige Unterscheidung: Häufig werden Telemetrie und Analyse miteinander vermischt, aber es ist wichtig zu verstehen, dass das System, das die Daten sendet, und das System, das die Daten analysiert, voneinander getrennt sind. Telemetrie sind die Daten selbst. Die Analyse ist das, was du mit den Daten machst.

Schließlich ergibt Telemetrie plus eine Analyse die Beobachtbarkeit. In diesem Buch geht es darum zu verstehen, wie man diese beiden Teile am besten zu einem nützlichen Beobachtungssystem kombiniert .

Beobachtbarkeit ist eine Praxis

Beobachtbarkeit hört nicht bei der Telemetrie und Analyse auf, sondern ist eine organisatorische Praxis, ähnlich wie DevOps. In vielerlei Hinsicht ist Beobachtbarkeit die Grundlage moderner Softwareentwicklungspraktiken - sie untermauert alles, was wir tun, von kontinuierlicher Integration und Bereitstellung bis hin zu Chaos Engineering, Entwicklerproduktivität und mehr. Die Quellen der Beobachtbarkeit sind so vielfältig wie deine Teams und deine Software, und diese Daten können gesammelt, analysiert und zur kontinuierlichen Verbesserung deines gesamten Unternehmens genutzt werden. Wir hoffen, dass du mit diesem Buch das nötige Grundwissen mitnimmst, um in deinem Unternehmen eine Observability-Praxis zu etablieren, die auf OpenTelemetry aufbaut!

Eine kurze Geschichte der Telemetrie

Wissenswertes: wird Telemetrie genannt, weil die ersten Ferndiagnosesysteme Daten über Telegrafenleitungen übertrugen. Viele denken bei dem Begriff Telemetrie an Raketen und die Luft- und Raumfahrt der 1950er Jahre, aber wenn die Praxis dort ihren Anfang genommen hätte, hieße sie Radiometrie. Tatsächlich wurde die Telemetrie zuerst entwickelt, um Kraftwerke und öffentliche Stromnetze zu überwachen - frühe, aber wichtige verteilte Systeme!

Die Computertelemetrie kam natürlich erst später. Die Geschichte der Benutzer- und Leistungstelemetrie hängt mit den Veränderungen im Softwarebetrieb und der ständig wachsenden Rechenleistung und Netzwerkbandbreite zusammen, die diese Trends seit langem vorantreiben. Zu verstehen, wie Computer-Telemetriesignale entstanden sind und wie sie sich entwickelt haben, ist wichtig, um ihre aktuellen Grenzen zu verstehen.

Die erste und beständigste Form der Telemetrie war das logging. Logs sind textbasierte Meldungen, die den Zustand eines Systems oder Dienstes beschreiben und für den menschlichen Gebrauch bestimmt sind. Im Laufe der Zeit verbesserten Entwickler und Betreiber die Speicherung und Suche in diesen Protokollen, indem sie spezielle Datenbanken erstellten, die eine Volltextsuche ermöglichten.

Die Protokollierung gab zwar Aufschluss über einzelne Ereignisse und Momente innerhalb eines Systems, aber um zu verstehen, wie sich das System im Laufe der Zeit verändert, waren mehr Daten erforderlich. Ein Log kann dir zwar sagen, dass eine Datei nicht geschrieben werden kann, weil der Speicherplatz knapp ist, aber wäre es nicht toll, wenn du die verfügbare Speicherkapazität verfolgen und eine Änderung vornehmen könntest , bevor der Platz knapp wird?

Metriken sind kompakte statistische Darstellungen des Systemzustands und der Ressourcenauslastung. Sie waren perfekt für diese Aufgabe. Durch das Hinzufügen von Metriken war es möglich, neben Fehlern und Ausnahmen auch Warnmeldungen zu den Daten zu erstellen.

Als das moderne Internet an Fahrt aufnahm, wurden die Systeme immer komplexer und die Leistung immer wichtiger. Eine dritte Form der Telemetrie wurde hinzugefügt: das verteilte Tracing. Da die Transaktionen immer mehr Vorgänge und immer mehr Maschinen umfassten, wurde es immer wichtiger, die Ursache eines Problems zu lokalisieren. Anstatt nur einzelne Ereignisse - Logs - zu untersuchen, betrachteten Tracing-Systeme ganze Vorgänge und wie sie sich zu Transaktionen zusammenfügen. Vorgänge haben eine Startzeit und eine Endzeit. Sie haben auch einen Ort: Auf welcher Maschine fand ein bestimmter Vorgang statt? So konnte die Quelle der Latenz auf einen bestimmten Vorgang oder eine Maschine eingegrenzt werden. Aufgrund von Ressourcenbeschränkungen neigten Tracing-Systeme jedoch dazu, nur einen kleinen Teil der Gesamtzahl der Transaktionen aufzuzeichnen, was ihren Nutzen über grundlegende Leistungsanalysen hinaus einschränkte.

Die drei Browser-Registerkarten der Beobachtbarkeit

gibt es zwar auch andere nützliche Formen der Telemetrie, aber die Vorrangstellung dieser drei Systeme - Logs, Metriken und Tracing - führte zu dem Konzept, das heute als die "drei Säulen der Beobachtbarkeit" bekannt ist.⁴ Die drei Säulen sind ein guter Weg, um zu beschreiben, wie wir derzeit Beobachtbarkeit praktizieren - aber sie sind eigentlich ein schlechter Weg, um ein Telemetriesystem zu entwickeln!

Traditionell wurde jede Form der Beobachtung - Telemetrie und Analyse - als völlig separates, isoliertes System aufgebaut, wie in Abbildung 1-1 beschrieben.

Abbildung 1-1. Eine Säule der Beobachtbarkeit

Ein Logging-System besteht aus Logging-Instrumenten, einem Log-Übertragungssystem und einem Log-Analyse-Tool. Ein Metrik-System besteht aus einem Metrik-Instrumentarium, einem Metrik-Übertragungssystem und einem Metrik-Analyse-Tool. Das Gleiche gilt für das Tracing - daher die drei Säulen in Abbildung 1-2.

Abbildung 1-2. Die drei Säulen der Beobachtbarkeit

Das ist grundlegende vertikale Integration: Jedes System wird für einen bestimmten Zweck gebaut, von Anfang bis Ende. Es macht Sinn, dass die Beobachtungsfähigkeit auf diese Weise aufgebaut wurde - sie hat sich im Laufe der Zeit entwickelt, und jedes Teil wurde hinzugefügt, wenn es gebraucht wurde. Mit anderen Worten: Die Beobachtbarkeit ist aus keinem besseren Grund als einem historischen Zufall so strukturiert. Die einfachste Art, ein Protokollierungssystem oder ein Kennzahlensystem zu implementieren, ist, es isoliert als eigenständiges System zu betreiben.

Der Begriff "drei Säulen" erklärt zwar die Art und Weise, wie die traditionelle Beobachtbarkeit aufgebaut ist, aber er ist auch problematisch - er lässt diese Architektur wie eine gute Idee klingen! Das ist sie aber nicht. Es ist zwar frech, aber ich bevorzuge eine andere Formulierung - die "drei Browser-Tabs der Beobachtbarkeit". Denn das ist es, was du tatsächlich bekommst.

Auftretende Komplikationen

Das Problem ist, dass unsere Systeme nicht aus Logging- oder Metrikproblemen bestehen. Sie bestehen aus Transaktionen und Ressourcen. Wenn ein Problem auftritt, sind das die einzigen beiden Dinge, die wir ändern können: Entwickler können ändern, was die Transaktionen tun, und Betreiber können ändern, welche Ressourcen verfügbar sind. Das war's.

Aber der Teufel steckt im Detail. Es ist möglich, dass ein einfacher, isolierter Fehler auf eine einzige Transaktion beschränkt ist. Die meisten Probleme in der Produktion entstehen jedoch durch die Art und Weise, wie viele gleichzeitige Transaktionen zusammenwirken.

Ein großer Teil der Beobachtung realer Systeme besteht darin, Muster schlechten Verhaltens zu erkennen und dann zu extrapolieren, um herauszufinden, wie bestimmte Muster von Transaktionen und Ressourcenverbrauch diese Muster verursachen. Das ist wirklich schwer zu machen! Es ist sehr schwer vorherzusagen, wie sich Transaktionen und Ressourcen in der realen Welt verhalten werden. Tests und kleine Einsätze sind für diese Aufgabe nicht immer hilfreich, denn die Probleme, die du zu lösen versuchst, treten außerhalb der Produktion nicht auf. Diese Probleme sind auftauchende Nebeneffekte, die sich aus der Art und Weise ergeben, wie die physische Realität deines Produktionseinsatzes mit den echten Nutzern des Systems interagiert.

Das ist eine Zwickmühle! Es liegt auf der Hand, dass deine Fähigkeit, diese Probleme zu lösen, von der Qualität der Telemetrie abhängt, die dein System in der Produktion aussendet.

Die drei Säulen waren ein Unfall

Du kannst auf jeden Fall Metriken, Logs und Traces verwenden, um dein System zu verstehen. Logs und Traces helfen dir, die Ereignisse zu rekonstruieren, die eine Transaktion ausmachen, während Metriken dir helfen, die Ressourcennutzung und -verfügbarkeit zu verstehen.

Aber nützliche Beobachtungen ergeben sich nicht aus der isolierten Betrachtung von Daten. Du kannst nicht nur einen einzigen Datenpunkt oder sogar nur einen Datentyp betrachten, um etwas über das aufkommende Verhalten zu erfahren. Du wirst fast nie die Ursache eines Problems finden, wenn du dir nur die Logs oder Metriken ansiehst. Die Hinweise, die uns zu Antworten führen, ergeben sich aus der Suche nach Korrelationen zwischen diesen verschiedenen Datenströmen. Wenn du also ein Problem untersuchst, schwenkst du zwischen Logs und Metriken hin und her und suchst nach Korrelationen.

Das ist das Hauptproblem des traditionellen Drei-Säulen-Ansatzes: Diese Signale werden alle in separaten Datensilos gespeichert. Das macht es unmöglich, automatisch Korrelationen zwischen sich verändernden Mustern in unseren Transaktionsprotokollen und veränderten Mustern in unseren Kennzahlen zu erkennen. Stattdessen hast du am Ende drei verschiedene Browser-Tabs, die jeweils nur einen Teil der benötigten Daten enthalten.

Vertikale Integration macht die Sache noch schlimmer: Wenn du Korrelationen zwischen Metriken, Logs und Traces erkennen willst, müssen diese Verbindungen in den Telemetriedaten deiner Systeme vorhanden sein. Ohne einheitliche Telemetrie würden dir selbst dann, wenn du diese separaten Signale in derselben Datenbank speichern könntest, wichtige Identifikatoren fehlen, die Korrelationen zuverlässig und konsistent machen. Die drei Säulen sind also eigentlich ein schlechtes Design! Was wir brauchen, ist ein integriertes System.

Ein einziges Geflecht aus Daten

Wie triagierst du deine Systeme, wenn du ein Problem festgestellt hast? Indem du Korrelationen findest. Wie findest du Zusammenhänge? Es gibt zwei Möglichkeiten - mit Menschen und mit Computern:

Menschliche Untersuchung

Die Operatoren gehen alle verfügbaren Daten durch und erstellen ein mentales Modell des aktuellen Systems. Dann versuchen sie in ihrem Kopf herauszufinden, wie alle Teile heimlich miteinander verbunden sein könnten. Dieser Ansatz ist nicht nur geistig anstrengend, sondern unterliegt auch den Grenzen des menschlichen Gedächtnisses. Denk mal darüber nach: Sie suchen buchstäblich nach Zusammenhängen, indem sie ihre Augen benutzen, um auf verschnörkelte Linien zu schauen. Außerdem leidet die menschliche Recherche, wenn die Organisationen größer und die Systeme komplexer werden. Etwas, das du in einer verschnörkelten Linie siehst, in eine verwertbare Erkenntnis umzuwandeln, wird schwieriger, wenn das erforderliche Wissen über die ganze Welt verteilt ist.

Computer Untersuchung

Die zweite Möglichkeit, Korrelationen zu finden, ist der Einsatz von Computern. Computer sind vielleicht nicht gut darin, Hypothesen aufzustellen und Ursachen zu finden, aber sie sind sehr gut darin, Korrelationen zu erkennen. Das ist einfach statistische Mathematik.

Aber auch hier gibt es einen Haken: Computer können nur zwischen zusammenhängenden Daten Korrelationen finden. Und wenn deine Telemetriedaten isoliert, unstrukturiert und uneinheitlich sind, können Computer dir nur sehr begrenzt helfen. Aus diesem Grund suchen menschliche Bediener immer noch mit ihren Augen nach Kennzahlen und versuchen gleichzeitig, sich jede Zeile in jeder Konfigurationsdatei zu merken.

Anstelle von drei einzelnen Säulen sollten wir eine neue Metapher verwenden: ein einziges Datengeflecht. Abbildung 1-3 zeigt, wie ich mir hochwertige Telemetriedaten am liebsten vorstelle. Wir haben immer noch drei verschiedene Signale - wir können sie nicht miteinander vermischen - aber die Signale haben Berührungspunkte, die alles zu einer einzigen grafischen Datenstruktur verbinden.

Abbildung 1-3. Ein Geflecht aus Signalen, das es einfacher macht, Korrelationen zwischen ihnen zu finden

Mit einem Telemetriesystem wie diesem können Computer durch den Graphen wandern und schnell entfernte, aber wichtige Verbindungen finden. Eine einheitliche Telemetrie bedeutet, dass es endlich möglich ist, eine einheitliche Analyse durchzuführen, die für die Entwicklung eines tiefgreifenden Verständnisses der auftauchenden Probleme in lebenden Produktionssystemen entscheidend ist.

Gibt es ein solches Telemetriesystem? Ja, das gibt es. Und zwar unter namens OpenTelemetry.

Fazit

Die Welt der Beobachtbarkeit ist dabei, sich zum Besseren zu verändern, und das Herzstück dieses Wandels wird die neu entdeckte Fähigkeit sein, alle Formen von Telemetrie zu korrelieren: Traces, Metriken, Logs, Profiling, alles. Korrelation ist der Schlüssel zu den Arbeitsabläufen und der Automatisierung, die wir dringend brauchen, um in dieser Welt der immer komplexer werdenden Systeme Schritt zu halten.

Dieser Wandel ist bereits im Gange, aber es wird noch einige Zeit dauern, bis die Umstellung abgeschlossen ist und die Beobachtungsprodukte die Funktionen erkunden können, die diese neuen Daten freisetzen. Wir stehen erst am Anfang. Aber da der Kern dieses Wandels die Umstellung auf eine neue Art von Daten ist und OpenTelemetry jetzt die allgemein anerkannte Quelle für diese Daten ist, bedeutet das Verständnis von OpenTelemetry, dass wir die Zukunft der Beobachtbarkeit im Allgemeinen verstehen.

Dieses Buch ist dein Leitfaden zum Erlernen von OpenTelemetry. Es ist nicht als Ersatz für die OpenTelemetry-Dokumentation gedacht, die du auf der Website des Projekts finden kannst. Stattdessen erklärt dieses Buch die Philosophie und das Design von OpenTelemetry und bietet praktische Anleitungen, wie du es effektiv nutzen kannst.

In Kapitel 2 erklären wir, welchen Nutzen OpenTelemetry bringt und wie dein Unternehmen davon profitiert, wenn es proprietäre Messgeräte durch Messgeräte ersetzt, die auf offenen Standards basieren.

In Kapitel 3 tauchen wir tiefer in das OpenTelemetry-Modell ein und besprechen die primären Beobachtungssignale von Traces, Metriken und Logs und wie sie über den Kontext miteinander verbunden sind.

In Kapitel 4 lernen wir OpenTelemetry in der OpenTelemetry-Demo praktisch kennen und geben dir einen Überblick über die Komponenten und wie OpenTelemetry in einen Observability-Stack passt.

In Kapitel 5 gehen wir auf die Instrumentierung einer Anwendung ein und stellen eine Checkliste zur Verfügung, mit der du sicherstellen kannst, dass alles funktioniert und die Telemetrie von hoher Qualität ist.

In Kapitel 6 gehen wir auf die Instrumentierung von OSS-Bibliotheken und -Diensten ein und erklären, warum Bibliotheksbetreuer sich um die Beobachtbarkeit kümmern sollten.

In Kapitel 7 befassen wir uns mit den Optionen für die Beobachtung von Software-Infrastrukturen - Cloud-Provider, Plattformen und Datendienste.

In Kapitel 8 gehen wir im Detail darauf ein, wie und warum du mit dem OpenTelemetry Collector verschiedene Arten von Beobachtungspipelines aufbauen kannst.

In Kapitel 9 geben wir dir Tipps, wie du OpenTelemetry in deinem Unternehmen einführen kannst. Da die Telemetrie - insbesondere das Tracing - eine teamübergreifende Angelegenheit ist, gibt es bei der Einführung eines neuen Beobachtungssystems organisatorische Fallstricke. In diesem Kapitel findest du Strategien und Ratschläge, wie du eine erfolgreiche Einführung sicherstellen kannst.

In den Anhängen findest du hilfreiche Informationen über die Struktur des OpenTelemetry-Projekts sowie Links zu weiterführender Literatur und anderen Titeln.

Wenn du ganz neu in OpenTelemetry bist, empfehlen wir dir, zuerst das Kapitel 4 zu lesen. Danach können die Kapitel in beliebiger Reihenfolge gelesen werden. Du kannst einfach zu dem Abschnitt springen, der für deine Aufgabe am wichtigsten ist.

¹ Henry Glassie, Passing the Time in Ballymenone: Culture and History of an Ulster Community (Philadelphia: University of Pennsylvania Press, 1982).

² Carl E. Sagan (Autor und Moderator), in Cosmos: A Personal Voyage, Staffel 1, Folge 2, "One Voice in the Cosmic Fugue", produziert von Adrian Malone (Arlington, VA: Public Broadcasting Service, 1980).

³ Andrew S. Tanenbaum und Maarten van Steen, Distributed Systems: Principles and Paradigms (Upper Saddle River, NJ: Prentice Hall, 2002).

⁴ Cindy Sridharan, Distributed Systems Observability (Sebastopol, CA: O'Reilly, 2018).