Dieses Dokument enthält einige allgemeine Tipps zur Fehlerbehebung beim Veröffentlichen von Nachrichten. 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 benötigt wird, um eine Veröffentlichungsanfrage abzuschließen, die von einem Publisher-Client ausgegeben wird. Die Veröffentlichungslatenz unterscheidet sich von der End-to-End-Zustellungslatenz, also der Zeitspanne, die vergeht, bis eine in Pub/Sub veröffentlichte Nachricht an einen Abonnenten-Client zugestellt wird. Auch wenn der Wert des anderen Latenztyps niedrig ist, kann es zu einer hohen Veröffentlichungs- oder End-to-End-Latenz kommen. Eine hohe Veröffentlichungslatenz kann beim Pub/Sub-Publisher-Client, beim Transport 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 Veröffentlichungslatenz im Pub/Sub-Backend prüfen. Hohe Latenzen bei der Veröffentlichung im Backend können folgende Ursachen haben:
Pub/Sub wurde für die Bereitstellung mit niedriger Latenz und hohem Durchsatz entwickelt. Wenn das Thema einen geringen Durchsatz hat, kann die Initialisierung der mit dem Thema verknüpften Ressourcen länger dauern.
Wenn Sie eine Richtlinie für die Speicherung von Nachrichten verwenden, kann sich diese auf die Gesamtlatenz der Anfragen an das Thema und das Abo auswirken. Prüfen Sie die Auswirkungen auf Leistung und Verfügbarkeit der Verwendung dieser Konfiguration.
Wenn die Veröffentlichungslatenz für deinen Publisher-Client deutlich höher ist als im Messwert angegeben, kann das auf einen der folgenden clientseitigen Faktoren zurückzuführen sein:
Achten Sie darauf, nicht bei jeder Veröffentlichung einen neuen Verlag oder Webpublisher zu erstellen. Es wird empfohlen, einen einzigen Publisher-Client pro Thema und Anwendung zu verwenden, um alle Nachrichten zu veröffentlichen. Das Erstellen neuer Publisher-Objekte und das Hinzufügen neuer Threads hat Latenzkosten. Wenn Sie zum Veröffentlichen von Nachrichten Cloud Run-Funktionen verwenden, können Aufrufe auch die Veröffentlichungslatenz beeinflussen.
Wenn Sie feststellen, dass die Standardeinstellungen für Wiederholungsversuche für Ihren Anwendungsfall nicht ausreichen, nehmen Sie die entsprechenden Anpassungen vor. Achten Sie jedoch darauf, dass die neuen Werte nicht zu hoch sind. Weitere Informationen zum Konfigurieren von Wiederholungsanfragen
Eine hohe Veröffentlichungslatenz kann zu DEADLINE_EXCEEDED-Fehlern führen, die im nächsten Abschnitt beschrieben 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 Zeitlimits abgeschlossen werden konnte. Dies kann an verschiedenen Faktoren liegen, z. B. weil Anfragen den Pub/Sub-Dienst nicht erreichen oder Leistungsprobleme die Anfragen beeinträchtigen.
Wenn Sie prüfen möchten, ob Veröffentlichungsanfragen den Pub/Sub-Dienst erreichen, überwachen 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 vorübergehendes Problem auszuschließen, prüfen Sie außerdem die Fehlerrate mithilfe des zuvor erwähnten Messwertdiagramms topic/send_request_count oder der APIs und 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, können Veröffentlichungsvorgänge mit dem Fehler DEADLINE_EXCEEDED fehlschlagen:
Clientseitiger Engpass
Fehler beim Veröffentlichen sind wahrscheinlich auf einen clientseitigen Engpass zurückzuführen, z. B. unzureichender Arbeitsspeicher, CPU-Druck, schlechte Threadintegrität oder Netzwerküberlastung in der VM, auf der der Publisher-Client gehostet wird. Wenn ein Publish-Aufruf DEADLINE_EXCEEDED zurückgibt, können asynchrone Publish-Aufrufe schneller in die Warteschlange aufgenommen werden, als sie an den Dienst gesendet werden. Dadurch erhöht sich die Latenz der Anfrage nach und nach. Prüfen Sie außerdem, ob Folgendes hilfreich ist, um 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 einFuture-Objekt zurück. Wenn Sie die Anzahl der Nachrichten verfolgen möchten, die zum Senden warten, speichern Sie die Anzahl der Nachrichten, die mit jedemPublish-Aufruf gesendet werden sollen, und löschen Sie sie nur im Callback desFuture-Objekts.Achten Sie darauf, dass Sie eine ausreichende Uploadbandbreite zwischen dem Computer, auf dem der Publisher ausgeführt wird, und Google Cloud haben. 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. Die Veröffentlichung von Nachrichten in einer Schleife ohne Ratenbegrenzung könnte zu einem kurzen Burst mit hoher Bandbreite über einen kurzen Zeitraum führen. Um dies zu vermeiden, können Sie den Publisher auf einem Computer in Google Cloud ausführen oder die Veröffentlichungsrate der Nachrichten entsprechend der verfügbaren Bandbreite verringern.
Prüfen Sie, ob aus Gründen wie Netzwerküberlastung beim Start oder Firewalls eine sehr hohe Latenz zwischen Ihrem Host und Google Cloud auftritt. Die Berechnung des Netzwerkdurchsatzes bietet Hinweise zum Ermitteln 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überschreitung für Veröffentlichungen
Um die Zeitüberschreitungsrate für Veröffentlichungsaufrufe zu reduzieren, muss in den Wiederholungseinstellungen des Publisher-Clients ein ausreichend langes Zeitlimit festgelegt sein. Legen Sie für die Wiederholungseinstellungen die anfängliche Frist auf 10 Sekunden und das Gesamtzeitlimit auf 600 Sekunden fest. Auch wenn sich kein großer Rückstand nicht gesendeter Nachrichten angesammelt hat, können gelegentliche Spitzen bei der Anfragelatenz dazu führen, dass Veröffentlichungsaufrufe ein Zeitlimit erreichen. Wenn Ihre Probleme jedoch durch einen dauerhaften Engpass und nicht durch gelegentliche Zeitüberschreitungen verursacht werden, führt ein wiederholter Versuch möglicherweise zu mehr Fehlern.
Probleme mit der Clientbibliothek
Möglicherweise führen Sie eine Version der Clientbibliothek mit einem bekannten Problem aus. Die folgende Liste enthält die Issue-Tracker für alle Clientbibliotheken. Wenn Sie ein bekanntes Problem feststellen, das sich auf die von Ihnen verwendete Version der Clientbibliothek auswirkt, führen Sie ein Upgrade auf die neueste Version der Clientbibliothek durch. So können Sie sicher sein, dass Sie alle relevanten Updates, einschließlich Fehlerkorrekturen und Leistungsverbesserungen, installiert haben.
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Schemaprobleme
Wenn Ihre Veröffentlichungen INVALID_ARGUMENT zurückgeben, 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 Schemaversionen 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 vom Kunden verwalteten Verschlüsselungsschlüssel verschlüsselt werden, schlägt die Veröffentlichung möglicherweise mit dem Fehler FAILED_PRECONDITION fehl. Dieser Fehler kann auftreten, wenn der Cloud KMS-Schlüssel deaktiviert ist oder extern verwaltete Schlüssel über Cloud EKM nicht mehr zugänglich sind. Stellen Sie den Zugriff auf den Schlüssel wieder her, um die Veröffentlichung fortzusetzen.