Verteilte Nachverfolgung: Vergangenheit, Gegenwart und Zukunft

Distributed Tracing ist ein umstrittenes Thema. Einst der Doyen jeder KubeCon , sollte die Technologie die Beobachtbarkeit revolutionieren.

Fünf Jahre später hat der Hype etwas nachgelassen, es wird viel mehr über den Schmerz geredet und die Akzeptanz ist mäßig. Unterdessen gibt es weiterhin stetige Aktivitäten rund um den Ausbau und die Standardisierung der Technologie – Open Telemetry (basierend auf OpenTracing) ist nach Kubernetes das zweitgrößte CNCF-Projekt . Was hat es also mit Distributed Tracing auf sich? Soll man es gleich umsetzen oder abwarten?

In diesem Artikel wollen wir uns eingehend mit der verteilten Ablaufverfolgung befassen

1. Was ist das Besondere an Distributed Tracing und warum brauchen wir es?
2. Welche Probleme gibt es heute beim verteilten Tracing?
3. Was sind die bevorstehenden Entwicklungen und wie begegnen sie bestehenden Herausforderungen?

Einführung – Funktionsweise der verteilten Ablaufverfolgung

Für Uneingeweihte: Distributed Tracing ist eine Technologie, die es uns ermöglicht, eine einzelne Anfrage zu verfolgen, während sie mehrere verschiedene Komponenten/Microservices einer verteilten Umgebung durchläuft. Jeder im Anforderungspfad getätigte Netzwerkaufruf wird erfasst und als Spanne dargestellt.

Um dies zu ermöglichen, fügen verteilte Tracing-Tools einen eindeutigen Trace-Kontext (Trace-ID) in den Header jeder Anforderung ein und implementieren Mechanismen, um sicherzustellen, dass der Trace-Kontext über den gesamten Anforderungspfad weitergegeben wird.

Wie ein verteilter Trace einen Anforderungspfad darstellt

Warum wir Distributed Tracing überhaupt brauchen

Das Besondere an der verteilten Ablaufverfolgung ist, dass sie sich auf eine Anfrage als Einheit für die Beobachtbarkeit konzentriert. In einer Überwachungs-/Metrikplattform ist eine Komponente (z. B. ein Dienst, ein Host) die grundlegende Einheit, die beobachtet wird. Man kann diesen Plattformen Fragen zum Verhalten dieser Einheit als Ganzes im Laufe der Zeit stellen. Wie hoch ist beispielsweise der Zustand/Durchsatz/Fehlerrate dieses Dienstes in einem bestimmten Zeitraum?

Bei Protokollen ist die beobachtete Grundeinheit ein Ereignis . Wenn beispielsweise während der Codeausführung ein Ereignis auftritt, werden einige Informationen ausgegeben. Diese „Ereignisse“ werden von Entwicklern beim Schreiben von Code subjektiv definiert. Die Herausforderung bei Protokollen besteht darin, dass sie alle unzusammenhängend sind und jede Komponente isoliert ihre eigene Form von Protokollmeldungen ausgibt und es keine einfache Möglichkeit gibt, sie sinnvoll miteinander zu verbinden.

Im Gegensatz dazu wird beim verteilten Tracing eine einzelne Anforderung beobachtet, die mehrere Komponenten durchläuft. Dadurch können wir Fragen zum verteilten System als Ganzes stellen und verstehen, was wo in einem komplexen, vernetzten System passiert ist.

Das Hauptargument für die verteilte Ablaufverfolgung liegt darin, dass diese Orientierung an Anfragen der Erfahrung des Endbenutzers am nächsten kommt. Und daher ist es auch die intuitivste Art und Weise, wie wir verteilte Architekturen untersuchen und Fehler beheben möchten.

Die Entwicklung des verteilten Tracings

Distributed Tracing hat aufgrund der weit verbreiteten Einführung verteilter Softwarearchitekturen im letzten Jahrzehnt an Bedeutung gewonnen.

Die moderne, auf Microservices basierende Architektur ist eine Weiterentwicklung der Internet-Wachstumsgeschichte der späten 90er Jahre, als die Verwendung von Request-Response- Systemen üblich wurde.

„Mit den späten 90er Jahren und dem explosionsartigen Wachstum des Internets kam es zu einer enormen Verbreitung von Anfrage-Antwort-Systemen , wie z. B. zweistufigen Websites mit einem Webserver-Frontend und einem Datenbank-Backend … Anfragen waren eine neue Dimension für die Überlegungen zu Systemen , orthogonal zu einer Maschine oder einem Prozess insgesamt.

- Verteilte Nachverfolgung in der Praxis, O'Reilly Media

In diesen Microservices-Architekturen trifft jede einzelne Anfrage letztendlich auf viele (Zehner oder sogar Hunderte von Microservices) und führt dazwischen mehrere Netzwerkaufrufe aus. Nachfolgend finden Sie Informationen zur Microservices-Architektur von Uber, die über 3000 Dienste umfasst.

Ubers Microservices-Architektur aus dem Jahr 2018. Quelle: https://www.uber.com/en-IN/blog/microservice-architecture/

In solch komplexen Systemen wird die verteilte Ablaufverfolgung für jede Form der Fehlerbehebung von entscheidender Bedeutung. Daher wurde Distributed Tracing von großen Unternehmen entwickelt, die als Frühanwender große, komplexe, verteilte Umgebungen nutzten.

• Das 2010 veröffentlichte Dapper-Papier von Google war der Beginn des verteilten Tracings

  
  

• In den nächsten Jahren stellten zwei weitere Unternehmen ihre eigenen verteilten Rückverfolgungssysteme als Open-Source-Lösung zur Verfügung (Twitter veröffentlichte Zipkin im Jahr 2012 und Uber veröffentlichte Jaeger im Jahr 2017). Zipkin und Jaeger gehören auch heute noch zu den beliebtesten verteilten Tracing-Tools

  
  

• Seit 2016 werden im Rahmen des OpenTracing-Projekts erhebliche Anstrengungen unternommen, um die verteilte Ablaufverfolgung über Komponenten hinweg zu standardisieren. Aus OpenTracing wurde schließlich 2019 OpenTelemetry . OpenTelemetry erfreut sich großer Beliebtheit und hat weltweit Tausende von Mitwirkenden

  
  

• Mittlerweile wird Distributed Tracing neben Metriken und Protokollen allgemein als dritte „Säule“ der Beobachtbarkeit angesehen. Die meisten großen Überwachungs- und Observability-Anbieter bieten als Teil ihrer Produkte verteilte Tracing-Tools an.

Stand der verteilten Nachverfolgung: Theorie vs. Realität

Doch trotz des Versprechens, der Begeisterung und der Bemühungen der Community liegt die Akzeptanz von Distributed Tracing heute bei etwa etwa 25 %. Es ist nicht ungewöhnlich, dass Unternehmen auf Microservices-Architekturen mit Protokollen und Metriken auskommen, obwohl sie eindeutig verteiltes Tracing benötigen.

Gleichzeitig nimmt die durchschnittliche Zeit bis zur Behebung von Produktionsfehlern weltweit zu. 73 % der Unternehmen geben an, dass die Lösung von Produktionsproblemen heute über eine Stunde dauert .

Fragen Sie einen Entwickler, was die schmerzhaftesten Momente in seinem Leben sind, und er wird über die Zeit sprechen, die er mit dem Debuggen eines Sev-1-Fehlers in der Produktion verbracht hat, während ihm gefühlt ein paar hundert Leute im Nacken sitzen.

Es scheint also, dass jedes Unternehmen, dem seine MTTR am Herzen liegt (was fast jedes Unternehmen ist), verteiltes Tracing verwenden sollte, und die Akzeptanz dürfte in diesem Umfeld sprunghaft angestiegen sein. Aber die tatsächlichen Zahlen stützen das nicht – was gibt es also?

Herausforderungen beim verteilten Tracing heute

Heutzutage gibt es beim verteilten Tracing mehrere Probleme, die Unternehmen überwinden müssen, um einen Mehrwert zu erzielen – die alle im Mainstream-Narrativ nicht so ausführlich diskutiert werden.

1. Die Umsetzung ist schwierig!

Um heute verteiltes Tracing in einem Dienst zu implementieren, müssen wir eine Codeänderung und eine Veröffentlichung vornehmen. Während das Vornehmen von Codeänderungen eine häufige Anforderung an die Beobachtbarkeit ist, besteht die Herausforderung speziell beim verteilten Tracing darin, dass jeder Dienst oder jede Komponente instrumentiert werden muss, um einen verteilten Trace zu erhalten, sonst wird der Trace unterbrochen.

Man kann nicht einfach mit einem einzelnen Dienst beginnen – wie das bei der Überwachung oder Protokollierung der Fall ist – und einen Nutzen daraus ziehen. Für die verteilte Ablaufverfolgung ist eine Instrumentierung über einen gesamten Satz von Diensten hinweg erforderlich, um nutzbare Ablaufverfolgungen zu generieren.

Dies erfordert eine Koordination zwischen mehreren Teams und Serviceeigentümern, um Änderungen an ihren Services vorzunehmen. Es wird also zu einem organisatorischen Problem – stellen Sie sich vor, Hunderte von Teams müssten ihre Dienste über mehrere Monate hinweg instrumentieren, bevor Sie einen Mehrwert realisieren könnten.

Dies ist heute die größte Herausforderung beim verteilten Tracing.

2. Notwendigkeit komplexer Stichprobenentscheidungen

Darüber hinaus kann die Menge der durch Distributed Tracing generierten Trace-Daten überwältigend sein. Stellen Sie sich Hunderte von Diensten vor, von denen jeder für jede einzelne Anfrage eine kleine Menge an Trace-Daten ausgibt. Dabei handelt es sich um Millionen von Anfragen pro Sekunde, was die verteilte Ablaufverfolgung sowohl im Hinblick auf den Speicher als auch auf die Netzwerkbandbreite teuer macht.

Auch wenn die Protokollierung dasselbe bewirkt (und pro Anfrage mehr Daten ausgibt, die dann von umfangreichen Protokollaggregationstools verwaltet werden), besteht der Unterschied darin, dass die meisten Unternehmen heute bereits über eine Protokollierung verfügen . Die Einführung eines weiteren Datentyps, der fast so umfangreich sein wird wie die Protokollierung, ist eine gewaltige Aufgabe und wird wahrscheinlich die Ausgaben verdoppeln.

Um dieses Kostenproblem in den Griff zu bekommen, verwenden heute alle verteilten Rückverfolgungssysteme Stichproben und zeichnen nur eine Teilmenge der Spuren auf. Die heute in der Praxis üblichen Abtastraten liegen zwischen 0,1 % und 2 %. Der Grundgedanke ist, dass bereits 1 % der Stichproben ausreicht, um ein anständiges Gesamtbild der Leistungsengpässe zu liefern.

Auf den meisten Plattformen können Kunden heute ihre Sampling-Strategie wählen und ihre eigenen Kosten-Transparenz-Kompromisse eingehen. Dieser Entscheidungsprozess erhöht jedoch den ohnehin schon komplexen Aufwand für die Instrumentierung und Verwaltung eines verteilten Rückverfolgungssystems.

3. Aber das Sampling verringert den Wert erheblich

Nehmen wir an, ein Unternehmen macht sich die Mühe, jeden Service/jede Komponente zu instrumentieren und entscheidet dann über die Sampling-Strategie, um sicherzustellen, dass es nicht die Bank sprengt.

Was nun – ist mit einem drastischen Rückgang der MTTR zu rechnen? Nein, denn Entwickler können die verteilte Ablaufverfolgung aufgrund der Stichprobenerhebung nicht zur tatsächlichen Fehlerbehebung verwenden.

Stellen Sie sich die Erfahrung eines Entwicklers vor: „Ich kann das Problem , von dem ich weiß, dass es existiert, nicht finden. Ich habe den Fehler generiert, aber ich kann die entsprechende Ablaufverfolgung nicht finden.“

Was passiert also? Entwickler vertrauen nicht mehr auf die Qualität verteilter Tracing-Daten und kehren zu ihren regulären Methoden zum Debuggen/Fehlerbeheben zurück (z. B. mithilfe von Protokollen).

4. Die Nutzung durch Entwickler ist selten

Angesichts dieser Einschränkungen wird Distributed Tracing heute hauptsächlich als Möglichkeit zur Behebung von Leistungsproblemen verkauft.

Denken Sie daran, dass ein einfacher verteilter Trace uns eigentlich nur sagt, wer wen angerufen hat und wie lange die einzelnen Zeitspannen gedauert haben. Verteilte Ablaufverfolgungen sagen uns nicht , was innerhalb des Dienstes passiert ist , das den Fehler/die hohe Latenz verursacht hat. Dazu müssen sich Entwickler noch die Protokollmeldung ansehen und/oder das Problem lokal reproduzieren, um es zu debuggen.

In einem typischen Unternehmen machen Leistungsprobleme wahrscheinlich weniger als 10 % der Gesamtleistung aus. In Wirklichkeit ist die verteilte Ablaufverfolgung also nur für diesen kleinen Teil der Probleme nützlich.

Der durchschnittliche Entwickler, der einen Dienst ausliefert und besitzt, nutzt ein verteiltes Tracing-Tool vielleicht zwei bis drei Mal pro Jahr.

Auswirkungen all dieser Herausforderungen

In Summe:

1. Die verteilte Ablaufverfolgung ist schwer zu implementieren
2. Distributed Tracing erfordert umfangreiche Stichproben, um die Kosten zu kontrollieren
3. Durch die Probenahme wird der Wert jedoch erheblich gemindert
4. Daher verwenden Entwickler die Ablaufverfolgung nur für den einen oder anderen einmaligen Leistungsanwendungsfall

All dies macht die ROI-Argumente für verteiltes Tracing ziemlich unklar.

In einem typischen Hype-Zyklus können wir sagen, dass wir das Stadium der überzogenen Erwartungen nun hinter uns gelassen haben und sich allmählich Ernüchterung breit macht.

Wenn wir jedoch im Endzustand denken und die Zukunft der Computersysteme verteilt ist, dann ist die verteilte Ablaufverfolgung natürlich der grundlegendste Vektor für die Beobachtbarkeit. In dieser Welt nutzt jedes Unternehmen mit einer verteilten Architektur Tracing als primären Mechanismus zur Fehlerbehebung bei Problemen in der Produktion – echte „Beobachtbarkeit“ – im Gegensatz zur passiven Überwachung von Systemen, die wir heute haben.

Bevor wir jedoch diesen Endzustand erreichen können, müssen wir gegenüber dem Status quo einige Verbesserungen vornehmen. Die gute Nachricht ist, dass vieles davon bereits im Gange ist. Schauen wir uns jeden von ihnen an. Was können wir also in Zukunft erwarten?

Zukunft der verteilten Ablaufverfolgung

Sofortige Instrumentierung ohne Codeänderungen

Stellen Sie sich vor, Sie setzen einen Agenten ein und könnten ein gesamtes verteiltes System (alle Dienste, Komponenten) auf einmal abdecken, ohne dass Codeänderungen erforderlich sind.

Dies scheint in den nächsten 2-3 Jahren realistischerweise möglich.

Die Auto-Instrumentierungsbibliotheken von OpenTelemetry ermöglichen dies bereits für einige Programmiersprachen (jedoch nicht in kompilierten Sprachen wie Go). Parallel dazu entwickeln sich Technologien wie eBPF weiter, um eine systemweite Instrumentierung ohne Codeänderung zu ermöglichen . Davon abgesehen können wir mit Sicherheit davon ausgehen, dass das Instrumentierungsproblem in einigen Jahren gelöst sein wird.

Die Stichprobenerhebung weicht der KI-basierten Auswahl von Interessensanfragen

In einer LLM-Welt wirkt die Zufallsstichprobe wie ein Relikt aus dem dunklen Zeitalter. Im Idealfall sollten wir in der Lage sein, 100 % der Spuren zu untersuchen, alles zu identifizieren, was ungewöhnlich aussieht, und dies für zukünftige Untersuchungen zu speichern. Keine Zufallsstichproben mehr.

Wenn wir darüber nachdenken, interessieren uns die ca. 95 % „glücklichen Anfragen“ nicht wirklich. Wir kümmern uns nur um etwa 5 % der anomalen Spuren – Fehler, Ausnahmen, hohe Latenz oder irgendeine Form von Soft Errors. Wir brauchen also nur eine Möglichkeit, 100 % zu betrachten und die interessanten 5 % herauszusuchen.

Es gibt Mechanismen wie Tail-based Sampling , die heute darauf abzielen. Beim Tail-basierten Sampling wartet das System, bis alle Spans in einer Anfrage abgeschlossen sind, und entscheidet dann auf der Grundlage des vollständigen Trace, ob dieser beibehalten werden muss.

Die größte Herausforderung beim Tail-basierten Sampling besteht darin, dass Sie alle Spannen eines Trace speichern müssen, bis die gesamte Anforderung abgeschlossen ist, und dann entscheiden müssen, ob Sie den Trace behalten oder verwerfen möchten. Das bedeutet, dass wir jede einzelne Anfrage mit allen Spans für einen bestimmten Zeitraum speichern (bis die Anfrage abgeschlossen ist) – dies erfordert eine separate Datenarchitektur mit Komponenten für Lastverteilung, Speicherung und Verarbeitung, was sehr komplex und teuer ist.

OpenTelemetry verfügt über einen Tail-basierten Sampling-Kollektor , dieser ist jedoch noch nicht ausgereift und weist mehrere Skalierbarkeitsprobleme auf (aufgrund des oben genannten Problems). Mittlerweile arbeiten mehrere Unternehmen, darunter ZeroK.ai , daran, mithilfe von KI die Anomalieerkennung effizient und skalierbar zu machen.

Angesichts der schnellen Entwicklung in diesem Bereich können wir davon ausgehen, dass dieses Problem in den nächsten drei bis fünf Jahren ebenfalls gelöst wird.

Das Aufkommen „reicher“ verteilter Spuren, die das gesamte Debuggen ermöglichen

Ein echter Sprung in die nächste Generation der Ablaufverfolgung wird sein, wenn sich die Ablaufverfolgung von „nur Leistungsproblemen“ zu „alle Problemen“ entwickelt. Dann kommt die wahre Kraft der verteilten Nachverfolgung zum Vorschein.

Damit dies möglich ist, muss jede Spur über einen umfassenden Kontext verfügen.

Stellen Sie sich ein Szenario vor, in dem jeder Span in jeder Ablaufverfolgung Folgendes aufweist:

• Anfrage- und Antwortnutzlasten (mit PII-Maskierung)

• Stack-Traces für alle Ausnahmen

• Protokolle

• Kubernetes-Ereignisse

• Pod-Zustände

• Und alles andere, was in dieser Zeitspanne passiert ist

  
  

Alles in einem integrierten, nahtlosen Ablauf.

Und stellen Sie sich vor, dass die gesuchte Spur ganz einfach zu finden ist – es gibt keine stichprobenbedingten Datenlücken, Probleme werden dedupliziert und gruppiert und können über mehrere Dimensionen gefiltert werden.

Das ist also alles, was ein Entwickler braucht, um ein Softwareproblem zu beheben. Und möglicherweise alles, was ein KI-Modell braucht, um eine Diagnose zu stellen und einen Entwickler darauf hinzuweisen, was schief läuft.

In dieser Welt wird die Spur zur primären Achse für die Beobachtbarkeit und ersetzt die Protokollierung . So könnte der Endzustand des verteilten Tracings aussehen – obwohl er noch nicht da ist, ist er von unserem heutigen Standort aus sichtbar.

Das Haupthindernis, dies zu ermöglichen, ist die Explosion des Datenvolumens, die durch die Speicherung all dieser Kontextdaten verursacht wird. Um dies zu ermöglichen, sind tiefgreifende Innovationen in den Datenverarbeitungs- und Speicherarchitekturen erforderlich. Es ist noch früh und wir müssen abwarten, was hier passiert.

Zusammenfassung

Zusammenfassend ist Distributed Tracing eine notwendige und intuitive Sichtweise, die erforderlich ist, um verteilte Anwendungsarchitekturen in der Produktion beobachten zu können.

Die erste Generation der verteilten Nachverfolgung war zwar vielversprechend, war jedoch mit mehreren Herausforderungen verbunden, die es für Unternehmen schwierig machten, einen Nutzen aus der Nachverfolgung zu ziehen, was die Einführung etwas behinderte.

Es gibt jedoch mehrere spannende Entwicklungen in diesem Bereich, die die Rückverfolgung voraussichtlich einfacher, einfacher und leistungsfähiger machen werden als das, was wir heute haben, und die Beobachtbarkeit in Zukunft nahtloser gestalten.