Fehlerbehebung bei einem Standardthema

In diesem Dokument finden Sie einige Tipps zur Fehlerbehebung beim Veröffentlichen von Nachrichten in einem standardmäßigen 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 vergeht, bis eine Veröffentlichungsanfrage von einem Publisher-Client abgeschlossen ist. 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. Es kann sein, dass die Veröffentlichungslatenz oder die End-to-End-Latenz hoch ist, auch wenn der Wert des anderen Latenztyps niedrig ist. 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 ist für die Bereitstellung mit niedriger Latenz und hohem Durchsatz ausgelegt. Wenn das Thema einen geringen Durchsatz hat, kann die Initialisierung der zugehörigen Ressourcen länger dauern.

• Wenn Sie eine Richtlinie für den Nachrichtenspeicher verwenden, kann sich das auf die Gesamtlatenz der Anfragen an das Thema und das Abo auswirken. Lesen Sie den Artikel Auswirkungen auf Leistung und Verfügbarkeit, um mehr über die Verwendung dieser Konfiguration zu erfahren.

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. Wir empfehlen, für alle Nachrichten einen einzelnen Publisher-Client pro Thema und Anwendung zu verwenden. Das Erstellen neuer Publisher-Objekte und das Hinzufügen neuer Threads hat Latenzkosten. Wenn Sie Cloud Run-Funktionen zum Veröffentlichen von Nachrichten verwenden, können Aufrufe auch die Veröffentlichungslatenz beeinflussen.

• Wenn die Standardeinstellungen für Wiederholungen 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 Anfragen, die bei Fehlern wiederholt werden

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. Das kann verschiedene Ursachen haben, z. B. dass die Anfragen den Pub/Sub-Dienst nicht erreichen oder dass 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. Prüfen Sie außerdem die Fehlerrate anhand der bereits erwähnten topic/send_request_count-Messwertgrafik oder auf der Seite APIs und Dienste in der Google Cloud Console, um ein vorübergehendes Problem auszuschließen. Wenn die Fehlerrate sehr niedrig ist, kann es sich um ein vorübergehendes Problem handeln.

Wenn Anfragen Pub/Sub erreichen, können folgende Ursachen dafür vorliegen, dass Veröffentlichungsvorgänge mit einem DEADLINE_EXCEEDED-Fehler scheitern:

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, 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 Ihnen bei der Ermittlung eines möglichen Engpasses in Ihrem System hilft:

• 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.

• Achten Sie darauf, dass Sie eine ausreichende Uploadbandbreite zwischen dem Computer, auf dem der Publisher ausgeführt wird, und Google Cloud haben. WLANs 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 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überschreitung für die Veröffentlichung

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 die Gesamtzeitüberschreitung 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 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 mit der von Ihnen verwendeten Clientbibliotheksversion feststellen, 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.

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 zu veröffentlichenden 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 einem FAILED_PRECONDITION-Fehler 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. Wenn Sie die Veröffentlichung fortsetzen möchten, stellen Sie den Zugriff auf den Schlüssel wieder her.