Dieses Dokument enthält einige allgemeine Tipps zur Fehlerbehebung beim Veröffentlichen von Nachrichten in einem Pub/Sub-Standardthema.
Weitere Informationen zum Veröffentlichen von Nachrichten in Themen und zu den verschiedenen Funktionen
Hohe Latenz bei der Veröffentlichung
Die Veröffentlichungslatenz ist die Zeit, die benötigt wird, um eine von einem Publisher-Client gesendete Veröffentlichungsanfrage zu bearbeiten. Die Veröffentlichungslatenz unterscheidet sich von der End-to-End-Zustellungslatenz. Dies ist die Zeit, die benötigt wird, bis eine in Pub/Sub veröffentlichte Nachricht an einen Abonnentenclient gesendet wird. Selbst 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, bei der Übertragung zwischen dem Client und dem Pub/Sub-Back-End oder im Pub/Sub-Back-End auftreten. Sie können die im Pub/Sub-Back-End auftretende Veröffentlichungslatenz mithilfe des Messwerts topic/send_request_latencies prüfen. Eine hohe Back-End-Veröffentlichungslatenz könnte mit den folgenden Faktoren zusammenhängen:
Pub/Sub wurde für die Bereitstellung mit niedriger Latenz und hohem Durchsatz entwickelt. Wenn das Thema einen niedrigen Durchsatz hat, kann die Initialisierung der mit dem Thema verknüpften Ressourcen länger dauern.
Wenn Sie eine Richtlinie zur Nachrichtenspeicherung verwenden, kann sich diese auf die Gesamtlatenz der Anfragen an das Thema und Abo auswirken. Prüfen Sie die Auswirkungen auf Leistung und Verfügbarkeit der Verwendung dieser Konfiguration.
Wenn die Veröffentlichungslatenz in Ihrem Publisher-Client deutlich höher ist als im Messwert widergespiegelt, könnte dies auf einen der folgenden clientseitigen Faktoren zurückzuführen sein:
Achte darauf, nicht für jede Veröffentlichung einen neuen Publisher zu erstellen. Es empfiehlt sich, einen 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 verursacht Latenzkosten. Wenn Sie Cloud Functions zum Veröffentlichen von Nachrichten verwenden, beachten Sie, dass Aufrufe auch die Veröffentlichungslatenz beeinflussen können.
Wenn Sie feststellen, dass die standardmäßigen Wiederholungseinstellungen 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 zur Konfiguration von Wiederholungsanfragen
Eine hohe Latenz bei der Veröffentlichung 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 während einer Veröffentlichungsanfrage gibt an, dass die Anfrage nicht innerhalb der zugewiesenen Zeit abgeschlossen wurde. Dies kann an verschiedenen Faktoren liegen, z. B., dass die Anfragen den Pub/Sub-Dienst nicht erreichen, oder Leistungsprobleme, die sich auf die Anfragen auswirken.
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 das Pub/Sub-Thema erreicht wird. Wenn der Messwert leer ist, verhindert ein externer Faktor, dass die Nachrichten den Pub/Sub-Dienst erreichen. Außerdem können Sie die Fehlerrate prüfen, um ein vorübergehendes Problem auszuschließen. Wenn die Fehlerrate sehr niedrig ist, könnte dies ein zeitweises Problem sein.
Wenn Anfragen Pub/Sub erreichen, gibt es verschiedene mögliche Ursachen dafür, dass Veröffentlichungsvorgänge mit dem Fehler DEADLINE_EXCEEDED fehlschlagen:
Clientseitiger Engpass
Veröffentlichungsfehler werden wahrscheinlich durch einen clientseitigen Engpass verursacht, z. B. durch unzureichenden Arbeitsspeicher, CPU-Auslastung, einen fehlerhaften Threadzustand oder eine Netzwerküberlastung in der VM, auf der der Publisher-Client gehostet wird. Wenn ein Publish-Aufruf DEADLINE_EXCEEDED zurückgibt, kann es sein, dass asynchrone Publish-Aufrufe schneller in die Warteschlange gestellt werden, als sie an den Dienst gesendet werden, wodurch die Anfragelatenz schrittweise erhöht wird. Prüfen Sie außerdem, ob die folgenden Dinge hilfreich sind, 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. In der Regel gibt jeder asynchrone
Publish-Aufruf einFuture-Objekt zurück. Um die Anzahl der Nachrichten zu erfassen, die auf den Sendevorgang 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. Entwicklungs-WLANs haben in der Regel eine Bandbreite von 1–10 MB/s oder 1.000–1.000 Nachrichten pro Sekunde. Das Veröffentlichen 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 an Ihre verfügbare Bandbreite reduzieren.
Prüfen Sie, ob die Latenz zwischen Ihrem Host und Google Cloud aufgrund einer Netzwerküberlastung beim Start oder Firewalls sehr hoch ist. Die Netzwerkdurchsatzberechnung enthält Hinweise zum Ermitteln der 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. Das Testen von Cloud Pub/Sub-Clients zur Maximierung der Streamingleistung zeigt, wie Pub/Sub auf einer einzelnen Google Cloud-VM mit zunehmender Anzahl von CPUs skaliert. Beispielsweise können Sie auf einer Compute Engine-Instanz mit 16 Kernen 500 MB/s bis 700 MB/s für Nachrichten mit einer Größe von 1 KB erreichen.
Unzureichendes Zeitlimit für Veröffentlichungen
Wenn Sie die Zeitüberschreitungsrate für Veröffentlichungsaufrufe reduzieren möchten, 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 Sie keinen großen Rückstand nicht gesendeter Nachrichten sammeln, können gelegentliche Spitzen in der Anfragelatenz dazu führen, dass Veröffentlichungsaufrufe zu Zeitüberschreitungen führen. Wenn die Probleme jedoch durch einen dauerhaften Engpass und nicht durch gelegentliche Zeitüberschreitungen verursacht werden, kann es zu mehr Fehlern kommen, wenn Sie den Vorgang häufiger wiederholen.
Probleme mit der Clientbibliothek
Möglicherweise führen Sie eine Version der Clientbibliothek mit einem bekannten Problem aus. Die folgende Liste enthält die Problemverfolgung für alle Clientbibliotheken. Wenn ein bekanntes Problem mit der verwendeten Version der Clientbibliothek auftritt, führen Sie ein Upgrade auf die neueste Version der Clientbibliothek durch. So ist sichergestellt, dass alle relevanten Updates, einschließlich Fehlerbehebungen und Leistungsverbesserungen, erkannt wurden.
C++
C#
Einfach loslegen (Go)
Java
Node.js
PHP
Python
Ruby
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 Schemaversionen 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 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 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.