Verteiltes Tracing

Wo verbringt eine langsame Anfrage tatsächlich ihre Zeit? Die Response Time Ihrer Web-App sieht normal aus, die Datenbank ist ruhig, und die Anfrage dauert trotzdem vier Sekunden. Eine einzelne Anfrage kann sich bei einem Service authentifizieren, Daten aus einer internen API laden, einen Background-Job einreihen und eine Zahlungs-API eines Drittanbieters aufrufen, bevor die Antwort zurückkommt. Ist sie langsam oder schlägt sie fehl, liegt die Ursache oft in einem anderen Service als dem, der das Problem gemeldet hat. Verteiltes Tracing verfolgt diese Anfrage über diese Grenzen hinweg und führt die Arbeit aller beteiligten Services in einem Trace zusammen, sodass Sie den gesamten Weg sehen, statt ihn aus den Daten jedes einzelnen Service selbst zusammenzusetzen. Stellen Sie es sich wie einen Gruppenchat vor: Jeder Service antwortet im selben Thread, sodass sich die Anfrage wie eine einzige Unterhaltung liest statt wie fünf getrennte Chats.

​

Was ist verteiltes Tracing?

Wenn jeder Service für sich selbst berichtet, sehen Sie, dass eine Web-Action langsam ist, aber nicht, dass ein Inventory-Service weiter unten in der Aufrufkette die Ursache war. In AppSignal ist jeder dieser Services eine eigene App oder ein eigener Namespace. Um eine Anfrage über sie hinweg zu verfolgen, müssen Sie jede einzeln öffnen und die Zeitstempel abgleichen. Verteiltes Tracing entfernt diese Grenzen. Während eine Anfrage von einem Service zum nächsten wandert, markiert jeder Service seine Arbeit mit derselben Trace-ID und speichert, von welcher Arbeit sie aufgerufen wurde. AppSignal nutzt diese IDs, um den vollständigen Weg der Anfrage über alle beteiligten Services hinweg zu rekonstruieren. Mit einem verteilten Trace können Sie:

• Eine Anfrage von ihrem Einstiegspunkt bis zu jedem erreichten Service verfolgen.
• Sehen, wohin die Zeit geflossen ist, selbst wenn der langsame Teil in einem anderen Service oder einer anderen Anwendung läuft.
• Herausfinden, in welchem Service ein Fehler entstanden ist, nicht nur, wo er sichtbar wurde.

​

Spans, Traces und Services

AppSignal beschreibt einen Trace anhand von drei Bausteinen.

• Span: eine einzelne Arbeitseinheit, etwa eine eingehende HTTP-Anfrage, eine Datenbankabfrage, ein Aufruf an einen anderen Service oder ein Codeblock, den Sie selbst instrumentieren. Ein Span hat einen Namen, eine Dauer und Attribute, und er erfasst den Span, der ihn gestartet hat. Spans sind die kleinste Einheit, aus der ein Trace besteht.
• Trace: alle Spans, die zu einem durchgängigen Vorgang gehören. Da jeder Span seinen Parent-Span kennt, bilden die Spans in einem Trace einen Baum, der die Anfrage von Anfang bis Ende beschreibt.
• Service: eine benannte Komponente, die an einem Trace beteiligt ist, etwa eine Web-App, ein Background-Worker oder eine interne API. Sie benennen einen Service mit der Option service_name (oder der Umgebungsvariable APPSIGNAL_SERVICE_NAME), und AppSignal nutzt diesen Namen, um Services innerhalb eines Trace zu unterscheiden. Ein einzelner Trace erstreckt sich meist über mehrere Services, und diese Services können an unterschiedliche AppSignal-Anwendungen berichten.

Innerhalb von AppSignal ist ein Trace eine Art Sample: die detaillierte Aufzeichnung einer Anfrage, gespeichert, damit Sie sie öffnen und Span für Span nachvollziehen können. AppSignal leitet Ihre Performance-Metriken, etwa Response Time und Throughput, aus diesen Traces ab, sodass ein Performance-Diagramm und ein einzelner Trace zwei Ansichten derselben Daten sind.

​

Verfügbarkeit und Einrichtung

Verteiltes Tracing ist zunächst für Python, Ruby und PHP verfügbar. Andere Sprachen, etwa Elixir und JavaScript, werden noch nicht unterstützt. Ob Sie etwas aktivieren müssen, hängt davon ab, wie Ihre Integration an AppSignal berichtet. Python und Ruby können entweder über den in der Integration enthaltenen Agent oder über einen Collector berichten, daher muss der Collector-Modus konfiguriert werden. PHP und ein individuelles OpenTelemetry-Setup berichten stets nur über einen Collector, daher gibt es hier nichts zu aktivieren.

• Python und Ruby: Setzen Sie die Option collector_endpoint auf die URL eines gehosteten statt eines selbst gehosteten Collectors. Der Unterschied zwischen beiden wird unter Collector-Konfiguration für Python, Collector-Konfiguration für Ruby und Gehostete vs. selbst gehostete Collector erklärt.
• PHP: nichts zu konfigurieren. Das PHP-Paket berichtet bereits über einen Collector, daher funktioniert verteiltes Tracing, sobald Ihre App an AppSignal berichtet.
• Ein individuelles OpenTelemetry-Setup: nichts zu konfigurieren. Der Export an einen Collector ist die einzige Art, wie diese Setups berichten, daher verbinden sich Traces von selbst.

Verteiltes Tracing basiert auf OpenTelemetry und ist daher nicht auf die oben genannten Integrationen beschränkt. Jede mit OpenTelemetry instrumentierte Anwendung kann einem Trace beitreten, indem sie ihre Daten an einen gehosteten Collector exportiert. Das können Sie über eine AppSignal-Integration wie das PHP-Paket tun oder über ein individuelles OpenTelemetry-SDK-Setup.

​

Wie funktioniert es in AppSignal?

AppSignal baut verteilte Traces auf OpenTelemetry auf, das den Teil übernimmt, der verteiltes Tracing überhaupt erst möglich macht: die Kontextweitergabe. Wenn ein instrumentierter Service einen anderen Service aufruft, hängt OpenTelemetry die Trace-ID und den aufrufenden Span an den ausgehenden Aufruf an. Sie reist als Header auf einer HTTP-Anfrage oder als Metadaten auf einem eingereihten Job mit, und der empfangende Service liest sie aus und setzt denselben Trace fort. Jeder Service berichtet den Teil des Trace, für den er verantwortlich ist, seinen sogenannten Subtrace. AppSignal empfängt diese Subtraces unabhängig voneinander, oft von unterschiedlichen Prozessen oder Hosts, und setzt sie anhand der gemeinsamen Trace-ID sowie der Parent- und Child-Beziehungen zwischen den Spans zu einem Trace zusammen. Sie konfigurieren die Verbindung zwischen Services nie von Hand. Ist eine Bibliothek instrumentiert, treten ihre Aufrufe dem Trace automatisch bei. AppSignal samplet Traces, statt jeden einzelnen zu behalten, und trifft diese Entscheidung serviceübergreifend: Wird ein Trace behalten, wird auch die Arbeit aller darin enthaltenen Services behalten, sodass der Trace vollständig ankommt statt als verstreute Fragmente. Das Sampling bevorzugt die Traces, die Sie am ehesten sehen möchten: die mit Fehlern und die langsamsten Anfragen. An den Rändern können weiterhin Lücken entstehen, wenn ein Service nicht berichtet oder seine Daten zu spät eintreffen. Das Ergebnis erkunden Sie auf der Trace-Seite auf zwei Arten: der Service Map, die die Services im Trace und die Aufrufe zwischen ihnen zeigt, und der Trace-Zeitleiste, die jeden Span zeitlich anordnet. Die Trace-Seite erklärt, wie Sie beide lesen.

​

Anwendungsübergreifende Unterstützung

Ein Service in AppSignal ist nicht dasselbe wie eine Anwendung. Mehrere Services können an eine AppSignal-Anwendung berichten, und ein einzelner Trace kann auch Services überspannen, die zu vollständig getrennten Anwendungen gehören. Zum Beispiel könnten eine Web-App, ein Inventory-Service und ein Audit-Service alle an eine AppSignal-Anwendung berichten, jeweils unter ihrem eigenen Servicenamen, während ein weiterer Service als eigene Anwendung berichtet. Eine einzelne Nutzeraktion, etwa ein Checkout, kann einen Trace erzeugen, der Services aus beiden Anwendungen umfasst. Die Service Map von AppSignal behandelt dies als einen einzigen Trace, unabhängig davon, wo jeder Subtrace gemeldet wurde. Sie ermittelt die Anwendung, zu der jeder Service gehört, und verknüpft jede Karte mit der Ansicht dieser Anwendung auf denselben Trace. Um eine Anfrage über eine Anwendungsgrenze hinweg zu verfolgen, wählen Sie die Karte des nächsten Service aus. Sie wechseln entlang desselben Trace von einer Anwendung zur nächsten, ohne den Faden zu verlieren. Das funktioniert, weil sich der Kontext über Prozess- und Anwendungsgrenzen hinweg genauso weitergibt wie zwischen Services, und AppSignal Subtraces anhand ihrer gemeinsamen Trace-ID zuordnet, nicht danach, aus welcher Anwendung oder welchem Host sie stammen.

​

Verwandt