Verteiltes Tracing

Wo verbringt eine langsame Anfrage tatsächlich ihre Zeit? Eine Anfrage dauert vier Sekunden, aber Ihre Web-App wirkt normal, und die Datenbank ist ruhig. 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. Verlangsamt sie sich oder schlägt sie fehl, liegt die Ursache oft in einem anderen Service als dem, der das Symptom zuerst zeigte. Verteiltes Tracing lässt Sie diese eine Anfrage über diese Grenzen hinweg verfolgen. AppSignal fasst die Arbeit aller Services in einem Trace zusammen, sodass Sie den vollständigen Weg sehen, bevor Sie beginnen, Zeitstempel über Apps hinweg zu vergleichen.

​

Was ist verteiltes Tracing?

Wenn jeder Service für sich selbst berichtet, können Sie sehen, dass eine Web-Action langsam ist, aber nicht, dass ein Inventory-Service weiter unten in der Aufrufkette die Ursache war. In AppSignal können diese Services in separaten Anwendungen oder Namespaces liegen, sodass das Verfolgen einer Anfrage bedeutet, jede einzeln zu öffnen und die Zeitstempel abzugleichen. Verteiltes Tracing hält diese Services miteinander verbunden. Während eine Anfrage von einem Service zum nächsten wandert, markiert jeder Service seine Arbeit mit derselben Trace-ID und erfasst, welcher Span sie aufgerufen hat. AppSignal nutzt diese Daten, 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 zeigt einen verteilten Trace als drei Bausteine.

• 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

Bevor Sie eine Anfrage über Services hinweg untersuchen, muss jede Anwendung an einen gehosteten Collector berichten und sich mit einem eindeutigen Servicenamen identifizieren. Verteiltes Tracing ist über AppSignal-Integrationen für Python, Ruby und PHP sowie über OpenTelemetry für Go und Java verfügbar. Elixir und Node.js werden noch nicht unterstützt. Jede andere mit OpenTelemetry instrumentierte Anwendung kann ebenfalls Trace-Daten an einen gehosteten Collector melden. Im Browser startet AppSignal für Browser den Trace für Anfragen an Ihre API. Was Sie konfigurieren müssen, hängt davon ab, wie Ihre Integration Daten an AppSignal sendet. Python und Ruby können entweder über ihren mitgelieferten Agent oder über einen Collector berichten, daher müssen Sie den Collector-Modus aktivieren. PHP, Go, Java und individuelle OpenTelemetry-Setups berichten bereits über einen Collector, daher gibt es für verteiltes Tracing nichts zusätzlich zu aktivieren.

• Python: Setzen Sie die Option collector_endpoint auf die URL Ihres gehosteten statt eines selbst gehosteten Collectors. Siehe Collector-Konfiguration für Python.
• Ruby: Setzen Sie die Option collector_endpoint auf die URL Ihres gehosteten statt eines selbst gehosteten Collectors. Der Collector-Modus kam mit AppSignal für Ruby 5.0 und benötigt zusätzlich das appsignal-opentelemetry-Gem, ab Ruby 3.1 oder neuer. Siehe Collector-Konfiguration für Ruby für die zu installierenden Versionen und Verteiltes Tracing für Ruby für die Bibliotheken, die den Trace für Sie weitergeben.
• PHP: keine zusätzliche Einstellung für verteiltes Tracing zu aktivieren. Das PHP-Paket berichtet bereits über einen Collector, daher funktioniert verteiltes Tracing, sobald Ihre App an AppSignal berichtet.
• Go: Instrumentieren Sie Ihre App mit dem OpenTelemetry SDK und exportieren Sie an die URL Ihres gehosteten Collectors. Registrieren Sie einen Propagator mit otel.SetTextMapPropagator, wie es die Go-Installationsanleitung tut. Ohne ihn gibt das Go SDK den Trace-Kontext nicht weiter. AppSignal bietet Einrichtungsanleitungen für die Frameworks Gorilla mux und Gin-gonic.
• Java: Instrumentieren Sie mit dem OpenTelemetry SDK oder dem Java-Agent und exportieren Sie an die URL Ihres gehosteten Collectors. Die Einrichtung des Agents finden Sie in der Java-Installationsanleitung.
• Ein individuelles OpenTelemetry-Setup: keine AppSignal-spezifische Einstellung für verteiltes Tracing zu aktivieren. Der Export an einen gehosteten Collector ist bereits die Art, wie diese Setups berichten, daher verbinden sich Traces von selbst.
• Browser: Setzen Sie tracePropagationTargets auf Ihre API-Hosts. Jede passende Anfrage trägt einen traceparent-Header. Das empfangende Back-end braucht eine HTTP-Server-Instrumentierung, um ihn fortzusetzen. Eine 5xx-Antwort oder ein Timeout wird als Browser-Fehler in diesem Trace gemeldet. Siehe Verteiltes Tracing für Browser.

Legen Sie außerdem für jede Anwendung einen Servicenamen fest. Python, Ruby und PHP nehmen ihn über die Option service_name oder die Umgebungsvariable APPSIGNAL_SERVICE_NAME entgegen; Go, Java und individuelle OpenTelemetry-Setups setzen das Ressourcenattribut service.name. Legen Sie ihn für jeden Service explizit fest. Ohne ihn kann AppSignal die Services in einem Trace nicht zuverlässig unterscheiden, und ein individuelles OpenTelemetry-Setup erwartet, dass das Ressourcenattribut service.name vorhanden ist. Verteiltes Tracing basiert auf OpenTelemetry und ist daher nicht auf die oben genannten Integrationen beschränkt. Jede mit OpenTelemetry instrumentierte Anwendung kann Daten für verteiltes Tracing an einen gehosteten Collector melden. Das können Sie über eine AppSignal-Integration wie das PHP-Paket tun oder über ein individuelles OpenTelemetry-SDK-Setup. Mehr dazu erfahren Sie in den Dokumentationen zur Collector-Konfiguration für Python, zur Collector-Konfiguration für Ruby, zur PHP-Konfiguration, zur Go-Konfiguration, zur Java-Konfiguration und zur OpenTelemetry-Option für den Servicenamen.

​

Wie funktioniert es in AppSignal?

AppSignal baut verteilte Traces auf OpenTelemetry auf. Der Teil, der das möglich macht, ist 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, den er bearbeitet hat, 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 verbinden Services in AppSignal 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. Sobald Traces eintreffen, öffnen Sie die Trace-Seite, um sie auf zwei Arten zu untersuchen: 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 jeden Service mit der Ansicht dieser Anwendung auf denselben Trace. Um eine Anfrage über eine Anwendungsgrenze hinweg zu verfolgen, wählen Sie den nächsten Service auf der Map aus. Sie wechseln entlang desselben Trace von einer Anwendung zur nächsten. 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. Sobald jeder Service über einen gehosteten Collector mit seinem eigenen Servicenamen berichtet, können Sie eine Anfrage über Services und Anwendungen hinweg in einem einzigen Trace verfolgen.

​

Verwandt