Verschaffen Sie sich einen umfassenden Einblick in Ihre verteilte Architektur.

Beheben Sie Fehler in Ihrer verteilten Architektur mit Leichtigkeit. Beseitigen Sie Engpässe mit einer reduzierten durchschnittlichen Lösungszeit (MTTR).

Was ist Distributed Tracing?

Distributed Tracing ist ein Verfahren zur Ermittlung von Fehlern in Ihrer Microservice-Architektur. Um die Relevanz von Distributed Tracing zu verstehen, müssen wir zunächst wissen, wie eine verteilte Architektur oder eine Microservice-Architektur funktioniert.

How microservices work: Site24x7

Microservices verstehen

Microservices sind schwach gekoppelte, unabhängige Dienste, die gemeinsam an der Ausführung einer Funktion oder einer Anforderung beteiligt sind. Die Kommunikation zwischen einzelnen Diensten erfolgt über miteinander verbundene APIs. Da jeder Dienst unabhängig arbeitet, sind die Abhängigkeiten zwischen den Diensten geringer, was die Skalierbarkeit und die schnellere Bereitstellung von Code begünstigt.

Engpässe identifizieren und beseitigen

Komplexe Anwendungen bringen jedoch meist komplexe Probleme mit sich. In einer Microservice-Architektur ist es bei Auftreten eines Fehlers aufgrund der miteinander verbundenen Dienste oft schwierig, die Ursache des Fehlers zu ermitteln. Anstatt nach einer Lösung für den Fehler zu suchen, wird die Fehlersuche selbst zur Herausforderung.

Es ist nicht hilfreich, nur die Ursache zu betrachten, wenn nicht genügend Kontext vorhanden ist. Da jeder Dienst unabhängig ist, kann das Korrelieren der Protokolle, Kennzahlen und Traces der beteiligten Dienste und das Eingrenzen des genauen Problems mehr Zeit und Aufwand erfordern als erwartet.

An dieser Stelle ist Distributed Tracing sehr hilfreich.

Error in distributed architecture: Site24x7 APM
Distributed tracing with Site24x7 APM

So funktioniert Distributed Tracing

Mit Distributed Tracing können Sie den genauen Ablauf eines Fehlers in einer komplexen Architektur ermitteln. Dabei werden die Anwendungstransaktionen mit Hilfe von Anforderungs- und Antwort-Headern aufgezeichnet.

Ein Trace-Header wird von der ursprünglichen Anforderung zu nachfolgenden Anforderungen hinzugefügt und erzeugt so eine Verbindung innerhalb der gesamten Transaktion, die bis zum Ursprung zurückverfolgt werden kann.

Anwendungsfall in Echtzeit

Eine Zahlungstransaktion kann beispielsweise aus verschiedenen Gründen fehlgeschlagen sein, z. B. aufgrund einer falschen Benutzereingabe, eines Problems im Zahlungsportal oder eines Ausfalls einer Datenbankkomponente im Backend.

Um die Ursache eines Fehlers zu ermitteln, müssen die Daten über alle miteinander verbundenen Dienste hinweg korreliert werden, die an der entsprechenden Transaktion beteiligt sind. Während das Durchsuchen von Protokollen mit dem Abgleich von Zeitstempeln und Daten in allen Diensten Stunden in Anspruch nehmen kann, verfolgt das Distributed Tracing den API-Fluss in allen Diensten und erleichtert die Identifizierung der Ursache eines einzelnen Transaktionsfehlers.

Distributed Tracing: Site24x7 APM Insight