Dieses Dokument enthält einige allgemeine Tipps zur Fehlerbehebung für Pub/Sub-Pull-Abos. Weitere Informationen zu Pull-Abos finden Sie im Pull-Abonnentenleitfaden.
Um Ihr Pub/Sub-Abo effektiv zu überwachen, sollten Sie zuerst den Status der Zustellungslatenz (subscription/delivery_latency_health_score) prüfen, um herauszufinden, welche Faktoren zu einer unerwarteten oder erhöhten Latenz beitragen können.
Das Alter der ältesten unbestätigten Nachricht nimmt immer weiter zu
Der oldest_unacked_message_age ist ein wichtiger Messwert für die Überwachung des Status von Pub/Sub-Abos. Sie gibt das Alter der ältesten Nachricht im Rückstand eines Abos in Sekunden an, die noch nicht von einem Abonnenten bestätigt wurde. Dieser Messwert liefert wertvolle Informationen zu potenziellen Verarbeitungsverzögerungen oder Engpässen.
Durch die Überwachung des Nachrichtenrückstands wird eine zeitnahe und effiziente Nachrichtenverarbeitung gewährleistet. Wenn Sie das Alter der ältesten unbestätigten Nachricht im Blick behalten, können Sie proaktiv Situationen erkennen, in denen Verbraucher in Verzug geraten. So können Sie frühzeitig eingreifen, um potenzielle Probleme im Zusammenhang mit einer schlechteren Leistung zu beheben.
Hier einige häufige Probleme im Backlog, die Sie untersuchen können:
Probleme bei der Clientkonfiguration
Wenn sowohl der Messwert oldest_unacked_message_age als auch der Messwert num_undelivered_messages gleichzeitig steigen, kann das bedeuten, dass die Abonnenten mit der Nachrichtenmenge nicht mithalten können. Konzentrieren Sie sich in diesem Fall auf die Abonnentenkomponenten:
Clientzustand: Analysieren Sie die Ressourcennutzung auf Computern, auf denen Abonnentenclients gehostet werden, z. B. CPU, Arbeitsspeicher und Netzwerkbandbreite. Suchen Sie nach Engstellen, die die Verarbeitungseffizienz beeinträchtigen könnten.
Clientcode: Überprüfen Sie die letzten Codeänderungen und sehen Sie sich die Fehlerprotokolle an. Fehler oder Ineffizienzen im Abonnentencode können die Raten für die Nachrichtenverarbeitung erheblich beeinträchtigen. Beachten Sie, dass es Probleme in bestimmten Nachrichten geben kann. Beispielsweise müssen möglicherweise mehrere Nachrichten gleichzeitig auf dieselbe Zeile in einer Datenbank zugreifen. Dieses Verhalten kann zu Konflikten und hoher Latenz führen.
Kontingentbeschränkungen: Prüfen Sie, ob Sie Pub/Sub-Kontingente oder Beschränkungen Ihres Hostings überschritten haben. Wenn die Abonnenten in Google Cloudgehostet werden, prüfen Sie die Compute Engine- oder GKE-Ressourcenkontingente, um potenzielle Engpässe zu vermeiden.
Der Abonnent hat die Nachrichten negativ bestätigt
Wenn ein Abonnent eine Nachricht negativ bestätigt (NACK), signalisiert er Pub/Sub, dass die Nachricht nicht erfolgreich verarbeitet werden konnte. Pub/Sub versucht dann, dieselbe Nachricht noch einmal zu senden. Wiederholte NACKs für eine Nachricht führen zu Duplikaten und möglicherweise zu einer hohen Verzögerung bei der Zustellung von Nachrichten.
Das NACKen einer Nachricht garantiert nicht, dass beim nächsten Pull eine andere Nachricht abgerufen wird. Gemäß der Richtlinie für die erneute Zustellung von Pub/Sub werden möglicherweise weiterhin Nachrichten, die nicht bestätigt wurden, vor neuen Nachrichten noch einmal zugestellt. Verlassen Sie sich daher nicht auf NACKs, um bestimmte Nachrichten zu filtern oder zu überspringen. Legen Sie stattdessen eine Wiederholungsrichtlinie fest, vorzugsweise einen exponentiellen Backoff, um einzelne Nachrichten zurückzustellen, die wahrscheinlich später verarbeitet werden können, aber etwas mehr Zeit vor der erneuten Zustellung benötigen.
Wenn Sie bestimmte Nachrichten absichtlich überspringen müssen, empfehlen wir, sie zu bestätigen, auch wenn Sie sie nicht verarbeiten. Dadurch werden sie aus dem Abo entfernt, unnötige erneute Zustellungen werden vermieden und der Ressourcenverbrauch wird reduziert. Wenn Nachrichten nicht bestätigt werden, entstehen unabhängig davon, ob dies absichtlich geschieht oder nicht, Probleme mit dem Rückstand und doppelte Zustellungen.
Hohe Bereitstellungslatenz
Die Übermittlungs-Latenz in Pub/Sub ist die Zeit, die eine Nachricht von einem Publisher benötigt, um einen Abonnenten zu erreichen. In den folgenden Abschnitten werden einige mögliche Ursachen für eine hohe Zustellungslatenz beschrieben.
Nicht genügend Abonnenten
Damit Clients, die StreamingPull verwenden, eine gleichbleibend niedrige Latenz erreichen, sollten Sie mehrere offene StreamingPull-Verbindungen zu Ihrem Abo aufrechterhalten. Ohne aktive Abonnentenverbindungen kann Pub/Sub Nachrichten nicht rechtzeitig zustellen. Ein einzelner Stream kann ein Single Point of Failure sein, was das Risiko von Verzögerungen erhöht. Der Messwert subscription/open_streaming_pulls gibt Aufschluss über die Anzahl der aktiven Streamingverbindungen. So können Sie dafür sorgen, dass Sie immer genügend Streams haben, um eingehende Nachrichten zu verarbeiten.
Bei Clients, die Unary Pull verwenden, sollten Sie mehrere ausstehende Pull-Anfragen für Ihr Abo aufrechterhalten, um eine gleichbleibend niedrige Latenz zu erzielen. Bei seltenen Anfragen können sich Nachrichten im Rückstand ansammeln und die Latenz erhöhen. Dieser Ansatz trägt dazu bei, Lücken bei der Konnektivität zu minimieren und die Bereitstellungslatenz zu verbessern.
Die Clientbibliothek auf hoher Ebene wird für Fälle empfohlen, in denen Sie einen hohen Durchsatz und eine niedrige Latenz mit minimalem Betriebsaufwand und minimalen Verarbeitungskosten benötigen. Standardmäßig verwendet die Clientbibliothek auf hoher Ebene die StreamingPull API, da sie in der Regel die bessere Wahl ist, um die Latenz zu minimieren. Die Clientbibliotheken auf hoher Ebene enthalten vorgefertigte Funktionen und Klassen, die die zugrunde liegenden API-Aufrufe für Authentifizierung, Optimierung von Durchsatz und Latenz, Nachrichtenformatierung und andere Funktionen verarbeiten.
Probleme bei der Clientkonfiguration
Weitere Informationen finden Sie unter Probleme bei der Clientkonfiguration.
Hoher Rückstand
Ein Nachrichtenrückstand von nicht bestätigten Nachrichten in einem Pub/Sub-Abo erhöht die End-to-End-Latenz, da Nachrichten nicht sofort von Abonnenten verarbeitet werden.
Bestellschlüssel und genau einmalige Zustellung
Reihenfolgeschlüssel und die genau einmalige Zustellung sind nützliche Funktionen, erfordern jedoch eine zusätzliche Koordination in Pub/Sub, um eine korrekte Zustellung zu gewährleisten. Diese Koordination kann die Verfügbarkeit verringern und die Latenz erhöhen. Im stabilen Zustand ist der Unterschied minimal, aber alle erforderlichen Koordinierungsschritte können zu vorübergehenden Latenzzeiten oder einer erhöhten Fehlerrate führen. Wenn die Sortierung aktiviert ist, können Nachrichten mit einem Sortierschlüssel erst zugestellt werden, wenn frühere Nachrichten mit demselben Sortierschlüssel bestätigt wurden.
Überlegen Sie, ob die Nachrichtenreihenfolge oder die genau einmalige Bereitstellung für Ihre Anwendung unbedingt erforderlich sind. Wenn eine geringe Latenz für Sie oberste Priorität hat, können Sie die Verzögerungen bei der Nachrichtenverarbeitung reduzieren, indem Sie diese Funktionen möglichst wenig nutzen.
Größe der Nachricht nimmt zu
Ein plötzlicher Anstieg der Nachrichtengröße kann die Übertragungszeit zwischen Pub/Sub und Ihrem Client verlängern und die Verarbeitungszeit der Nachrichten auf Clientseite verlangsamen.
Wenn Sie eine erhöhte Zustellungslatenz feststellen, können Sie die Nachrichtengrößen mit dem Messwert topic/message_sizes prüfen und nach topic_id gruppieren. Korrelieren Sie alle Spitzen bei der Nachrichtengröße mit beobachteten Leistungsproblemen.
Fehlende Nachrichten
Wenn Sie vermuten, dass Nachrichten nicht erfolgreich an Ihren Abonnenten zugestellt werden, kann das einen der folgenden Gründe haben.
Nachrichtenzustellung in Pub/Sub-Abos mit mehreren Consumern
In Pub/Sub werden Nachrichten möglicherweise ungleichmäßig auf die Nutzer desselben Abos verteilt. Pub/Sub führt einen Lastenausgleich für Nachrichten auf alle aktiven Clients durch. Das primäre Ziel ist jedoch, den Gesamtdurchsatz der Nachrichtenverarbeitung zu maximieren und den Rückstand zu minimieren, anstatt für eine gleichmäßige Verteilung zu sorgen. Das System leitet mehr Nachrichten dynamisch an Verbraucher weiter, die eine höhere Kapazität haben, d. h. Nachrichten schnell bestätigen und nicht durch ihre Einstellungen zur Ablaufsteuerung eingeschränkt sind. Consumer, die Nachrichten mit unterschiedlicher Geschwindigkeit verarbeiten oder unter unterschiedlichen Bedingungen arbeiten (z.B. Ressourcenverfügbarkeit, Netzwerklatenz), verarbeiten wahrscheinlich unterschiedliche Mengen an Nachrichten. In der Regel erhalten und verarbeiten schnellere und reaktionsfähigere Nutzer einen größeren Teil der Nachrichtenlast.
Bei dieser Verteilungsmethode über mehrere Consumer hinweg kann die Reihenfolge, in der Nachrichten empfangen und verarbeitet werden, variieren. Wenn Nachrichtensortierung für das Abo nicht aktiviert ist und Verlage keine Sortierungsschlüssel angeben, werden Nachrichten nicht garantiert in der Reihenfolge verarbeitet, in der sie veröffentlicht wurden.
Beachten Sie, dass Nachrichten möglicherweise bereits an Kunden gesendet wurden. Ein Rückstand nicht bestätigter Nachrichten bedeutet nicht unbedingt, dass Sie diese Nachrichten bei Ihrem nächsten Pull-Request erhalten. Ein Consumer kann ein Nutzer sein, der „pull“ in der Google Cloud Konsole oder der Google Cloud CLI verwendet oder einen benutzerdefinierten Abonnenten lokal ausführt, um Nachrichten zu prüfen.
Bei unären Pull-Clients kann es vorkommen, dass bei einigen Pull-Anfragen keine Nachrichten zurückgegeben werden. Wie im Abschnitt Nicht genügend Abonnenten beschrieben, wird empfohlen, mehrere ausstehende Pull-Anfragen zu haben, da bei einigen Anfragen möglicherweise weniger als die maximal konfigurierte Anzahl von Nachrichten oder sogar keine Nachrichten zurückgegeben werden, auch wenn ein Backlog vorhanden ist. Das liegt daran, dass andere Verbraucher möglicherweise Leases für die verfügbaren Nachrichten haben.
Wenn ein Consumer eine Nachricht nicht innerhalb der Bestätigungsfrist bestätigt oder die Nachricht negativ bestätigt (NACK), versucht Pub/Sub, sie noch einmal zuzustellen. Dieser erneute Zustellversuch kann an jeden aktiven Nutzer des Abos erfolgen, nicht nur an den, der die Nachricht ursprünglich erhalten hat. Daher kann eine bestimmte Nachrichten-ID während ihres Lebenszyklus an mehrere verschiedene mit dem Abo verbundene Nutzer gesendet und von diesen verarbeitet werden, bis einer von ihnen sie erfolgreich bestätigt.
Wenn Sie vermuten, dass Nachrichten unerwartet verteilt werden, prüfen Sie, ob mehrere Consumer gleichzeitig mit dem Abo verbunden sind, und sehen Sie sich die einzelnen Leistungsmesswerte und Konfigurationen an.
Nach dem Abo filtern
Prüfen Sie, ob dem Abo ein Filter zugeordnet ist. Wenn ja, erhalten Sie nur die Nachrichten, die dem Filter entsprechen. Der Pub/Sub-Dienst bestätigt automatisch die Nachrichten, die nicht mit dem Filter übereinstimmen. Auswirkungen von Filtern auf Backlog-Messwerte
Option returnImmediately verwenden
Wenn Ihr Client den unären Pull-Vorgang verwendet, prüfen Sie, ob das Feld returnImmediately auf „true“ gesetzt ist. Dies ist ein eingestelltes Feld, das den Pub/Sub-Dienst anweist, sofort auf die Pull-Anfrage zu antworten, auch wenn keine Nachrichten zurückgegeben werden. Dies kann dazu führen, dass Pull-Requests mit 0 Nachrichten zurückgegeben werden, auch wenn ein Backlog vorhanden ist.
Probleme bei der Clientkonfiguration
Wenn Sie die Java-Clientbibliothek verwenden und Ihren Abonnenten mit einem benutzerdefinierten gRPC-Channel initialisieren, indem Sie die Methode setChannelProvider() verwenden, sollten Sie darauf achten, dass die Einstellung maxInboundMessageSize beim Erstellen von TransportChannelProvider mindestens 20 MB beträgt (entsprechend dem Standardwert der Bibliothek). Wenn dieser Wert kleiner als 10 MB ist, werden Nachrichten, die größer als maxInboundMessageSize sind, nicht richtig empfangen. Häufig verwendete Methoden zum Konfigurieren dieser Einstellung sind InstantiatingGrpcChannelProvider.Builder.setMaxInboundMetadataSize() und ManagedChannelBuilder.maxInboundMetadataSize().
Umgang mit Duplikaten
Die Duplizierung von Nachrichten in Pub/Sub tritt häufig auf, wenn Abonnenten Nachrichten nicht innerhalb der Bestätigungsfrist bestätigen können. Dadurch werden die Nachrichten noch einmal zugestellt, was den Eindruck von Duplikaten erweckt. Sie können die Rate, mit der Abonnenten die Bestätigungsfrist verpassen, mit dem Messwert subscription/expired_ack_deadlines_count messen. Weitere Informationen zum Überwachen des Ablaufs des Quittierungszeitlimits
Verlängern Sie die Nachrichtenfristen, 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
modifyAckDeadlineverlängern.
Wenn Nachrichten im Abonnenten schneller abgerufen werden, als sie verarbeitet und bestätigt werden können, laufen einige Nachrichten möglicherweise ab und erfordern Fristverlängerungen. Wenn der Abonnent jedoch weiterhin überfordert ist, schlagen wiederholte Fristverlängerungen schließlich fehl. Im schlimmsten Fall kann dies dazu führen, dass ein Abonnent mit Duplikaten überflutet wird, was den Rückstand noch verschlimmert. Abgelaufene Duplikate generieren dann neue Duplikate.
Um den Abonnenten nicht zu überfordern, sollten Sie die Anzahl der Nachrichten reduzieren, die er gleichzeitig abruft. So muss der Abonnent innerhalb der Frist weniger Nachrichten verarbeiten. Weniger Nachrichten laufen ab und weniger Nachrichten werden noch einmal zugestellt.
Wenn Sie die Anzahl der Nachrichten verringern möchten, die der Abonnent gleichzeitig abruft, müssen Sie die Einstellung für die maximale Anzahl ausstehender Nachrichten in der Ablaufsteuerung Ihres Abonnenten verringern. Es gibt keinen universellen Wert. Sie müssen das Limit für die maximale Anzahl ausstehender Nachrichten an Ihren Durchsatz und Ihre Abonnentenkapazität anpassen. Beachten Sie, dass jede Anwendung Nachrichten unterschiedlich verarbeitet und unterschiedlich lange braucht, um eine Nachricht zu bestätigen.
Wiederholungsversuche erzwingen
Wenn Sie erzwingen möchten, dass Pub/Sub eine Nachricht noch einmal sendet, senden Sie eine nack-Anfrage. Wenn Sie die allgemeinen Clientbibliotheken nicht verwenden, senden Sie eine modifyAckDeadline-Anfrage mit einem ackDeadlineSeconds-Wert von 0.
Reihenfolgeschlüssel
Wenn Pub/Sub eine Nachricht mit einem Reihenfolgeschlüssel noch einmal sendet, werden auch alle nachfolgenden Nachrichten mit demselben Reihenfolgeschlüssel noch einmal gesendet, auch wenn sie zuvor bestätigt wurden. Dadurch wird die Reihenfolge der Sequenz beibehalten. Es gibt jedoch keine strikte Garantie dafür, dass abhängige Nachrichten erst nach der erfolgreichen Bestätigung vorheriger Nachrichten in der Sequenz gesendet werden.
Der Abonnent bestätigt die Nachrichten
Weitere Informationen finden Sie unter Abonnent sendet NACK-Nachrichten.
Fehlerbehebung bei einem StreamingPull-Abo
Beziehung zwischen dem Messwert für die Anfragelatenz und der End-to-End-Übertragungslatenz
Bei StreamingPull stellt der Messwert serviceruntime.googleapis.com/api/request_latencies die Zeit dar, in der der Stream geöffnet ist. Der Messwert ist nicht hilfreich, um die End-to-End-Latenz zu bestimmen.
Anstelle des Messwerts für die Anfrage-Latenz sollten Sie den Status der Zustellungslatenz verwenden, um zu prüfen, welche Faktoren zu einer erhöhten End-to-End-Zustellungslatenz beitragen.
StreamingPull-Verbindungen werden mit einem Fehlerstatus geschlossen
StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Im Gegensatz zu einem Fehlerstatus für unäre RPCs ist dieser Status für StreamingPull nur ein Hinweis darauf, dass die Verbindung zum Stream getrennt wurde. Die Anfragen schlagen nicht fehl. Aus diesem Grund ist es möglich, dass die StreamingPull API eine anscheinend überraschende Fehlerrate von 100% hat. Dies ist designbedingt.
Da StreamingPull-Streams immer mit einem Fehler enden, ist es nicht hilfreich, die Stream-Beendigungskennzahlen während der Fehlerdiagnose zu untersuchen. Konzentrieren Sie sich stattdessen auf den Messwert für die StreamingPull-Antwort subscription/streaming_pull_response_count, gruppiert nach response_code oder response_class.
Suchen Sie nach diesen Fehlern:
Fehler bei der Vorbedingung können auftreten, wenn noch nicht versendete Nachrichten mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind. Wenn Sie das Abrufen fortsetzen möchten, stellen Sie den Zugriff auf den Schlüssel wieder her.
Fehler vom Typ „Nicht verfügbar“ können auftreten, wenn Pub/Sub eine Anfrage nicht verarbeiten kann. Dies ist höchstwahrscheinlich ein vorübergehender Zustand und die Clientbibliothek wiederholt die Anfragen. Wenn Sie eine Clientbibliothek verwenden, müssen Sie nichts weiter tun.
Fehler vom Typ „Nicht gefunden“ können auftreten, wenn das Abo gelöscht wurde oder nie vorhanden war. Letzteres ist der Fall, wenn Sie einen ungültigen Abopfad angegeben haben.