OpenTelemetry lernen

Kapitel 4. Die OpenTelemetry-Architektur

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

Jeder weiß, dass das Debuggen doppelt so schwer ist wie das Schreiben eines Programms. Wenn du also beim Schreiben eines Programms so schlau bist, wie du sein kannst, wie willst du es dann jemals debuggen?

Brian W. Kernighan und P. J. Plauger¹

OpenTelemetry besteht aus drei Arten von Komponenten: Instrumenten, die in Anwendungen installiert werden, Exporteuren für Infrastrukturen wie Kubernetes und Pipeline-Komponenten, die all diese Telemetrie an ein Speichersystem senden. Wie diese Komponenten zusammenhängen, siehst du in Abbildung 4-1.

Dieses Kapitel gibt dir einen Überblick über alle Komponenten, aus denen OpenTelemetry besteht. Danach werden wir in die OpenTelemetry-Demo-Anwendung eintauchen, um zu sehen, wie die Komponenten zusammenpassen.

Anwendung Telemetrie

Die wichtigste Quelle für Telemetrie sind die Anwendungen. Das bedeutet, dass OpenTelemetry in jeder Anwendung installiert werden muss, damit es richtig funktioniert. Unabhängig davon, ob du es automatisch mit einem Agenten oder manuell durch das Schreiben von Code installierst, sind die Komponenten, die du installierst, dieselben. Abbildung 4-2 zeigt, wie sie zusammengehören.

Abbildung 4-1. Die Beziehung zwischen OpenTelemetry und den Analysekomponenten

Abbildung 4-2. OpenTelemetry-Anwendungsarchitektur

Bibliothek Instrumentierung

Die wichtigsten Telemetriedaten stammen von OSS-Bibliotheken wie Frameworks, HTTP- und RPC-Clients und Datenbank-Clients. Diese Bibliotheken übernehmen in den meisten Anwendungen die Hauptarbeit, und oft reichen die Telemetriedaten dieser Bibliotheken aus, um fast die gesamte Arbeit einer Anwendung abzudecken.

Heute sind die meisten OSS-Bibliotheken nicht nativ mit OpenTelemetry instrumentiert. Das bedeutet, dass die Instrumentierung für diese Bibliotheken separat installiert werden muss. OpenTelemetry bietet Instrumentierungsbibliotheken für viele beliebte OSS-Bibliotheken.

Die OpenTelemetry API

Die Instrumentierung der Bibliothek ist zwar sehr nützlich, aber du wirst unweigerlich auch kritische Teile des Anwendungscodes und der Geschäftslogik instrumentieren wollen. Dazu verwendest du die OpenTelemetry-API. Die Bibliotheksinstrumentierung, die du installierst, wird ebenfalls mit dieser API geschrieben, sodass es keinen grundlegenden Unterschied zwischen der Anwendungsinstrumentierung und der Bibliotheksinstrumentierung gibt.

Die OpenTelemetry-API hat eine besondere Eigenschaft: Sie kann auch dann sicher aufgerufen werden, wenn OpenTelemetry nicht in einer Anwendung installiert ist. Das bedeutet, dass OSS-Bibliotheken OpenTelemetry-Instrumente enthalten können, die automatisch aktiviert werden, wenn OpenTelemetry verwendet wird, und die als Null-Kosten-No-Op funktionieren, wenn die Bibliothek in Anwendungen installiert ist, die OpenTelemetry nicht verwenden. Weitere Informationen darüber, wie du OSS-Bibliotheken instrumentieren kannst, findest du in Kapitel 6.

Das OpenTelemetry SDK

Unter müssen Sie den OpenTelemetry-Client installieren, damit die von den Bibliotheken und dem Anwendungscode gesendeten OpenTelemetry-API-Aufrufe tatsächlich verarbeitet werden können. Wir bezeichnen diesen Client als OpenTelemetry SDK. Das SDK ist ein Plug-in-Framework, das aus Sampling-Algorithmen, Lifecycle Hooks und Exportern besteht, die mithilfe von Umgebungsvariablen oder einer YAML-Konfigurationsdatei konfiguriert werden können.

Die Instrumentierung ist entscheidend!

Wenn du über die Installation von OpenTelemetry in deiner Anwendung nachdenkst, kann es leicht passieren, dass du nur an die Installation des SDKs denkst. Es ist wichtig, sich daran zu erinnern, dass du auch die Instrumentierung für alle wichtigen Bibliotheken benötigst. Während der Installation solltest du deine Anwendung überprüfen und sicherstellen, dass die notwendigen Bibliotheksinstrumente vorhanden und korrekt installiert sind.

In Kapitel 5 werden wir tiefer in das Innenleben dieser Anwendungskomponenten eintauchen und dich durch eine erfolgreiche Installation führen. Im Moment reicht es, wenn du weißt, dass diese Komponenten existieren.

Infrastruktur Telemetrie

Anwendungen werden in einer Umgebung ausgeführt. Beim Cloud Computing besteht diese Umgebung aus dem Host, auf dem die Anwendung läuft, und der Plattform, die zur Verwaltung der Anwendungsinstanzen verwendet wird, sowie aus verschiedenen Netzwerk- und Datenbankdiensten, die von deinem Cloud-Provider betrieben werden. Der Zustand der Infrastruktur ist unglaublich wichtig, und große verteilte Systeme haben eine Menge Infrastruktur. Hochwertige Telemetriedaten von diesen Diensten sind entscheidend.

OpenTelemetry wird langsam zu Kubernetes und anderen Cloud-Diensten hinzugefügt. Aber auch ohne OpenTelemetry produzieren die meisten Infrastrukturdienste eine Art nützlicher Telemetrie. OpenTelemetry enthält eine Reihe von Komponenten, mit denen du diese Daten sammeln und in die Telemetrie-Pipeline der Anwendungen einfügen kannst. (Weitere Informationen findest du in Kapitel 7.)

Telemetrie-Pipelines

Die von den Anwendungen und der Infrastruktur gesammelten Telemetriedaten müssen zur Speicherung und Analyse an ein Beobachtungstool gesendet werden. Das kann sich zu einem schwierigen Problem entwickeln. Die Menge an Telemetriedaten von einem großen verteilten System unter hoher Last kann enorm sein. Infolgedessen können Netzwerkprobleme wie Egress, Lastausgleich und Rückstau erheblich sein.

Außerdem handelt es sich bei großen Systemen meist um alte Systeme. Das bedeutet, dass sie möglicherweise einen Flickenteppich von Beobachtungsinstrumenten einsetzen, unterschiedliche Anforderungen an die Datenverarbeitung haben und im Allgemeinen eine umfangreiche Verarbeitung und Weiterleitung von Telemetriedaten an verschiedene Stellen erfordern. Die daraus resultierende Topologie kann sehr kompliziert sein.

OpenTelemetry hat zwei Hauptkomponenten, um dies zu ermöglichen: Das OpenTelemetry-Protokoll (OTLP), das in Kapitel 3 besprochen wird, und den Collector, der in Kapitel 8 ausführlich behandelt wird.

Was in OpenTelemetry nicht inbegriffen ist

Was OpenTelemetry nicht enthält, ist fast genauso wichtig wie das, was es enthält. Langfristige Speicherung, Analyse, GUIs und andere Frontend-Komponenten sind nicht enthalten und werden es auch nie sein.

Und warum? Standardisierung. Während es möglich ist, eine stabile, universelle Sprache für die Beschreibung von Computeroperationen zu entwickeln, wird sich der Analysebereich der Beobachtbarkeit immer weiterentwickeln. Das Ziel von OpenTelemetry ist es, mit allen Analysetools zusammenzuarbeiten und die Menschen zu ermutigen, in Zukunft noch viel fortschrittlichere und neuartige Tools zu entwickeln. Daher wird das OpenTelemetry-Projekt niemals um eine Art "offizielles" Observability-Backend erweitert werden, das sich von allen anderen Observability-Systemen auf der Welt unterscheidet oder besonders behandelt wird. Diese Trennung - standardisierte Telemetriedaten, die in eine sich ständig weiterentwickelnde Landschaft von Analysewerkzeugen einfließen - ist für die Sichtweise des OpenTelemetry-Projekts von grundlegender Bedeutung.

Praktische Übungen mit der OpenTelemetry-Demo

Bis zu diesem Punkt war unsere Diskussion über OpenTelemetry sehr theoretisch. Um wirklich zu verstehen, wie die Dinge in der Praxis zusammenpassen, müssen wir uns eine echte Anwendung und echten Code ansehen.

Als Erstes gibt es eine kurze Zusammenfassung dessen, was du bisher gelernt hast:

• OpenTelemetry bietet APIs, SDKs und ein Ökosystem von Tools, um Telemetriedaten zu erstellen, zu sammeln, umzuwandeln und ihre Qualität zu sichern.

• OpenTelemetry stellt sicher, dass Telemetriedaten übertragbar und interoperabel sind.

• Anders als das alte "Drei-Säulen-Modell" verbindet OpenTelemetry Tracing, Metriken, Logging und Ressourcen in einem einzigen Datenmodell. So entstehen regulierte Daten, die hoch korreliert und von einheitlich hoher Qualität sind.

• Die semantischen Konventionen von OpenTelemetry stellen sicher, dass die Telemetrie aus verschiedenen Bibliotheken konsistent und von einheitlich hoher Qualität ist.

• OpenTelemetry ist einfach nur Telemetrie. Es wurde entwickelt, um Daten an eine Vielzahl von Speicher- und Analysetools zu senden und die Entwicklung neuer, fortschrittlicherer Analysetools zu ermöglichen.

Es ist klar, dass OpenTelemetry aus vielen Dingen besteht und eine Menge beweglicher Teile hat. Das Ziel dieses Buches ist es nicht, dir einfach beizubringen, wie du eine Metrik erstellst oder einen Span startest, sondern dir zu helfen, OpenTelemetry ganzheitlich zu verstehen. Das geht am besten, wenn du es in einer echten Anwendung in Aktion siehst.

Hilfreich ist, dass das OpenTelemetry-Projekt eine robuste Demo-App speziell für diesen Zweck bereitstellt. Im weiteren Verlauf des Kapitels werden wir ein praktisches Beispiel für die OpenTelemetry-Architektur durchgehen, wie sie in dieser Demo, dem Astronomy Shop, implementiert ist. Wir werden Folgendes behandeln:

• Installieren und Ausführen der Demo

• Erforschung der Anwendungsarchitektur und ihres Designs

• OpenTelemetry-Daten nutzen, um Fragen zur Demo zu beantworten

Du kannst auch nur mit dem Buch arbeiten, aber wir empfehlen dir dringend, die Demo selbst zu starten. Dieser praktische Ansatz wird viele Fragen klären.

Ausführen der Demo

Für diesen Abschnitt benötigst du einen aktuellen Laptop oder Desktop-Computer, idealerweise mit 16 GB oder mehr Arbeitsspeicher. Außerdem brauchst du etwa 20 GB Speicherplatz für alle Container-Images. In dieser Anleitung wird davon ausgegangen, dass du Docker und Git zur Verfügung hast und konfiguriert bist.

Bleib auf dem Laufenden

Diese Anleitung wurde Ende 2023 für die OpenTelemetry Demo v1.6.0 mit einem 2022 MacBook Pro mit einem Apple Silicon M2 Max und 32 GB RAM geschrieben. In der OpenTelemetry-Demo-Dokumentation findest du aktuelle Installationsanweisungen für neuere Versionen der Demo oder eine Anleitung zur Installation in Kubernetes.

Zum Installieren:

1. Navigiere zum GitHub-Repository der Demo und klone es auf deinen Computer.

2. Navigiere in einem Terminal zum Stammverzeichnis des Repositorys, das du gerade geklont hast, und führe make start aus.

Wenn dies erfolgreich war, solltest du nach einigen Minuten die folgende Ausgabe in deinem Terminal sehen:

OpenTelemetry Demo is running.
Go to http://localhost:8080 for the demo UI.
Go to http://localhost:8080/jaeger/ui for the Jaeger UI.
Go to http://localhost:8080/grafana/ for the Grafana UI.
Go to http://localhost:8080/loadgen/ for the Load Generator UI.
Go to http://localhost:8080/feature/ for the Feature Flag UI.

Navigiere in einem Webbrowser zu localhost:8080 und du solltest eine Webseite sehen, die wie Abbildung 4-3 aussieht.

Abbildung 4-3. Die Startseite von OpenTelemetry Demo

Wenn du das siehst, bist du startklar! Wenn du auf Schwierigkeiten stößt, findest du in der Anleitung, die im Hinweis "Bleib auf dem Laufenden" verlinkt ist, weitere Informationen und Hilfe bei der Fehlerbehebung.

Architektur und Design

Astronomy Shop ist eine Microservice-basierte E-Commerce-Anwendung, die aus 14 separaten Diensten besteht, wie in Abbildung 4-4 dargestellt.

Der Astronomy Shop soll Entwicklern, Betreibern und anderen Endnutzern die Möglichkeit geben, eine "produktionsnahe" Version eines Projekts zu testen. Um eine nützliche Demo mit interessanten Beispielen für die Beobachtbarkeit zu erstellen, wurden einige Dinge eingebaut, die du in einer "echten" Produktionsanwendung nicht unbedingt sehen würdest, z. B. Code zur Simulation von Fehlern. Die meisten realen Anwendungen, auch die Cloud-nativen, sind in Bezug auf Sprache und Laufzeit deutlich homogener als die Demo, und eine "echte" Anwendung arbeitet in der Regel mit mehr Datenschichten und Speichermaschinen als die Demo.

Abbildung 4-4. Der OpenTelemetry Demo-Dienst

Wir können die Gesamtarchitektur in zwei grundlegende Teile aufteilen: die Beobachtbarkeit und die Anwendungsbelange. Die Anwendungsbelange sind die Dienste, die die Geschäftslogik und die funktionalen Anforderungen abwickeln, wie z.B. der E-Mail-Dienst (der für den Versand von Transaktions-E-Mails an Kunden zuständig ist) und der Währungsdienst (der für die Umrechnung zwischen allen unterstützten Währungswerten in der Anwendung verantwortlich ist).

Observability Concerns ( ) sind für einen Teil der allgemeinen Observability der Anwendung verantwortlich, indem sie Telemetriedaten sammeln und umwandeln, sie speichern und abfragen oder diese Abfragen visualisieren. Dazu gehören der Lastgenerator, der OpenTelemetry Collector, Grafana, Prometheus, Jaeger und OpenSearch. Der Lastgenerator ist auch für die Beobachtbarkeit von Bedeutung, da er die Demo-Anwendung gleichmäßig belastet, um zu simulieren, wie eine "echte" Umgebung aussehen könnte.

Obwohl die Demo in einer Vielzahl von Programmiersprachen geschrieben ist, kommunizieren die Dienste untereinander über ein Standard-Framework, in diesem Fall gRPC (oder JSON Protobuffer über HTTP). Das ist aus zwei Gründen so gewollt. Erstens verwenden viele Organisationen (auch solche ohne polyglotte Umgebungen) standardmäßig ein einziges RPC-Framework, wie z. B. gRPC. Zweitens unterstützt OpenTelemetry gRPC und enthält bereits nützliche Instrumente für seine Bibliotheken. Das bedeutet, dass du eine Fülle von Telemetriedaten "umsonst" erhältst, wenn du mit OpenTelemetry und gRPC nutzt.

Verwaltung der Anwendungsleistung mit OpenTelemetry

Um zu sehen, was OpenTelemetry leisten kann, erstellen wir ein interessantes Problem, das du entdecken kannst. Navigiere mit deinem Browser zum Feature Flag UI (http://localhost:8080/feature) und aktiviere die Flags cartServiceFailure und adServiceFailure, indem du auf Bearbeiten klickst, das Kontrollkästchen Aktiviert aktivierst und dann deine Änderungen speicherst. Du solltest die Demo ein paar Minuten laufen lassen, bevor und nachdem du diese Feature Flags aktiviert hast, um zu sehen, wie die Leistung vor und nach der Aktivierung aussieht. Abbildung 4-5 zeigt, was du in der Feature Flag UI sehen solltest, nachdem du diese Aufgabe erledigt hast.

Abbildung 4-5. Die ausgewählten Feature Flags werden in der Feature Flag UI aktiviert

Nachdem du ein paar Minuten gewartet hast, kannst du mit dem Erkunden der Daten beginnen. Grafana (http://localhost:8080/grafana/) bietet mehrere vorgefertigte Dashboards an; eines der interessantesten ist das Spanmetrics Demo Dashboard. Dieses Dashboard bietet dir eine "APM-ähnliche" Ansicht der Dienste und zeigt die Latenz, die Fehlerrate und den Durchsatz jeder Route über alle Anwendungsdienste hinweg. Interessant ist, dass dieses Dashboard nicht aus Metriken, sondern aus Trace-Daten generiert wird, und zwar mithilfe des OpenTelemetry Collector's spanmetrics Konnektors. Wenn du dieses Dashboard auf den Anzeigendienst und den Warenkorbservice filterst(Abbildung 4-6), wirst du feststellen, dass sie eine leicht erhöhte Fehlerrate haben.

Abbildung 4-6. Das Spanmetrics Dashboard in Grafana

In der Tabelle unten rechts in Abbildung 4-6 kannst du sehen, dass der Name der Spanne mit der höheren Fehlerquote oteldemo.AdService/GetAds lautet. Das ist ein guter Ausgangspunkt für eine Untersuchung.

Wie würdest du normalerweise herausfinden, was die Ursache für dieses Problem ist? Viele Leute würden zu den Protokollen greifen. Aber da OpenTelemetry umfangreiche, kontextreiche Traces liefert, kannst du die beiden Daten, die du hast - das Vorhandensein und den Ort von Fehlern - nutzen, um nach passenden Traces zu suchen.

In Grafana kannst du Trace-Daten erkunden, indem du im Menü auf den Punkt Erkunden gehst. Dort wählst du Jaeger aus dem Dropdown-Menü oben aus (standardmäßig sollte dort Prometheus stehen) und wechselst dann zu einer Suchabfrage. Gib die Informationen ein, die du kennst (siehe Abbildung 4-7), und klicke dann auf Abfrage ausführen. Du siehst nun alle Anfragen, die Fehler für diese bestimmte Route enthalten. Wenn du diese Spuren untersuchst, siehst du, dass ein kleiner Prozentsatz der Transaktionen mit einem gRPC-Fehler fehlschlägt. Du kannst diese Informationen weiter untersuchen, indem du sie mit der Speicher- oder CPU-Auslastung auf dem Host oder dem Container vergleichst.

Abbildung 4-7. Erkunden der Jaeger-Trace-Daten in Grafana

Dieser zufällige Fehler ist vielleicht nicht besonders interessant, aber interessant ist, dass die Instrumentierung, die erforderlich war, um dieses Ergebnis zu erhalten, sozusagen kostenlos war. Dies ist ein Beispiel für die automatische Instrumentierung (oder Zero-Code-Instrumentierung), bei der ein Agent oder eine Bibliothek Instrumentierungscode hinzufügt, ohne dass du etwas schreiben musst, um sie zu aktivieren. Wenn du dir das Dockerfile für den Anzeigendienst ansiehst, kannst du sehen, dass es einen Agenten als Teil des Builds herunterlädt, ihn in den Container kopiert und ihn zusammen mit dem Dienst ausführt. Das bedeutet, dass beim Start des Dienstes die notwendige Instrumentierung hinzugefügt wird, ohne dass der Entwickler etwas dafür tun muss.

Ein ähnliches Muster gibt es auch beim Cart Service, und auch hier musst du keine eigene Instrumentierung schreiben, um ihn zu entdecken. In .NET ist OpenTelemetry in die Laufzeitumgebung integriert - du musst es nur noch aktivieren. Überzeuge dich selbst: Öffne /src/cartservice/src/Program.cs in einem Editor und sieh dir Zeile 52 an. Wir haben dem folgenden Code einige Anmerkungen hinzugefügt, damit du besser verstehst, was hier vor sich geht:

builder.Services.AddOpenTelemetry() 
    .ConfigureResource(appResourceBuilder)
    .WithTracing(tracerBuilder => tracerBuilder
        .AddRedisInstrumentation(
            options => options.SetVerboseDatabaseStatements = true)
        .AddAspNetCoreInstrumentation()
        .AddGrpcClientInstrumentation() 
        .AddHttpClientInstrumentation()
        .AddOtlpExporter()) 
    .WithMetrics(meterBuilder => meterBuilder 
        .AddProcessInstrumentation()
        .AddRuntimeInstrumentation()
        .AddAspNetCoreInstrumentation()

Dadurch werden die OpenTelemetry-Bibliotheken dem Container für die Injektion von Abhängigkeiten hinzugefügt, der in .NET-Anwendungen vorhanden ist.

Dies ermöglicht eine integrierte Instrumentierung für gRPC-Clients.

Hier aktivieren wir den OTLP-Export, um die Daten an einen OpenTelemetry Collector zu senden.

Wir erhalten auch Metriken aus den Prozessen wie Speicher und Speicherbereinigung, HTTP-Server-Metriken usw.

In beiden Fällen liefert OpenTelemetry mit sehr wenig Aufwand wertvolle Telemetriedaten auf Framework-Ebene. In Kapitel 5 gehen wir näher auf die Verfügbarkeit dieser Art von automatischer Instrumentierung in anderen Sprachen ein - es gibt nicht nur für .NET und Java!

Die Nadel im Heuhaufen finden

Framework-Instrumentierung bringt dir eine Menge, wie wir im letzten Abschnitt gezeigt haben. Du kannst aber noch viel mehr erreichen, wenn du weitere Instrumente hinzufügst. In den Kapiteln 5 und 6 wird dies ausführlicher behandelt, aber wir wollen dir einen Vorgeschmack auf den Unterschied geben. Abbildung 4-8 zeigt den Unterschied zwischen der Framework-Instrumentierung allein und einer Kombination aus Framework- und benutzerdefinierter Instrumentierung in einer Transaktion zwischen zwei Diensten in der Demo.

Abbildung 4-8. Zwei Trace-Wasserfälle der gleichen Transaktion. Der erste Trace (oben) zeigt nur Client-Spans; der zweite Trace umfasst Client-, Server- und Custom-Spans.

Untersuchen wir ein Problem, das nur bei der benutzerdefinierten Instrumentierung auftritt. Wenn du zum Feature Flag UI (http://localhost:8080/feature) zurückkehrst und productCatalogFailure aktivierst, wirst du ein neues Problem in der Demo feststellen. Nach ein paar Minuten wirst du feststellen, dass die Fehlerrate für mehrere Dienste schleichend ansteigt, vor allem für das Frontend(Abbildung 4-9).

Dies ist ein typisches Beispiel für einen häufigen Fehlermodus in verteilten Anwendungen: Das, was fehlschlägt, ist nicht unbedingt das, was ein Problem hat. Wäre dies eine echte Anwendung, würde dein Frontend-Team wahrscheinlich wegen dieser relativ hohen Fehlerrate angepiept werden. Deine erste Anlaufstelle könnte ein grundlegender Gesundheitscheck für das Frontend sein, der in der Demo als Metrik httpcheck.status verfügbar ist. Die Abfrage dieser Metrik in Grafana zeigt jedoch, dass alles in Ordnung ist(Abbildung 4-10).

Abbildung 4-9. Das Spanmetrics Dashboard zeigt die Fehlerraten während eines Produktkatalog-Serviceausfalls

Abbildung 4-10. Abfrage der Metrik httpcheck.status in Grafana

Das zeigt dir, dass der Webserver keine Probleme hat. Vielleicht ist es der Frontend-Dienst? Wenn du nur mit Metriken und Logs arbeiten könntest, müsstest du die Log-Statements durchsuchen und versuchen, die Fehler herauszufinden. Da es aber auch Metriken für die Spans gibt, kannst du stattdessen nach Fehlern auf der Route suchen(Abbildung 4-11). Wenn du nur nach Frontend-Spans filterst und die Suche auf Fehler einschränkst, kannst du diese Fehler über alle Aufrufe des Frontends an das Backend addieren.

Hier ist etwas Interessantes: Der Anstieg der Fehler kommt vom Produktkatalogdienst! Wenn du ein Frontend-Entwickler bist, kannst du aufatmen: Es ist wahrscheinlich nicht deine Schuld.

Abbildung 4-11. Filterung der Span-Metriken zur Fehlersuche nach Route

Dein nächster Schritt bei der Fehlersuche sollte darin bestehen, diese spezifischen Fehler zu untersuchen. Wie zuvor kannst du in Grafana oder direkt in Jaeger nach Spans suchen, die dem Fehler entsprechen.

Wenn du alle Traces untersuchst, die oteldemo.ProductCatalogService/GetProduct aufrufen, wirst du feststellen, dass die Fehler alle etwas gemeinsam haben: Sie treten nur auf, wenn das Attribut app.product.id einen bestimmten Wert hat. In Jaeger und Grafana allein kann es etwas schwierig sein, diese Tatsache zu entdecken; du musst viele Traces miteinander vergleichen, entweder manuell oder durch den Vergleich einzelner Traces. Fortschrittlichere Analysetools - sowohl Open Source als auch kommerziell - unterstützen die aggregierte Analyse von Spans und die Erkennung von Korrelationen. Damit kannst du den spezifischen Wert, der zu dem Fehler führt, leichter erkennen und den Zeitaufwand für die Identifizierung und Behebung des Problems verringern.

Die automatische Instrumentierung kann nichts über die domänen- oder geschäftsspezifische Logik und die Metadaten wissen, die für deinen Dienst wichtig sind. Du musst sie selbst hinzufügen, indem du die Instrumentierung erweiterst. In diesem Fall verwendet der Produktkatalog die gRPC-Instrumentierung. Du möchtest den erzeugten Spans einen nützlichen weichen Kontext hinzufügen, wie z. B. die angeforderte Produkt-ID. Du kannst sehen, wo dieses Attribut in den Zeilen 198 bis 202 des Quellcodes(/src/productcatalogservice/main.go) gesetzt ist:

func (p *productCatalog) GetProduct(ctx context.Context, req *pb.GetProductRequest) 
          (*pb.Product, error) { 
	span := trace.SpanFromContext(ctx) 
	span.SetAttributes(
		attribute.String("app.product.id", req.Id), 
	)

In Go wird der OpenTelemetry-Kontext im Context übertragen.

Um einen bestehenden Bereich zu ändern oder einen neuen zu beginnen, musst du den aktuellen Bereich aus dem Kontext holen.

Da OpenTelemetry semantisch ist, musst du Attribute und ihre Werte stark typisieren.

Die Demo bietet noch mehr als das, was wir hier beschrieben haben, z. B. Datenbankanfragen, asynchrone Arbeit über Kafka und Infrastrukturüberwachung. Am besten liest du dir die Dienste in den Sprachen durch, mit denen du am besten vertraut bist, um eine Vorstellung davon zu bekommen, wie du OpenTelemetry in der Praxis nutzen und die Daten, die es ausgeben kann, untersuchen kannst. Zum Zeitpunkt der Erstellung dieses Artikels ist die Unterstützung für alle OpenTelemetry-Funktionen in der Demo etwas lückenhaft. Tracing funktioniert überall gut, und Metriken funktionieren in etwa der Hälfte der Dienste. Die Logging-Unterstützung wird derzeit nur in einer Handvoll Dienste angeboten, aber wenn du dies liest, sollte sie weiter verbreitet sein.

Pipelines zur Beobachtbarkeit in der Demo

Das letzte, was du über die Demo wissen solltest, ist, wie sie Daten sammelt. Wenn möglich, zieht die Demo es vor, Daten von einem Prozess zu einer Instanz des OpenTelemetry Collector zu pushen. Das Filtern, Stapeln und Erstellen von Metrik-Ansichten wird im Collector und nicht im Prozess selbst durchgeführt.

Dies geschieht aus zwei Gründen. Erstens ist es eine gute Idee, die Telemetrie so schnell wie möglich aus deinem Dienst herauszuholen. Die Erstellung von Telemetriedaten ist nicht kostenlos; es gibt einen gewissen Overhead. Je mehr Daten du auf der Anwendungsebene verarbeitest, desto mehr Overhead verursachst du. Das mag in Ordnung sein, wenn die Dinge gut laufen, aber unerwartete Belastungsmuster (wie z. B. während eines Vorfalls) können unerwartete Auswirkungen auf das Leistungsprofil eines Dienstes haben. Wenn deine Anwendung abstürzt, bevor du Daten exportieren (oder scrapen) kannst, gehen dir diese Erkenntnisse verloren. Es ist aber auch möglich, so viele Telemetriedaten zu erzeugen, dass die lokalen Netzwerkverbindungen überlastet werden und Leistungsprobleme auf einer anderen Ebene deines Systems verursachen. Hier gibt es keine allgemeingültige Regel - jeder Mensch hat andere Voraussetzungen. Am besten stellst du sicher, dass du ein gutes Metamonitoring für deine OpenTelemetry-Infrastruktur aktivierst. (Ein Beispiel dafür siehst du im Collector-Dashboard, das in der Demo enthalten ist). Eine viel ausführlichere Diskussion über Observability-Pipelines findest du in Kapitel 8.

Das neue Modell der Beobachtbarkeit

Jetzt du eine Anwendung gesehen hast, die OpenTelemetry verwendet, lass uns überprüfen, wie alles, worüber wir bisher gesprochen haben, zusammenpasst. Der Rest des Buches wird sich auf die Einzelheiten konzentrieren. Du kannst dir diesen Abschnitt als das "Ende vom Anfang" vorstellen.

In Kapitel 1 haben wir über die "drei Browser-Tabs der Beobachtbarkeit" gesprochen, aber das Konzept ist es wert, noch einmal genauer betrachtet zu werden. Die Menschen nutzen Beobachtungswerkzeuge vor allem aus der Not heraus. Es ist zwar schön, über Datenmodellierungsstrategien oder die Zuordnung von Systemen zu Telemetriesignalen zu philosophieren, aber in der Regel haben sie keinen großen Einfluss auf deine tägliche Arbeit. Wenn du so darüber nachdenkst, macht es Sinn, warum die meisten Tools vertikal integriert sind. Sie sind integriert, weil dies die kosteneffizientesten Kompromisse für die Leute sind, die sie entwickeln.

Nehmen wir ein konkretes Beispiel für die Metriken. Wenn du ein Tool für die Analyse und Speicherung von Metriken entwickelst, willst du wahrscheinlich dein System effizienter gestalten, vor allem bei häufig auftretenden Daten. Das kannst du mit Strategien für Clustering, Reaggregation und Verdichtung erreichen. Dazu musst du allerdings die Instrumentierung und die Sammelpipeline kontrollieren - du musst sicherstellen, dass du die richtigen Attribute zu den richtigen Daten hinzufügst. Daraus ergeben sich weitere Effizienzgewinne: Du könntest z. B. den Prozessaufwand für die Erzeugung von Metriken reduzieren, indem du die Attributerzeugung in einen externen Prozess verlegst, zustandslose Drahtformate verwendest und so weiter.

Vieles davon wird jedoch hinfällig, wenn du mit einer Datenpipeline zu tun hast, die du nicht mehr kontrollieren kannst. Das ist der Grund, warum OpenTelemetry so eine große Sache im Bereich der Beobachtbarkeit ist: Es bricht dieses grundlegende Modell auf. Das Ergebnis ist ein neues Modell für Observability-Tools, das die Tür zu bedeutenden Innovationen öffnet.

In dem in Abbildung 4-12 dargestellten Modell basiert die "neue" Art, Dinge zu tun, auf einer einheitlichen, universellen Instrumentierung über OpenTelemetry. Sie kombiniert Telemetriedaten aus all deinen Quellen - Greenfield-Code, Legacy-Code, bestehende Instrumente und Geschäftsdaten aus Datensystemen und anderen wichtigen Quellen. Diese Daten werden dann über OTLP an (mindestens) einen Datenspeicher gesendet.

OpenTelemetry fungiert als universeller Kanal für Telemetriedaten, der es dir ermöglicht, Telemetriedatenströme zu verarbeiten und zu senden, je nach dem Wert der Daten für dein Unternehmen oder dem Anwendungsfall, den du damit ermöglichen möchtest. Das ist ein wichtiger Baustein für das, was als Nächstes kommen kann.

Abbildung 4-12. Das neue Modell der Beobachtbarkeitstools

Künftige Observabilitätsplattformen werden Funktionen wie universelle Abfrage-APIs bieten, mit denen du nahtlos Telemetriedaten aus einer Vielzahl von Datenspeichern abrufen kannst. Du bist nicht mehr an eine einzige Abfragesprache gebunden, sondern kannst mit Hilfe von KI-Tools in natürlicher Sprache das finden, wonach du suchst. Dank der Datenportabilität, die OpenTelemetry bietet, bist du nicht mehr auf große Omnibus-Plattformen beschränkt, sondern kannst aus einer Vielzahl spezifischer Analysewerkzeuge wählen, die für die Lösung bestimmter Probleme entwickelt wurden.

OpenTelemetry wird diese Probleme nicht allein lösen, aber es ist ein wichtiger Teil der Lösung. In gewisser Weise ist es mehr für die Zukunft mit hochgradig kontextbezogenen Daten und Tools, die sie verstehen können, ausgelegt als die heutigen Tools.

Vielleicht hast du den Widerspruch zwischen der "alten" und der "neuen" Art, Dinge zu tun, im vorherigen Abschnitt gespürt. So viel wir auch über Metriken und Protokolle gesprochen haben (und weiter sprechen werden), ein großer Teil der Demo-Workflows dreht sich um Tracing. Das liegt zum Teil daran, dass die uns zur Verfügung stehenden Tools wie Prometheus und Jaeger nicht die Art von Workflows mit hoher Kardinalität und hohem Kontext unterstützen, die OpenTelemetry bietet. Alle OpenTelemetry-Komponenten sind so konzipiert, dass sie zusammenarbeiten und erweitert werden können, um deine bestehenden Telemetriedaten ohne erneute Instrumentierung auf den neuesten Stand zu bringen. Um jedoch den größtmöglichen Nutzen daraus zu ziehen, müssen deine Tools auch die Konzepte der hochkardinalen Daten, der Korrelation zwischen harten und weichen Kontexten und der einheitlichen Telemetrie unterstützen.

Zum Zeitpunkt der Erstellung dieses Artikels gibt es hervorragende Anzeichen für Fortschritte in diese Richtung. In den letzten Jahren wurde eine ganze Reihe neuer Observabilitäts-Tools auf den Markt gebracht, von denen viele ausschließlich auf OpenTelemetry als Instrumentarium setzen. Diese Tools, die auf Open-Source-Säulenspeichern basieren, eignen sich gut für die Art von kontextbezogenen Telemetriedaten, die OpenTelemetry liefert. Große Unternehmen setzen ebenfalls auf OpenTelemetry, darunter Microsoft und Amazon Web Services, die beide vor kurzem erstklassige Unterstützung für OpenTelemetry angekündigt haben (Microsoft als Teil von Azure Monitor und Amazon als OpenTelemetry-gestützte APM-Lösung für EKS-Anwendungen). Auch nicht-kommerzielle Tools bauen ihre OpenTelemetry-Unterstützung aus. Projekte wie OpenSearch und ClickHouse werden immer beliebter für , die OpenTelemetry-Daten speichern.

Fazit

Die grundlegenden Bausteine von OpenTelemetry zu verstehen und zu sehen, wie sie in einer echten Anwendung zusammenpassen, ist dein erster richtiger Schritt in die praktische OpenTelemetry. Jetzt, wo du dir die Füße nass gemacht hast, ist es an der Zeit, in die Details einzutauchen.

Der Rest des Buches ist den Besonderheiten der Funktionsweise von OpenTelemetry gewidmet und dem, was du wissen musst, um deine Anwendungen, Bibliotheken und Infrastruktur erfolgreich für Observability zu instrumentieren. Außerdem geben wir dir praktische Tipps, wie du Telemetrie-Pipelines entwirfst und Observability in deinem Unternehmen einführst, basierend auf Fallstudien von bestehenden Nutzern. Nach jedem Vertiefungsteil gibt es eine Checkliste, mit der du sicherstellen kannst, dass deine OpenTelemetry-Einführung erfolgreich verläuft.

¹ Brian W. Kernighan und P. J. Plauger, The Elements of Programming Style, 2nd ed. (New York: McGraw-Hill, 1978).