Fehlerbehebung

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

Abo kann nicht erstellt werden

Prüfen Sie, ob 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.

403 (Forbidden) Fehler

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

  • Prüfen Sie, ob die Pub/Sub API in der Google Cloud Console aktiviert ist.
  • 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, überprü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 Cloud Monitoring, um Bestätigungsvorgänge mit dem Antwortcode expired zu überwachen, um diesen Zustand zu erkennen. Wählen Sie zum Abrufen dieser Daten den Messwert subscription/expired_ack_deadlines_count aus.

Mit Cloud Monitoring nach abgelaufenen Bestätigungsfristen für Nachrichten 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.

Wenn Sie dagegen erzwingen möchten, dass Pub/Sub den Versand einer Nachricht wiederholt, setzen Sie modifyAckDeadline auf 0.

Ü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
    }