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 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 Ende-zu-Ende-Zustellungslatenz, die die Zeit angibt, die für eine in Pub/Sub veröffentlichte Nachricht benötigt wird, um an einen Abonnentenclient zu senden. 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 auf dem Pub/Sub-Publisher-Client, bei der Übertragung zwischen dem Client und dem Pub/Sub-Back-End oder im Pub/Sub-Back-End auftreten. Mit dem Messwert topic/send_request_latencies können Sie die im Pub/Sub-Back-End auftretende Veröffentlichungslatenz prüfen. Eine hohe Backend-Veröffentlichungslatenz kann durch folgende Faktoren verursacht werden:
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 Ihr Publisher-Client die Veröffentlichungslatenz deutlich über dem Messwert erkennt, kann dies auf einen der folgenden clientseitigen Faktoren hindeuten:
Achten Sie darauf, nicht für jede Veröffentlichung einen neuen Publisher zu erstellen. Es wird empfohlen, einen einzigen Publisher-Client pro Thema und Anwendung zu verwenden, um alle Nachrichten zu veröffentlichen. Für das Starten neuer Publisher-Objekte und das Hinzufügen neuer Threads entstehen Latenzkosten. Wenn Sie Cloud Functions zum Veröffentlichen von Nachrichten 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 zur Konfiguration von Wiederholungsanfragen
Eine hohe Veröffentlichungslatenz kann zu DEADLINE_EXCEEDED-Fehlern führen, die im nächsten Abschnitt erläutert werden.
Publish-Vorgänge schlagen mit DEADLINE_EXCEEDED fehl
Der Fehler DEADLINE_EXCEEDED während einer Veröffentlichungsanfrage gibt an, dass die Anfrage nicht innerhalb der vorgesehenen Zeit abgeschlossen werden konnte. Dies kann an verschiedenen Faktoren liegen, z. B. wenn Anfragen den Pub/Sub-Dienst nicht erreichen oder Leistungsprobleme die Anfragen beeinträchtigen.
Überwachen Sie das Thema mit dem Messwert topic/send_request_count, gruppiert nach response_code, um zu prüfen, ob Veröffentlichungsanfragen den Pub/Sub-Dienst erreichen. 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, um ein vorübergehendes Problem auszuschließen. Wenn die Fehlerrate sehr niedrig ist, könnte es sich um ein zeitweise auftretendes Problem handeln.
Wenn Anfragen Pub/Sub erreichen, können Veröffentlichungsvorgänge mit dem Fehler DEADLINE_EXCEEDED fehlschlagen:
Clientseitiger Engpass
Veröffentlichungsfehler werden wahrscheinlich durch einen clientseitigen Engpass verursacht, z. B. unzureichenden Arbeitsspeicher, eine hohe CPU-Auslastung, ein fehlerhafter Thread-Zustand oder eine Netzwerküberlastung 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 genügend Uploadbandbreite zwischen der Maschine, auf der der Publisher ausgeführt wird, und Google Cloud haben. Entwicklungs-WLAN-Netzwerke haben in der Regel eine Bandbreite von 1–10 MB/s oder 1.000–10.000 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 so verringern, dass sie der verfügbaren Bandbreite entsprechen.
Prüfen Sie, ob aus Gründen wie Netzwerküberlastung oder Firewalls beim Start 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 horizontal skalieren oder mehrere Instanzen des Publisher-Clients auf mehreren Computern ausführen. 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 wird. Beispielsweise können Sie 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überschreitung für Veröffentlichungsaufrufe zu verringern, muss in den Wiederholungseinstellungen des Publisher-Clients ein ausreichend langes Zeitlimit definiert sein. Legen Sie für die Wiederholungseinstellungen die anfängliche Frist auf 10 Sekunden und das Gesamtzeitlimit auf 600 Sekunden fest. Selbst wenn Sie keinen großen Rückstand nicht gesendeter Nachrichten ansammeln, können gelegentliche Spitzen in der Anfragelatenz zu Zeitüberschreitungen bei Veröffentlichungsaufrufen führen. Wenn Ihre Probleme jedoch durch einen dauerhaften Engpass und nicht durch gelegentliche Zeitüberschreitungen verursacht werden, können wiederholte Versuche zu weiteren Fehlern führen.
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 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. Dadurch wird sichergestellt, dass Sie alle relevanten Updates übernommen haben, einschließlich Fehlerbehebungen und Leistungsverbesserungen.
C++
C#
Einfach loslegen (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 bei 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.