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

Hohe Latenz bei der Veröffentlichung

Die Veröffentlichungslatenz ist die Zeit, die benötigt wird, um eine Veröffentlichungsanfrage eines Publisher-Clients abzuschließen. Die Veröffentlichungslatenz unterscheidet sich von der End-to-End-Zustellungslatenz. Das ist die Zeit, die benötigt wird, bis eine in Pub/Sub veröffentlichte Nachricht an einen Abonnenten-Client gesendet wird. Möglicherweise stellen Sie eine hohe Veröffentlichungs- oder End-to-End-Latenz fest, auch wenn der Wert des anderen Latenztyps niedrig ist. Eine hohe Veröffentlichungslatenz kann beim Pub/Sub-Publisher-Client, während der Übertragung zwischen dem Client und dem Pub/Sub-Backend oder im Pub/Sub-Backend auftreten. Mit dem Messwert topic/send_request_latencies können Sie die im Pub/Sub-Backend anfallende Veröffentlichungslatenz untersuchen. Eine hohe Latenz bei der Backend-Veröffentlichung kann mit den folgenden Faktoren zusammenhängen:

  • Pub/Sub ist für die Zustellung mit niedriger Latenz und hohem Durchsatz konzipiert. Wenn das Thema einen geringen Durchsatz hat, kann es länger dauern, bis die zugehörigen Ressourcen initialisiert werden.

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

Wenn die Veröffentlichungsverzögerung in Ihrem Publisher-Client deutlich höher ist als im Messwert angegeben, kann das an einem der folgenden clientseitigen Faktoren liegen:

  • Achten Sie darauf, dass Sie nicht bei jeder Veröffentlichung einen neuen Verlag oder Webpublisher erstellen. Es wird empfohlen, pro Thema und Anwendung einen einzelnen Publisher-Client zum Veröffentlichen aller Nachrichten zu verwenden. Das Erstellen 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 Aufrufe auch auf die Veröffentlichungsverzögerung auswirken.

  • Wenn die Standardeinstellungen für Wiederholungsversuche 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

Eine hohe Veröffentlichungsverzögerung kann zu DEADLINE_EXCEEDED-Fehlern führen, die im nächsten Abschnitt behandelt werden.

Publish-Vorgänge schlagen mit DEADLINE_EXCEEDED fehl

Ein DEADLINE_EXCEEDED-Fehler bei einer Veröffentlichungsanfrage gibt an, dass die Anfrage nicht innerhalb des zugewiesenen Zeitrahmens abgeschlossen werden konnte. Das 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 Messwert topic/send_request_count, 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 die Fehlerrate anhand des oben erwähnten Messwertdiagramms topic/send_request_count oder auf der Seite APIs & Dienste in der Google Cloud Console. Wenn die Fehlerrate sehr niedrig ist, kann es sich um ein vorübergehendes 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 Speicherplatz, CPU-Belastung, eine schlechte Threadintegrität oder Netzwerküberlastung auf 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 Kunde sie senden kann. Normalerweise gibt jeder asynchrone Publish-Aufruf ein Future-Objekt zurück. Wenn Sie die Anzahl der Nachrichten erfassen möchten, die noch gesendet werden sollen, speichern Sie die Anzahl der Nachrichten, die mit jedem Publish-Aufruf gesendet werden sollen, und löschen Sie sie nur im Rückruf des Future-Objekts.

  • Stellen Sie sicher, 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. Wenn Sie dies vermeiden möchten, können Sie den Publisher auf einem Computer innerhalb von Google Cloud ausführen oder die Veröffentlichungsrate der Nachrichten entsprechend der verfügbaren Bandbreite verringern.

  • 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 Zeitüberschreitungsdauer für die Veröffentlichung

Um die Zeitlimitrate für Veröffentlichungsaufrufe zu verringern, müssen Sie in den Wiederholungseinstellungen des Publisher-Clients ein ausreichend langes Zeitlimit definieren. Legen Sie für die Einstellungen für Wiederholungsversuche 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 Zeitüberschreitungen bei Publish-Aufrufen auftreten. 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 Issue-Tracker für alle Clientbibliotheken. Wenn Sie ein bekanntes Problem finden, das die von Ihnen verwendete Clientbibliotheksversion betrifft, führen Sie ein Upgrade auf die neueste Version der Clientbibliothek durch. So stellen Sie sicher, dass Sie alle relevanten Updates mit Korrekturen und Leistungsverbesserungen übernommen haben.

Schemaprobleme

Wenn bei Ihren Veröffentlichungen INVALID_ARGUMENT zurückgegeben wird, hat möglicherweise jemand das Thema aktualisiert, um das zugehörige Schema zu ändern, das Schema gelöscht oder 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 Versionen, 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 Single Message Transforms (SMT)

Wenn Sie SMTs für Ihr Pub/Sub-Thema konfiguriert haben, schlägt die Veröffentlichung möglicherweise mit INVALID_ARGUMENT-Fehlern fehl, 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 überwachen

Um die Leistung und Auswirkungen von SMTs auf ein Thema zu verstehen, verwenden Sie die folgenden Monitoring-Messwerte:

Mit dem Messwert topic/message_transform_latencies wird gemessen, wie lange es dauert, bis SMTs auf eine Nachricht angewendet werden. Der Messwert misst nur die SMT-Latenz und schließt andere Teile der Nachrichtenübermittlungszeit nicht ein.

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 ein SMT eine Nachricht zu einem Thema filtert, verwirft Pub/Sub die Nachricht und sie wird nie an Abonnenten gesendet. Das Label filtered ist nur dann „true“, wenn ein SMT die Filterung durchführt. Nachrichten, die mit den integrierten Filterfunktionen von Pub/Sub gefiltert werden, sind in diesem Messwert nicht enthalten.

Mit dem Messwert topic/byte_cost werden Nachrichten identifiziert, die von SMTs gefiltert wurden oder bei denen SMTs fehlgeschlagen sind. Suchen Sie nach diesen spezifischen Werten:

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

  • Wenn eine SMT eine Nachricht nicht transformieren kann, sehen Sie ein response_code, das nicht OK ist.

Nächste Schritte

OpenTelemetry-Tracing kann Ihnen helfen, die Latenz beim Veröffentlichen zu beheben.