Fehlerbehebung bei einem Standardthema

In diesem Dokument finden Sie einige allgemeine Tipps zur Fehlerbehebung beim Veröffentlichen von Nachrichten in einem Standard-Pub/Sub-Thema.

Weitere Informationen zum Veröffentlichen von Nachrichten in Themen und zu den verschiedenen Funktionen

Hohe Veröffentlichungslatenz

Die Veröffentlichungslatenz ist die Zeit, die zum Abschließen einer Veröffentlichungsanfrage benötigt wird, die von einem Publisher-Client ausgegeben wird. Die Veröffentlichungslatenz unterscheidet sich von der End-to-End-Übermittlungslatenz, die angibt, wie viel Zeit vergeht, bis eine Nachricht, die in Pub/Sub veröffentlicht wurde, an einen Abonnenten-Client übermittelt wird. Es kann zu einer hohen Veröffentlichungslatenz oder End-to-End-Latenz kommen, auch wenn der Wert des anderen Latenztyps niedrig ist. Eine hohe Veröffentlichungslatenz kann beim Pub/Sub-Publisher-Client, bei der Übertragung zwischen dem Client und dem Pub/Sub-Backend oder im Pub/Sub-Backend auftreten. Sie können die im Pub/Sub-Backend entstandene Veröffentlichungslatenz mit dem topic/send_request_latencies Messwert prüfen. Eine hohe Veröffentlichungslatenz im Backend kann auf folgende Faktoren zurückzuführen sein:

  • Pub/Sub ist für die Übermittlung mit niedriger Latenz und hohem Durchsatz konzipiert. Wenn das Thema einen niedrigen Durchsatz hat, kann die Initialisierung der mit dem Thema verknüpften Ressourcen länger dauern.

  • Wenn Sie eine Nachrichtenspeicherrichtlinie verwenden, kann sich dies auf die Gesamtlatenz der Anfragen an das Thema und das Abo auswirken. Informationen zu den Auswirkungen dieser Konfiguration auf Leistung und Verfügbarkeit

Wenn die Veröffentlichungslatenz Ihres Publisher-Clients deutlich höher ist als im Messwert angegeben, kann dies auf einen der folgenden clientseitigen Faktoren zurückzuführen sein:

  • Achten Sie darauf, dass Sie nicht für jede Veröffentlichung einen neuen Publisher erstellen. Es wird empfohlen, für jedes Thema und jede Anwendung einen einzelnen Publisher-Client zu verwenden, um alle Nachrichten zu veröffentlichen. Das Starten neuer Publisher-Objekte und das Hinzufügen neuer Threads verursacht Latenz. Wenn Sie Cloud Run-Funktionen zum Veröffentlichen von Nachrichten verwenden, können sich auch Aufrufe auf die Veröffentlichungslatenz auswirken.

  • Wenn die Standardeinstellungen für Wiederholungen für Ihren Anwendungsfall nicht ausreichen, nehmen Sie die entsprechenden Anpassungen vor. Prüfen Sie jedoch, ob die neuen Werte nicht zu hoch sind. Anfragen wiederholen konfigurieren

Beachten Sie, dass eine hohe Veröffentlichungslatenz zu DEADLINE_EXCEEDED-Fehlern führen kann, die im nächsten Abschnitt behandelt werden.

Publish-Vorgänge schlagen mit DEADLINE_EXCEEDED fehl

Ein DEADLINE_EXCEEDED-Fehler bei einer Veröffentlichungsanfrage bedeutet, dass die Anfrage nicht innerhalb des zugewiesenen Zeitraums abgeschlossen werden konnte. Dies kann verschiedene Ursachen haben, z. B. dass die Anfragen den Pub/Sub-Dienst nicht erreichen oder Leistungsprobleme die Anfragen beeinträchtigen.

Um zu prüfen, ob Veröffentlichungsanfragen den Pub/Sub-Dienst erreichen, beobachten Sie das Thema mit dem topic/send_request_count Messwert, gruppiert nach response_code. Mit diesem Messwert können Sie feststellen, ob Anfragen fehlschlagen, bevor sie das Pub/Sub-Thema erreichen. Wenn der Messwert leer ist, verhindert ein externer Faktor, dass die Nachrichten den Pub/Sub-Dienst erreichen. Um ein intermittierendes Problem auszuschließen, prüfen Sie außerdem die Fehlerrate anhand des Diagramms für den Messwert topic/send_request_count, das oben erwähnt wurde, oder auf der Seite „APIs & Dienste“ in der Google Cloud Console. Wenn die Fehlerrate sehr niedrig ist, kann es sich um ein intermittierendes Problem handeln.

Wenn Anfragen Pub/Sub erreichen, sind dies einige mögliche Ursachen dafür, dass Veröffentlichungsvorgänge mit einem DEADLINE_EXCEEDED-Fehler fehlschlagen:

Clientseitiger Engpass

Veröffentlichungsfehler werden wahrscheinlich durch einen clientseitigen Engpass verursacht, z. B. unzureichender Arbeitsspeicher, CPU-Auslastung, schlechte Threadintegrität oder Netzwerküberlastung in der VM, auf der der Publisher-Client gehostet wird. Wenn ein Publish-Aufruf DEADLINE_EXCEEDED zurückgibt, werden asynchrone Publish-Aufrufe möglicherweise schneller in die Warteschlange eingereiht, als sie an den Dienst gesendet werden. Dadurch erhöht sich die Anforderungslatenz schrittweise. Prüfen Sie außerdem, ob einer der folgenden Punkte hilft, einen möglichen Engpass in Ihrem System zu ermitteln:

  • Prüfen Sie, ob Sie Nachrichten schneller veröffentlichen, als der Client sie senden kann. Normalerweise gibt jeder asynchrone Publish Aufruf ein Future Objekt zurück. Um die Anzahl der Nachrichten zu verfolgen, die noch gesendet werden müssen, speichern Sie die Anzahl der zu sendenden Nachrichten mit jedem Publish-Aufruf und löschen Sie sie erst im Callback des Future-Objekts.

  • Achten Sie darauf, dass Sie eine ausreichende Uploadbandbreite zwischen dem Computer, auf dem der Publisher ausgeführt wird, und Google Cloudhaben. WLAN-Netzwerke für die Entwicklung haben in der Regel eine Bandbreite von 1 bis 10 MB/s oder 1.000 bis 10.000 typische Nachrichten pro Sekunde. Wenn Sie Nachrichten ohne Ratenbegrenzung in einer Schleife veröffentlichen, kann dies über einen kurzen Zeitraum zu einem kurzen Anstieg der Bandbreite führen. Um dies zu vermeiden, können Sie den Publisher auf einem Computer in Google Cloud ausführen oder die Rate, mit der Sie die Nachrichten veröffentlichen, an Ihre verfügbare Bandbreite anpassen.

  • Prüfen Sie, ob zwischen Ihrem Host und Google Cloud eine sehr hohe Latenz aufgrund von Startüberlastungen oder Firewalls auftritt. Die Berechnung des Netzwerkdurchsatzes enthält Hinweise zur Ermittlung Ihrer Bandbreite und Latenz für verschiedene Szenarien.

  • Letztendlich gibt es Beschränkungen für die Datenmenge, die ein einzelner Computer veröffentlichen kann. Möglicherweise müssen Sie versuchen, horizontal zu skalieren oder mehrere Instanzen des Publisher-Clients auf mehreren Computern auszuführen. Unter Cloud Pub/Sub -Clients testen, um die Streamingleistung zu maximieren wird gezeigt, wie Pub/Sub auf einer einzelnen Google Cloud VM mit zunehmender Anzahl von CPUs skaliert. Sie können beispielsweise 500 MB/s bis 700 MB/s für 1-KB-Nachrichten auf einer Compute Engine-Instanz mit 16 Kernen erreichen.

Unzureichende Dauer des Veröffentlichungstimeouts

Um die Timeout-Rate für Veröffentlichungsaufrufe zu reduzieren, muss in den Wiederholungseinstellungen des Publisher-Clients ein ausreichend langes Timeout definiert sein. Legen Sie für die Wiederholungseinstellungen die anfängliche Frist auf 10 Sekunden und die Gesamtzeitüberschreitung auf 600 Sekunden fest. Auch wenn sich kein großer Rückstand nicht gesendeter Nachrichten ansammelt, können gelegentliche Spitzen bei der Anfragelatenz dazu führen, dass Veröffentlichungsaufrufe das Zeitlimit überschreiten. Wenn Ihre Probleme jedoch durch einen dauerhaften Engpass und nicht durch gelegentliche Zeitüberschreitungen verursacht werden, führt ein wiederholter Versuch zu mehr Fehlern.

Probleme mit Clientbibliotheken

Möglicherweise verwenden Sie eine Version der Clientbibliothek mit einem bekannten Problem. Die folgende Liste enthält die Problemverfolgungstools für alle Clientbibliotheken. Wenn Sie ein bekanntes Problem finden, das die von Ihnen verwendete Version der Clientbibliothek betrifft, führen Sie ein Upgrade auf die neueste Version der Clientbibliothek durch. So stellen Sie sicher, dass Sie alle relevanten Updates erhalten haben, einschließlich Fehlerkorrekturen und Leistungsverbesserungen.

Schemaprobleme

Wenn Ihre Veröffentlichungen INVALID_ARGUMENT zurückgeben, hat möglicherweise jemand das Thema aktualisiert, um das zugehörige Schemazu ändern, das Schema gelöschtoder die mit dem Thema verknüpften Schemaüberarbeitungen gelöscht. Aktualisieren Sie in diesem Fall die Schemaeinstellungen des Themas auf ein Schema und eine Reihe von Überarbeitungen, die den veröffentlichten Nachrichten entsprechen, oder passen Sie das Nachrichtenformat an das aktuelle Schema an.

Probleme mit der Nachrichtenverschlüsselung

Wenn Sie Ihr Pub/Sub-Thema so konfiguriert haben, dass veröffentlichte Nachrichten mit einem kundenverwalteten Verschlüsselungsschlüssel verschlüsselt werden, kann die Veröffentlichung mit einem FAILED_PRECONDITION-Fehler fehlschlagen. Dieser Fehler kann auftreten, wenn der Cloud KMS-Schlüssel deaktiviert ist oder wenn extern verwaltete Schlüssel über Cloud EKM nicht mehr zugänglich sind. Wenn Sie die Veröffentlichung fortsetzen möchten, stellen Sie den Zugriff auf den Schlüssel wieder her.

Probleme mit der Nachrichtenspeicherrichtlinie

Wenn Ihre Abos keine veröffentlichten Nachrichten empfangen, gilt möglicherweise eine Nachrichtenspeicherrichtlinie für das Thema. In diesem Fall werden in Ihren Veröffentlichungsmesswerten möglicherweise FAILED_PRECONDITION-Fehler angezeigt.

Diese Fehler enthalten in der Regel Nachrichten wie:

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

oder

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

Führen Sie einen der folgenden Schritte aus, um das Problem zu lösen:

  • Aktualisieren Sie die Nachrichtenspeicherrichtlinie des Themas, um die Region zuzulassen.
  • Konfigurieren Sie Ihren Publisher-Client so, dass er in einer zulässigen Region veröffentlicht, indem Sie den entsprechenden regionalen Pub/Sub-Endpunkt verwenden.

Probleme mit Transformationen einzelner Nachrichten (Single Message Transforms, SMT)

Wenn Sie SMTs für Ihr Pub/Sub-Thema konfiguriert haben, kann die Veröffentlichung mit INVALID_ARGUMENT Fehlern fehlschlagen, wenn Transformationen nicht auf Nachrichten angewendet werden können. Wenn die Transformation einer Nachricht in einem Veröffentlichungsbatch fehlschlägt, kann der gesamte Batch nicht veröffentlicht werden. Der zurückgegebene Fehler gibt den Grund für den Fehler an, z. B.:

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

SMTs beobachten

Verwenden Sie die folgenden Messwerte, um die Leistung und die Auswirkungen von SMTs auf ein Thema zu verstehen:

Der Messwert „ topic/message_transform_latencies “ gibt an, wie lange es dauert, bis SMTs auf eine Nachricht angewendet werden. Der Messwert erfasst nur die SMT-Latenz und enthält keine anderen Teile der Nachrichtenübermittlungszeit.

Der Messwert enthält zwei wichtige Labels:

  • status: Gibt an, ob die Transformation erfolgreich war oder ein Problem aufgetreten ist.

  • filtered: Gibt an, ob die Nachricht aufgrund der SMT herausgefiltert wurde. Wenn eine SMT eine Nachricht in einem Thema herausfiltert, verwirft Pub/Sub die Nachricht und sie wird nie an Abonnenten gesendet. Dieses filtered-Label ist nur dann „true“, wenn die Filterung von einer SMT durchgeführt wird. Nachrichten, die mit den integrierten Filterfunktionen von Pub/Sub gefiltert werden, werden in diesem Messwert nicht berücksichtigt.

Der Messwert „topic/byte_cost “ wird verwendet, um Nachrichten zu identifizieren, die von SMTs gefiltert wurden oder bei denen SMTs fehlgeschlagen sind. Achten Sie auf diese spezifischen Werte:

  • Wenn eine SMT eine Nachricht filtert, ist der „operation_type“ smt_publish_filter_drop.

  • Wenn eine SMT eine Nachricht nicht transformieren kann, wird ein response_code angezeigt, der nicht OK ist.

Nächste Schritte

Verwenden Sie OpenTelemetry-Tracing, um die Veröffentlichungslatenz zu debuggen.