Das verteilte Tracing für Application Load Balancer bietet End-to-End-Transparenz für Anfragen, die von Ihren Clients über den Load Balancer an Ihre Backend-Dienste gesendet werden.
Cloud Load Balancing ist in Cloud Trace eingebunden, um Trace-Spans für Anfragen zu generieren, die vom Load Balancer verarbeitet werden. Da der Load Balancer der Einstiegspunkt für den Anwendungstraffic ist, sorgt das Starten und Propagieren des Trace-Kontexts beim Load Balancer für eine Diagnose-Sichtbarkeit über den gesamten Anfragepfad hinweg. Mit diesen Traces können Sie Latenzengpässe identifizieren, fehlerhafte Hops isolieren und Fehler in mehrstufigen Architekturen beheben.
Der Load Balancer generiert Traces, die offenen Standards entsprechen (W3C Trace Context und OpenTelemetry). Backend-Dienste, die mit OpenTelemetry instrumentiert sind, können den vom Load Balancer gestarteten Trace fortsetzen.
Hauptvorteile
Verteiltes Tracing mit Cloud Trace bietet die folgenden Vorteile:
- End-to-End-Anfragesichtbarkeit: Verfolgen Sie den Pfad einer Anfrage über externe und interne Application Load Balancer und die Backend-Dienste, an die sie Traffic weiterleiten.
- Edge-Beobachtbarkeit: Erfassen Sie Trace-Spans bei der Weiterleitungsregel, bevor der Load Balancer ein Backend auswählt. So können Sie Edge-Fehler und Latenzen sehen, die von der Backend-Instrumentierung nicht erkannt werden.
- Entkoppelte Telemetriekonfiguration: Definieren Sie Tracing-Einstellungen in eigenständigen
TelemetryPolicy-Ressourcen, ohne die Routingkonfiguration Ihres Load Balancers zu ändern. - Telemetrieübergreifende Korrelation: Korrelieren Sie Trace-Spans mit Cloud Load Balancing-Anfragelogs und Cloud Monitoring-Messwerten, um die Ursache von Latenzen oder Fehlern zu ermitteln.
Unterstützte Load-Balancer
In der folgenden Tabelle sind die Load Balancer aufgeführt, die verteiltes Tracing unterstützen, sowie die Stichprobenmodi, die von jedem Load Balancer unterstützt werden:
| Load-Balancer | Load-Balancing-Schema | Probabilistische Stichprobenerhebung | Übergeordnetes Sampling |
|---|---|---|---|
| Globaler externer Application Load Balancer | EXTERNAL_MANAGED |
||
| Regionaler externer Application Load Balancer | EXTERNAL_MANAGED |
||
| Regionaler interner Application Load Balancer | INTERNAL_MANAGED |
||
| Regionsübergreifender interner Application Load Balancer | INTERNAL_MANAGED |
Klassische Application Load Balancer unterstützen kein verteiltes Tracing.
Funktionsweise von verteiltem Tracing
Wenn Sie verteiltes Tracing konfigurieren möchten, erstellen Sie eine TelemetryPolicy-Ressource in der Network Services API. Eine Telemetrie-Richtlinie gibt Folgendes an:
- Ziele: die Weiterleitungsregeln der Load Balancer, die Sie verfolgen möchten.
- Tracing-Konfiguration: Die Stichprobeneinstellungen, die bestimmen, welche Anfragen vom Load Balancer verfolgt werden.
Wenn eine Anfrage bei einer Weiterleitungsregel eingeht, auf die eine Telemetrie-Richtlinie abzielt, entscheidet der Load Balancer, ob die Anfrage in die Stichprobe aufgenommen werden soll. Wenn die Anfrage gesampelt wird, generiert der Load Balancer einen Trace-Span, sendet den Span an Cloud Trace und gibt den Trace-Kontext im W3C-traceparent-Anfrageheader an das Backend weiter.
Anhang der Weiterleitungsregel
Telemetrie-Richtlinien richten sich an die Weiterleitungsregel des Load Balancers, die das Frontend des Load Balancers darstellt. Wenn Sie das Tracing an die Weiterleitungsregel anhängen, kann der Load Balancer den gesamten Traffic verfolgen, der über eine virtuelle IP-Adresse (VIP) und einen Port eingeht, einschließlich Anfragen, die fehlschlagen, bevor der Load Balancer ein Backend auswählt.
Telemetrie-Richtlinien haben die folgenden Merkmale:
- Unabhängiger Lebenszyklus: Telemetrie-Richtlinien sind von Backend-Diensten, URL-Zuordnungen und Ziel-Proxys getrennt. Sie können eine Telemetrie-Richtlinie erstellen, ändern oder löschen, ohne die Art und Weise zu ändern, wie der Load Balancer Traffic weiterleitet.
- Frontend-übergreifend wiederverwendbar: Eine einzelne Telemetrie-Richtlinie kann auf mehrere Weiterleitungsregeln angewendet werden. So können Sie konsistente Tracing-Einstellungen auf mehrere Load-Balancer-Frontends anwenden.
- Standortbezogen: Erstellen Sie eine Telemetrie-Richtlinie am Standort
global, um globale Weiterleitungsregeln anzusprechen, z. B. solche, die von globalen externen Application Load Balancern und regionenübergreifenden internen Application Load Balancern verwendet werden. Erstellen Sie eine Telemetrie-Richtlinie in einer Region, um regionale Weiterleitungsregeln in dieser Region anzusprechen, z. B. solche, die von regionalen externen Application Load Balancern und regionalen internen Application Load Balancern verwendet werden.
Stichprobenmodi
Das verteilte Tracing unterstützt die folgenden Stichprobenmodi. Weitere Informationen dazu, welche Stichprobenmodi die einzelnen Load Balancer unterstützen, finden Sie in diesem Dokument unter Unterstützte Load Balancer.
- Probabilistische Stichprobenerhebung: Der Load Balancer nimmt eine feste Anzahl von Anfragen auf, die Sie im Feld
samplingRatefestlegen. Bei einem Wert von0.01wird beispielsweise 1 % der Anfragen erfasst. Die probabilistische Stichprobenerhebung wird auf allen unterstützten Load Balancern unterstützt. Übergeordnetes Sampling: Der Load Balancer berücksichtigt die Sampling-Entscheidung im eingehenden
traceparent-Header von einem vorgelagerten Client oder Dienst. Die übergeordnete Stichprobenerhebung wird im FeldparentBasedSamplingkonfiguriert. Übergeordnetes Sampling wird nur bei internen Application Load Balancern unterstützt.Wenn Sie die übergeordnete Stichprobenerhebung aktivieren, verarbeitet der Load Balancer Anfragen so:
- Wenn im eingehenden
traceparent-Header das Flag „sampled“ festgelegt ist, nimmt der Load Balancer Stichproben der Anfrage mit der im FeldparentBasedSampling.samplingRateangegebenen Rate vor. Setzen Sie dieses Feld beispielsweise auf1.0, um alle Anfragen zu verfolgen, die bereits von einem Upstream-Dienst erfasst wurden. - Wenn im eingehenden
traceparent-Header das Flag „sampled“ nicht gesetzt ist, wird die Anfrage vom Load Balancer nicht erfasst. Dieses Verhalten berücksichtigt die Upstream-Entscheidung und entspricht der OpenTelemetry-Spezifikation, die verhindert, dass nicht verbundene Traces in Cloud Trace angezeigt werden. - Wenn die Anfrage keinen
traceparent-Header enthält, wendet der Load Balancer die Referenz-samplingRatean.
- Wenn im eingehenden
Umgang mit Trace-Kontext-Headern
Der Load Balancer verarbeitet den W3C-traceparent-Header so:
- Tracing ist nicht aktiviert oder die Anfrage wird nicht erfasst: Der Load Balancer leitet den eingehenden
traceparent-Header unverändert an das Backend weiter. - Die Anfrage wird erfasst und enthält keinen
traceparent-Header: Der Load Balancer generiert eine neue Trace-ID und Span-ID und setzt die Trace-Flags auf03(zufällig und erfasst). - Die Anfrage wird per Stichprobe erfasst und enthält einen
traceparent-Header: Der Load Balancer behält die eingehende Trace-ID und das zufällige Flag bei, generiert eine neue Span-ID und legt das Stichproben-Flag fest.
Backend-Dienste, die ein OpenTelemetry SDK mit dem W3C Trace Context-Propagator verwenden, lesen den traceparent-Header automatisch und setzen den Trace fort.
Weitere Informationen finden Sie unter Trace-Kontext.
Gängige Anwendungsfälle
In diesem Abschnitt werden gängige Szenarien für verteiltes Tracing beschrieben.
Schaufensterkante überwachen
Ein E-Commerce-Onlineshop verwendet einen globalen externen Application Load Balancer, um Kundentraffic zu empfangen. Um die Edge-Latenz und Fehler wie 404-Antworten und TLS-Fehler zu überwachen, hängen Sie eine Telemetrie-Richtlinie mit probabilistischem Sampling an die Weiterleitungsregel der Storefront an. Eine niedrige Abtastrate wie 0.01 (1 %) sorgt dafür, dass die Kosten für die Cloud Trace-Aufnahme bei Traffic-Spitzen vorhersehbar bleiben.
Trace-Kontinuität über Kassendienste hinweg aufrechterhalten
Checkout-Anfragen werden von der Storefront über einen internen Application Load Balancer an interne Einkaufswagen-, Inventar- und Zahlungsdienste weitergeleitet. Damit die an der Storefront erfassten Checkout-Anfragen über jeden internen Hop hinweg verfolgt werden, aktivieren Sie das übergeordnete Sampling auf dem internen Load Balancer mit einem parentBasedSampling.samplingRate von 1.0. Für routinemäßigen internen Traffic, der keine vorgelagerte Stichprobenentscheidung enthält, wird die Baseline samplingRate verwendet.
Latenzengpässe isolieren
Wenn die Checkout-Latenz steigt oder die Anzahl der 5xx-Fehler zunimmt, vergleichen Sie die Load-Balancer-Spans in Cloud Trace mit den Load-Balancer-Anfragelogs und den Latenzmesswerten. Anhand dieses Vergleichs können Sie feststellen, ob das Problem am Load-Balancer-Edge, an einem internen Load-Balancer-Hop oder in einem Backend-Dienst auftritt.
Preise
Der Load Balancer berechnet keine Kosten für das Generieren von Trace-Spans. Cloud Trace berechnet jedoch die Aufnahme von Trace-Spans gemäß den Cloud Trace-Preisen.
Zur Verwaltung der Aufnahmekosten für Produktionsarbeitslasten mit hohem Traffic empfehlen wir einen samplingRate-Wert von 0.01 (1 %) oder 0.001 (0, 1 %).
Beschränkungen
Während der Vorabversion gelten für das verteilte Tracing für Application Load Balancer die folgenden Einschränkungen:
- Übergeordnetes Sampling wird auf externen Application Load Balancern nicht unterstützt.
- Benutzerdefinierte Span-Attribute werden nicht unterstützt.
- Sie können verteiltes Tracing nicht mit der Google Kubernetes Engine Gateway API oder Terraform konfigurieren.
- Eine einzelne Telemetrie-Richtlinie kann auf bis zu 50 Ressourcen angewendet werden.
Verteiltes Tracing für Agent Gateway
Wenn Sie Agent Gateway zum Verwalten des Traffics für KI-Agenten verwenden, finden Sie unter Traffic über Agent Gateway überwachen Informationen zum Überwachen des Agent-Traffics.