Verteilte Rückverfolgung in der Praxis

Kapitel 1. Das Problem mit verteiltem Tracing

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

ICH HABE KEINE WERKZEUGE, WEIL ICH MEINE WERKZEUGE MIT MEINEN WERKZEUGEN ZERSTÖRT HABE.

James Mickens¹

Das Konzept, die Ausführung eines Computerprogramms zu verfolgen, ist keineswegs neu. Die Fähigkeit, den Stack eines Programms zu verstehen, ist für alle Arten von Profiling-, Debugging- und Überwachungsaufgaben von entscheidender Bedeutung, könnte man sagen. In der Tat sind Stack Traces wahrscheinlich das am zweithäufigsten genutzte Debugging-Tool der Welt, gleich nach den print Anweisungen, die überall im Code verstreut sind. Unsere Werkzeuge, Prozesse und Technologien haben sich in den letzten zwei Jahrzehnten verbessert und erfordern neue Methoden und Denkmuster. Wie wir bereits in der Einleitung erwähnt haben, haben moderne Architekturen wie Microservices die klassischen Methoden des Profilings, Debuggens und Überwachens grundlegend verändert. Verteiltes Tracing steht bereit, um diese Probleme zu lindern und die Lücken zu schließen, die wir mit unseren Tools zerstört haben.

Es gibt nur ein Problem: Verteiltes Tracing kann schwierig sein. Warum ist das so? Drei grundlegende Probleme treten in der Regel auf, wenn du versuchst, mit verteiltem Tracing anzufangen.

Erstens: musst du in der Lage sein, Trace-Daten zu erzeugen. Die Unterstützung für verteiltes Tracing als Bürger erster Klasse in deiner Laufzeitumgebung ist vielleicht lückenhaft oder gar nicht vorhanden. Möglicherweise ist deine Software nicht so strukturiert, dass sie den für die Ausgabe von Tracing-Daten erforderlichen Instrumentierungscode problemlos akzeptiert. Du verwendest vielleicht Muster, die dem anforderungsbasierten Stil der meisten verteilten Tracing-Plattformen zuwiderlaufen. Oft scheitern verteilte Tracing-Initiativen schon bei der Ankunft an den Herausforderungen, die die Instrumentierung einer bestehenden Codebasis mit sich bringt.

Ein weiteres Problem ist, wie du die von deiner Software erzeugten Trace-Daten sammelst und speicherst. Stell dir Hunderte oder Tausende von Diensten vor, von denen jeder bei jeder Anfrage kleine Stücke von Trace-Daten sendet, möglicherweise Millionen Mal pro Sekunde. Wie erfasst du diese Daten und speicherst sie zur Analyse und zum Abruf? Wie entscheidest du, was und wie lange du es aufbewahrst? Wie passt du die Erfassung deiner Daten an die Anfragen an deine Dienste an?

Und schließlich: Wenn du all diese Daten hast, wie kannst du sie dann nutzen? Wie verwandelst du die rohen Trace-Daten, die du erhältst, in umsetzbare Erkenntnisse und Maßnahmen? Wie kannst du die Trace-Daten nutzen, um anderen Service-Telemetrien einen Kontext zu geben und so den Zeitaufwand für die Fehlerdiagnose zu verringern? Kannst du deine Trace-Daten nicht nur für die Techniker, sondern auch für andere Bereiche des Unternehmens nutzbar machen? Diese und andere Fragen verwirren viele, die versuchen, mit verteiltem Tracing anzufangen.

Das Ergebnis eines verteilten Tracing-Einsatzes ist ein Tool, das dir Einblick in dein tiefes System gewährt und dir die Möglichkeit gibt, leicht zu verstehen, wie einzelne Dienste in einer Anfrage zur Gesamtleistung jeder Anfrage beitragen. Die erzeugten Trace-Daten können nicht nur dazu verwendet werden, die Gesamtform deines verteilten Systems darzustellen (siehe Abbildung 1-1), sondern auch, um die Leistung einzelner Dienste innerhalb einer einzelnen Anfrage anzuzeigen.

Abbildung 1-1. Eine aus verteilten Trace-Daten generierte Service-Map.

Wie in Abbildung 1-2 zu sehen ist, kannst du die Anfragen untersuchen, während sie von den Frontend-Clients zu den Backend-Diensten übertragen werden, und verstehen, wie - und warum - Latenzzeiten oder Fehler auftreten und welche Auswirkungen sie auf die gesamte Anfrage haben. Diese Traces liefern eine Fülle von Informationen, die bei der Behebung von Problemen in der Produktion von unschätzbarem Wert sind, z. B. Metadaten, die angeben, auf welchem Host oder in welcher Region ein bestimmter Dienst läuft. Du kannst diese Trace-Daten nach Belieben durchsuchen, sortieren, filtern, gruppieren und ganz allgemein zerlegen, um Probleme schnell zu beheben oder zu verstehen, wie sich verschiedene Dimensionen auf die Leistung deines Dienstes auswirken.

Abbildung 1-2. Ein Beispiel für eine Anfrage, die von einem Frontend-Webclient initiiert wurde.

Wie kommst du also von hier nach dort? Was brauchst du, um eine erfolgreiche verteilte Rückverfolgung aufzubauen?

Die Bestandteile eines verteilten Suchlaufeinsatzes

Um diese Fragen zu beantworten und dir dabei zu helfen, deine Gedanken zu diesem Thema zu ordnen, haben wir die verteilte Rückverfolgung in drei Hauptbereiche unterteilt, wie auch das Buch gegliedert ist. Diese drei Bereiche bauen aufeinander auf, können aber für verschiedene Personen zu unterschiedlichen Zeiten nützlich sein - du musst auf keinen Fall ein Experte für alle drei Bereiche sein! In jedem Abschnitt findest du hilfreiche Erklärungen, Lektionen und Beispiele, wie du eine verteilte Rückverfolgung in deinem Unternehmen aufbauen und umsetzen kannst, um das Vertrauen in deine Systeme und Software zu stärken.

Instrumentierung, Kapitel 2

Verteiltes Tracing erfordert Traces. Trace-Daten können durch Instrumentierung deiner Dienstprozesse oder durch die Umwandlung vorhandener Telemetriedaten in Trace-Daten erzeugt werden. In diesem Abschnitt erfährst du etwas über Spans, die Bausteine von anforderungsbasierten verteilten Traces, und wie sie von deinen Diensten erzeugt werden können. Wir besprechen den aktuellen Stand der Technik bei Instrumentierungs-Frameworks wie OpenTelemetry, einem weithin unterstützten Open-Source-Projekt, das eine Instrumentierungs-API (und mehr) bietet, mit der du verteiltes Tracing einfach in deine Software einbauen kannst. Außerdem besprechen wir die bewährten Methoden für die Instrumentierung von Legacy-Code und für die Entwicklung auf der grünen Wiese.

Einsatz, Kapitel 5

Sobald du Trace-Daten generierst, musst du sie irgendwo hinschicken. Wenn du Tracing in deinem Unternehmen einsetzen willst, musst du wissen, wo deine Software läuft - für Endnutzer und ihre Clients sowie auf Servern - und wie sie betrieben wird. Du musst wissen, welche Auswirkungen die Erfassung und Speicherung von Trace-Daten auf die Sicherheit, den Datenschutz und die Einhaltung von Vorschriften hat. Möglicherweise musst du Kompromisse eingehen, wenn es darum geht, wie viele Daten aufbewahrt werden und wie viele durch Stichproben verworfen werden. Wir besprechen bewährte Methoden zu all diesen Themen und zeigen dir, wie du schnell eine Tracing-Infrastruktur für dein System einrichten kannst.

Werte schaffen, Kapitel 7

Sobald deine Dienste Trace-Daten erzeugen und du die nötige Infrastruktur zum Sammeln dieser Daten eingerichtet hast, beginnt der eigentliche Spaß! Wie kombinierst du Traces mit deinen anderen Beobachtungsinstrumenten und -techniken wie Metriken und Logs? Wie misst du, was wichtig ist - und wie definierst du überhaupt, was wichtig ist? Verteiltes Tracing bietet dir die Werkzeuge, die du brauchst, um diese Fragen zu beantworten, und wir helfen dir in diesem Abschnitt dabei. Du erfährst, wie du Traces nutzen kannst, um deine Basisleistung zu verbessern, und wie du mit Tracing zu dieser Basisleistung zurückbekommst, wenn die Dinge ins Stocken geraten.

Dennoch bleibt eine Frage offen: Wie verhält sich verteiltes Tracing zu Microservices und verteilten Architekturen im Allgemeinen? Wir haben das in der Einführung angesprochen : Was ist verteiltes Tracing? angeschnitten, aber lasst uns einen Moment abschweifen, um die Beziehung zwischen diesen Dingen zu betrachten.

Verteiltes Tracing, Microservices, Serverless, Oh My!

Es gibt eine bestimmte Denkweise über Microservices, die seit einigen Jahren nicht mehr das "heiße Eisen" im Portfolio der Analysten für die "Top Trends 20XX" ist - nämlich die, dass die Schlacht gewonnen worden ist. Die explodierende Popularität von Cloud Computing, Kubernetes, Containerisierung und anderen Entwicklungstools, die eine schnelle Bereitstellung und Nutzung von Hardware (oder hardwareähnlichen Abstraktionen) ermöglichen, hat die Branche zweifellos verändert. Diese Faktoren können dazu führen, dass man sich mit der Frage "Soll ich Microservices nutzen?" als Narr oder Scharlatan outet.

Treten Sie einen Schritt zurück und schauen Sie sich einige reale Daten an. Zunächst einmal gibt es Hinweise darauf, dass Container in der Produktion nicht so beliebt sind, wie es der Hype vermuten lässt: Nur 25 % der Entwickler nutzen sie in der Produktion.² Viele Entwicklungsorganisationen verwenden für einen Großteil ihrer Arbeit immer noch traditionelle Monolithen. Und warum? Ein Grund könnte ironischerweise der Mangel an zugänglichen verteilten Tracing-Tools sein.

Der Entwickler und Autor Martin Fowler nennt drei Hauptkriterien für die Einführung von Microservices: die Fähigkeit, Hardware schnell bereitzustellen, die Fähigkeit, Software schnell zu verteilen und ein Überwachungssystem, das ernsthafte Probleme schnell erkennt.³ Die Dinge, die wir an Microservices lieben (Unabhängigkeit, Idempotenz usw.), sind auch die Dinge, die sie schwer verständlich machen, vor allem, wenn etwas schief läuft. Serverlose Technologien machen diese Gleichung noch verwirrender, weil sie dir weniger Einblick in die Laufzeitumgebung einer bestimmten Funktion geben und sich oft hartnäckig gegen die Überwachung durch deine Lieblings-Tools wehren.

Wie sollten wir also verteiltes Tracing im Hinblick auf diese Fragen betrachten? Erstens löst das verteilte Tracing die von Fowler aufgeworfene Überwachungsfrage, indem es einen Einblick in den Betrieb deiner Microservice-Architektur ermöglicht. Es ermöglicht dir, kritische Einblicke in die Leistung und den Status einzelner Dienste als Teil einer Kette von Anfragen zu gewinnen, was sonst schwierig oder zeitaufwändig wäre. Verteiltes Tracing gibt dir die Möglichkeit, genau zu verstehen, was ein bestimmter, einzelner Dienst als Teil des Ganzen tut, und ermöglicht es dir, Fragen zur Leistung deiner Dienste und deines verteilten Systems zu stellen und zu beantworten.

Herkömmliche Metriken und Logging allein können nicht mit dem zusätzlichen Kontext mithalten, den das verteilte Tracing bietet. Metriken ermöglichen es dir zum Beispiel, einen Überblick darüber zu bekommen, was mit allen Instanzen eines bestimmten Dienstes passiert, und sie erlauben es dir sogar, deine Abfrage auf bestimmte Gruppen von Diensten einzugrenzen, aber sie schlagen nicht auf die unendliche Kardinalität von .⁴

Logs hingegen liefern extrem detaillierte Informationen über einen bestimmten Dienst, haben aber keine eingebaute Möglichkeit, diese Informationen im Kontext einer Anfrage bereitzustellen. Während du Metriken und Protokolle nutzen kannst, um Probleme in deinem verteilten System zu entdecken und zu beheben, liefert verteiltes Tracing einen Kontext, der dir hilft, den Suchraum einzugrenzen, der erforderlich ist, um die Ursache eines Vorfalls zu finden, während er auftritt (wenn jeder Moment zählt).

Wie wir bereits in der Einleitung erwähnt haben, kann der Versuch, eine komplexe, auf Microservices basierende verteilte Architektur zu verwalten und zu verstehen, zu Stress und Burnout führen. Wenn du darüber nachdenkst, auf Microservices umzusteigen, dich mitten in der Umstellung von einem Monolithen auf Microservices befindest oder bereits mit einer riesigen Microservice-Architektur zurechtkommen musst, dann erlebst du diesen Stress vielleicht auch, wenn du darüber nachdenkst, wie du den Zustand und die Leistung deiner Software verstehen kannst. Verteiltes Tracing ist zwar kein Allheilmittel, aber als Teil einer größeren Beobachtungsstrategie kann es zu einem entscheidenden Bestandteil für den Betrieb zuverlässiger verteilter Systeme werden.

Die Vorteile der Rückverfolgung

Welche konkreten Vorteile kannst du mit verteiltem Tracing erzielen? Darüber werden wir im weiteren Verlauf des Buches sprechen, aber lassen Sie uns zunächst die Quick Wins auf höchster Ebene betrachten:

• Verteiltes Tracing kann die Art und Weise, wie du Software entwickelst und bereitstellst, verändern, daran besteht kein Zweifel. Sie hat nicht nur Vorteile für die Softwarequalität, sondern auch für die Gesundheit deines Unternehmens.

• Verteiltes Tracing kann die Produktivität von Entwicklern und deine Entwicklungsleistung verbessern. Es ist der beste und einfachste Weg für Entwickler, das Verhalten von verteilten Systemen in der Produktion zu verstehen. Mit verteiltem Tracing verbringst du weniger Zeit mit der Fehlersuche und -behebung in einem verteilten System als ohne und entdeckst Probleme, von denen du sonst nicht wüsstest, dass du sie hast.

• Verteiltes Tracing unterstützt die moderne polyglotte Entwicklung. Da verteiltes Tracing unabhängig von deiner Programmiersprache, deinem Monitoring-Anbieter und deiner Laufzeitumgebung ist, kannst du einen einzigen Trace von einem iOS-nativen Client über einen C++ High-Performance-Proxy, ein Java- oder C#-Backend bis hin zu einer Web-Scale-Datenbank und wieder zurück übertragen - alles an einem einzigen Ort und mit einem einzigen Tool visualisiert. Kein anderes Tool-Set bietet dir diese Freiheit und Flexibilität.

• Verteiltes Tracing reduziert den Aufwand für Einsätze und Rollbacks, indem es dir einen schnellen Überblick über Änderungen verschafft. Dadurch wird nicht nur die durchschnittliche Zeit bis zur Lösung von Problemen verkürzt, sondern auch die Zeit bis zur Markteinführung neuer Funktionen und die durchschnittliche Zeit bis zur Erkennung von Leistungseinbrüchen. Dies verbessert auch die Kommunikation und die Zusammenarbeit zwischen den Teams, da deine Entwickler nicht auf einen bestimmten Monitoring-Stack für ihren Teil des Kuchens beschränkt sind - alle, von den Frontend-Entwicklern bis zu den Datenbank-Nerds, können dieselben Daten einsehen, um zu verstehen, wie sich Änderungen auf das gesamte System auswirken.

Den Tisch decken

Nach all dem hoffen wir, dass wir deine Aufmerksamkeit haben! Fassen wir noch einmal zusammen:

• Verteiltes Tracing ist ein Werkzeug, das die Erstellung von Profilen und die Überwachung verteilter Systeme mit Hilfe von Traces ermöglicht, also Daten, die Anfragen darstellen, während sie durch ein System fließen.

• Verteiltes Tracing ist unabhängig von der Programmiersprache, der Laufzeit oder der Einsatzumgebung und kann für fast jede Art von Anwendung oder Dienst verwendet werden.

• Verteiltes Tracing verbessert die Teamarbeit und Koordination und verkürzt die Zeit, um Leistungsprobleme in deiner Anwendung zu erkennen und zu beheben.

Um diese Vorteile nutzen zu können, brauchst du zunächst einige Trace-Daten. Dann musst du sie sammeln, und schließlich musst du sie analysieren. Fangen wir also am Anfang an und sprechen über die Instrumentierung deines Codes für verteiltes Tracing.

¹ [Mic13]

² [Sta19]

³ [Fow14]

⁴ Kardinalität ist ein mathematischer Begriff, der sich auf die Anzahl der Elemente in einer Menge oder Gruppe bezieht. Im Zusammenhang mit Metriken ist es die Anzahl der eindeutigen Kombinationen von Metriknamen und Schlüssel/Wertattributen, die mit diesen Namen verbunden sind. Darauf werden wir in späteren Kapiteln näher eingehen.