Fehlerbehebung

Hier finden Sie nützliche Informationen über die schrittweise Fehlerbehebung in Verbindung mit Pub/Sub.

Abo kann nicht erstellt werden

Stellen Sie sicher, dass Sie Folgendes getan haben:

  • Im Feld name muss ein Aboname angegeben werden. Ab Version v1beta2 muss der Aboname das Format projects/project-identifier/subscriptions/subscription-name haben.
  • Geben Sie den Namen eines bereits vorhandenen Themas, das Sie abonnieren möchten, im Feld topic an. Ab Version v1beta2 muss der Themenname das Format projects/project-identifier/topics/topic-name haben.
  • Der Wert https:// muss in Kleinbuchstaben (nicht http:// oder HTTPS://) als Protokoll für Ihre Empfänger-URL im Feld pushEndpoint angegeben werden.

Push-Abonnent erhält keine Nachrichten

Prüfen Sie Folgendes:

  • Sehen Sie in Cloud Monitoring nach, ob Fehler vorliegen, die sich auf das betreffende Abo beziehen.
  • In App Engine empfehlen wir, das Präfix /_ah/push-handlers/ im URL-Pfad der Endpunkte zu verwenden, wie unter App Engine-Endpunkte registrieren beschrieben. Mit diesem Code kann der Endpunkt Push-Nachrichten von der Pub/Sub API empfangen.
  • Sorgen Sie in anderen Umgebungen dafür, dass Ihre Endpunkt-URL aus dem Internet zugänglich ist, ohne eine Anmeldung zu erfordern. Sie können prüfen, ob die URL eingeschränkt ist, indem Sie sie mit einem Diagnosetool wie cURL aufrufen.
  • Für andere Domains als appspot.com müssen Sie die Domain in der Google Cloud Console registrieren. Weitere Informationen finden Sie unter Andere Endpunkte registrieren.

Die Zustellung von Push-Nachrichten verspätet sich um mehrere Stunden

Eine unbestätigte Push-Nachricht kann die Zustellung neuer Nachrichten verzögern. Eine Nachricht wird nicht bestätigt, wenn der Push-Endpunkt fehlschlägt oder einen anderen Statuscode als 200, 201, 202, 204 oder 102 zurückgibt. Um die Verzögerung zu beheben, aktualisieren Sie den Endpunktcode, um die fehlgeschlagenen Nachrichten zu verarbeiten, oder rufen Sie sie manuell ab und bestätigen Sie sie. Weitere Informationen zum Erkennen nicht bestätigter Nachrichten und zum Erstellen von Benachrichtigungen finden Sie in der Monitoring-Übersicht.

Fehler 403 (Forbidden)

Gehen Sie folgendermaßen vor, wenn dieser Fehler angezeigt wird:

  • Stellen Sie sicher, dass Sie die Pub/Sub API in der Cloud Console aktiviert haben.
  • Achten sie darauf, dass der Teilnehmer, der die Anfrage stellt, die erforderlichen Berechtigungen für die relevanten Pub/Sub API-Ressourcen hat. Dies ist besonders wichtig, wenn Sie die Pub/Sub API für die projektübergreifende Kommunikation verwenden.
  • Wenn Sie Dataflow verwenden, achten Sie darauf, dass sowohl <projectId>@cloudservices.gserviceaccount.com als auch das Compute Engine-Dienstkonto <projectId>-compute@developer.gserviceaccount.com die erforderlichen Berechtigungen für die entsprechende Pub/Sub API-Ressource haben. Weitere Informationen finden Sie unter Sicherheit und Berechtigungen in Dataflow.
  • Wenn Sie App Engine verwenden, prüfen Sie auf der Seite "Berechtigungen", ob ein App Engine-Dienstkonto als Bearbeiter aufgeführt ist. Wenn dies nicht der Fall ist, fügen Sie Ihr App Engine-Dienstkonto als Bearbeiter hinzu. Normalerweise hat das App Engine-Dienstkonto das Format <project-id>@appspot.gserviceaccount.com.

Duplikate verwalten und Wiederholungsversuche erzwingen

Wenn Sie eine Nachricht nicht vor Ablauf der Bestätigungsfrist bestätigen, sendet Pub/Sub die Nachricht noch einmal. Infolgedessen kann Pub/Sub Nachrichten doppelt senden. Verwenden Sie die Operations Suite von Google Cloud, um Vorgänge mit dem Antwortcode expired zu beobachten, um dieses Problem zu erkennen. Wählen Sie zum Abrufen dieser Daten den Messwert Nachrichtenvorgänge bestätigen aus und gruppieren oder filtern Sie ihn nach dem Label response_code. Beachten Sie, dass response_code ein Systemlabel für einen Messwert ist und kein Messwert an sich.

Verwenden Sie Stackdriver, um nach abgelaufenen Bestätigungsfristen für Nachrichten zu suchen

Verlängern Sie die Nachrichtenfrist, um die Duplizierungsrate zu senken.

  • Clientbibliotheken erledigen die Fristverlängerung automatisch, es gibt jedoch standardmäßig Beschränkungen für die maximal konfigurierbare Fristverlängerung.
  • Wenn Sie eine eigene Clientbibliothek erstellen, können Sie die Bestätigungsfrist mit der Methode modifyAckDeadline verlängern.

Alternativ können Sie festlegen, dass Pub/Sub eine Nachricht noch einmal sendet, indem Sie modifyAckDeadline auf 0 setzen.

Publish-Vorgänge schlagen mit DEADLINE_EXCEEDED fehl

Dies ist wahrscheinlich auf einen clientseitigen Engpass zurückzuführen, z. B. unzureichende Dienst-CPUs, eine schlechte Threadintegrität oder Netzwerküberlastung. Wenn ein Publish-Aufruf DEADLINE_EXCEEDED zurückgibt, werden asynchrone Publish-Aufrufe schneller in die Warteschlange eingereiht, als sie an den Dienst gesendet werden. Dadurch erhöht sich die Anforderungslatenz schrittweise. Unter Cloud Pub/Sub-Clients testen, um die Streaming-Leistung zu maximieren erfahren Sie, wie Sie den Publish-Durchsatz mit einer einzelnen VM für verschiedene Parameter (Kerne, Worker, Nachrichtengröße) ermitteln. Alternativ kann es sein, dass Sie eine Version der Clientbibliothek mit einem bekannten Problem ausführen. Schauen Sie im Problemverfolgungsclient für Ihre Clientbibliothek in der Liste nach.

Schließlich können Sie eine Frist festlegen, die niedriger ist als die typische Publish-Latenz von Pub/Sub. Empfohlen wird, die anfängliche Frist auf 10 Sekunden und die gesamte Zeitüberschreitung auf 600 Sekunden festzulegen.

Probieren Sie folgende Lösungsschritte aus:

  • 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 diesem Publish-Aufruf gesendet werden sollen, und löschen Sie sie nur im Rückruf des Future-Objekts. Wenn Sie Publish-Aufrufe schneller ausführen, als die entsprechenden Anfragen an den Pub/Sub-Dienst abgeschlossen werden können, erhöht sich die Latenz für einen einzelnen Publish-Aufruf, der später erfolgt, drastisch.
  • Stellen Sie sicher, dass Sie eine ausreichende Uploadbandbreite zwischen dem Computer, auf dem der Publisher ausgeführt wird, und Google Cloud haben. Es ist üblich, dass WLAN-Netzwerke, die für die Entwicklung verwendet werden, eine Bandbreite von 1 bis 10 MB/s oder 1.000 bis 10.000 typische Nachrichten pro Sekunde haben. Wenn Sie diese Nachrichten ohne Ratenbegrenzung in einer Schleife veröffentlichen, kann dies über einen kurzen Zeitraum zu einem kurzen Anstieg der Bandbreite führen. Sie erhalten möglicherweise mehr Bandbreite, wenn Sie den Publisher auf einem Computer innerhalb der GCP ausführen oder die Veröffentlichungsrate der Nachrichten entsprechend der verfügbaren Bandbreite verringern.
  • Achten Sie darauf, dass das Zeitlimit für den in den Wiederholungseinstellungen definierten Aufruf lang genug ist. Es gibt Fälle, in denen Spitzen bei der Anfragelatenz zu Fehlern führen, auch wenn sich kein großer Rückstand nicht gesendeter Nachrichten angesammelt hat. Wenn Sie die anfängliche Frist auf 10 Sekunden und die Gesamtzeitüberschreitung auf 600 Sekunden erhöhen, sinkt die Zeitüberschreitung. Wenn Ihre Probleme durch einen dauerhaften Engpass und nicht durch gelegentliche Zeitüberschreitungen verursacht werden, führt ein wiederholter Versuch zu mehr Fehlern.
  • 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.
  • Führen Sie ein Upgrade auf die neueste Version der Clientbibliothek durch. Achten Sie daran, dass Sie alle relevanten Updates mit Korrekturen wie Leistungsverbesserungen übernommen haben.
  • Prüfen Sie, ob die VM, auf der der Publisher-Client gehostet wird, keine Ressourcen mehr hat, einschließlich CPU, RAM und Threads. Es kann sein, dass es lange dauert, bevor der Aufruf tatsächlich eine Anfrage an den Dienst richtet.
  • 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.

Übermäßige Verwaltungsvorgänge verwenden

Sollten Sie feststellen, dass Sie zu viel von Ihrem Kontingent für Verwaltungsvorgänge verbrauchen, müssen Sie unter Umständen Ihren Code refaktorieren. Betrachten Sie diesen Pseudocode zur Veranschaulichung. In diesem Beispiel wird mit einem Verwaltungsvorgang (GET) geprüft, ob ein Abo vorhanden ist, bevor versucht wird, seine Ressourcen zu verbrauchen. Sowohl GET als auch CREATE sind Administratorvorgänge:


    if !GetSubscription my-sub {
     CreateSubscription my-sub
    }
    Consume from subscription my-sub
            

Ein effizienteres Muster ist der Versuch, Nachrichten aus dem Abo zu verbrauchen (vorausgesetzt, Sie sind sich beim Namen des Abos einigermaßen sicher). Bei diesem optimistischen Ansatz erhalten oder erstellen Sie das Abo nur, wenn ein Fehler auftritt. Betrachten Sie dieses Beispiel:

    try {
      Consume from subscription my-sub
    } catch NotFoundError {
      CreateSubscription my-sub
      Consume from subscription my-sub
    }