In diesem Dokument finden Sie einige gängige Tipps zur Fehlerbehebung bei Pub/Sub-Pull-Abos. Weitere Informationen zu Pull-Abos finden Sie im Leitfaden für Pull-Abonnenten.
Um Ihr Pub/Sub-Abo effektiv zu überwachen, sollten Sie sich zuerst den Status der Zustellungslatenz (subscription/delivery_latency_health_score) ansehen, um zu prüfen, welche Faktoren zu einer unerwarteten oder erhöhten Latenz beitragen können.
Alter der ältesten unbestätigten Nachricht steigt weiter
oldest_unacked_message_age ist ein wichtiger Messwert für das Monitoring des Zustands von Pub/Sub-Abos. Er misst das Alter der ältesten Nachricht im Backlog eines Abos in Sekunden, die noch nicht von einem Abonnenten bestätigt wurde. Dieser Messwert bietet wertvolle Einblicke in potenzielle Verarbeitungsverzögerungen oder Engpässe.
Durch das Monitoring des Nachrichten-Backlogs wird eine zeitnahe und effiziente Nachrichtenverarbeitung sichergestellt. Wenn Sie das Alter der ältesten unbestätigten Nachricht im Blick behalten, können Sie proaktiv Situationen erkennen, in denen Consumer ins Hintertreffen geraten. So können Sie frühzeitig eingreifen, um potenzielle Probleme im Zusammenhang mit Leistungseinbußen zu beheben.
Hier sind einige der häufigen Backlog-Probleme, 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 dem Nachrichtenvolumen nicht Schritt halten können. Konzentrieren Sie sich in diesem Fall auf die Abonnentenkomponenten:
Clientzustand: Analysieren Sie die Ressourcenauslastung auf Computern, auf denen Abonnentenclients gehostet werden, z. B. CPU, Arbeitsspeicher und Netzwerkbandbreite. Suchen Sie nach Druckpunkten, die die Verarbeitungseffizienz beeinträchtigen könnten.
Clientcode: Prüfen Sie die letzten Codeänderungen und die Fehlerlogs. Fehler oder Ineffizienzen im Abonnentencode können die Verarbeitungsraten von Nachrichten erheblich beeinträchtigen. Möglicherweise gibt es Probleme mit bestimmten Nachrichten. Beispielsweise müssen mehrere Nachrichten möglicherweise 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 Einschränkungen Ihres Hosting-Dienstes überschritten haben. Wenn die Abonnenten in Google Cloudgehostet werden, prüfen Sie die Ressourcenkontingente für Compute Engine oder GKE, 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 zuzustellen. Wiederholte negative Bestätigungen für eine Nachricht führen zu Duplikaten und möglicherweise zu einer hohen Verzögerung bei der Nachrichtenzustellung.
Beachten Sie, dass das Senden einer negativen Bestätigung für eine Nachricht nicht garantiert, dass beim nächsten Abruf eine andere Nachricht abgerufen wird. Die Richtlinie für die erneute Zustellung von Pub/Sub kann dazu führen, dass abgelehnte Nachrichten vor neuen Nachrichten noch einmal zugestellt werden. 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 vor der erneuten Zustellung etwas länger brauchen.
Wenn Sie bestimmte Nachrichten absichtlich überspringen müssen, empfiehlt es sich, 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 absichtlich oder unabsichtlich nicht bestätigt werden, führt dies zu Rückständen und doppelten Zustellungen.
Hohe Übermittlungslatenz
Die Zustellungslatenz 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
Wenn Sie StreamingPull verwenden, sollten Sie mehrere offene StreamingPull-Verbindungen zu Ihrem Abo aufrechterhalten, um eine konstant niedrige Latenz zu erreichen. Ohne aktive Abonnentenverbindungen kann Pub/Sub Nachrichten nicht zeitnah zustellen. Ein einzelner Stream könnte 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 für eingehende Nachrichten haben.
Wenn Sie Clients mit unärem Pull verwenden, sollten Sie mehrere ausstehende Pull-Anfragen für Ihr Abo aufrechterhalten, um eine konstant niedrige Latenz zu erreichen. Bei seltenen Anfragen können sich Nachrichten im Rückstand ansammeln und die Latenz erhöhen. So lassen sich Verbindungslücken minimieren und die Übermittlungslatenz verbessern.
Die High-Level-Clientbibliothek wird für Fälle empfohlen, in denen Sie einen hohen Durchsatz und eine niedrige Latenz bei minimalem Betriebsaufwand und minimalen Verarbeitungskosten benötigen. Standardmäßig verwendet die High-Level-Clientbibliothek die StreamingPull API, da sie in der Regel die bessere Wahl ist, um die Latenz zu minimieren. Die allgemeinen Clientbibliotheken enthalten vordefinierte Funktionen und Klassen, die die zugrunde liegenden API-Aufrufe für Authentifizierung, Durchsatz- und Latenzoptimierung, Nachrichtenformatierung und andere Features verarbeiten.
Probleme bei der Clientkonfiguration
Weitere Informationen finden Sie unter Probleme mit der Clientkonfiguration.
Hoher Rückstand
Beachten Sie, dass ein Nachrichten-Backlog von nicht bestätigten Nachrichten in einem Pub/Sub-Abo die End-to-End-Latenz erhöht, da Nachrichten nicht sofort von Abonnenten verarbeitet werden.
Sortierschlüssel und genau einmalige Zustellung
Sortierschlüssel und die genau einmalige Zustellung sind nützliche Funktionen, erfordern jedoch zusätzliche Koordination innerhalb von Pub/Sub, um eine korrekte Zustellung zu gewährleisten. Diese Koordination kann die Verfügbarkeit verringern und die Latenz erhöhen. Der Unterschied ist im stabilen Zustand minimal, aber alle erforderlichen Koordinierungsschritte können zu vorübergehenden Erhöhungen der Latenz oder einer erhöhten Fehlerrate führen. Wenn die Sortierung aktiviert ist, können Nachrichten mit einem Reihenfolgeschlüssel erst zugestellt werden, wenn frühere Nachrichten mit demselben Reihenfolgeschlüssel bestätigt wurden.
Überlegen Sie, ob die Nachrichtenreihenfolge oder die genau einmalige Zustellung für Ihre Anwendung unbedingt erforderlich sind. Wenn eine niedrige Latenz für Sie oberste Priorität hat, kann die Minimierung der Verwendung dieser Funktionen dazu beitragen, Verzögerungen bei der Nachrichtenverarbeitung zu reduzieren.
Größere Nachrichten
Ein plötzlicher Anstieg der Nachrichtengröße kann die Übertragungszeit zwischen Pub/Sub und Ihrem Client erhöhen und die Verarbeitungszeit der Nachrichten auf der Clientseite verlangsamen.
Wenn Sie eine Zunahme der Zustellungslatenz feststellen, können Sie die Nachrichtengrößen mit dem Messwert topic/message_sizes prüfen und nach topic_id gruppieren. Setzen Sie Spitzen bei der Nachrichtengröße mit beobachteten Leistungsproblemen in Beziehung.
Fehlende Nachrichten
Wenn Sie vermuten, dass Nachrichten nicht erfolgreich an Ihren Abonnenten zugestellt werden, kann dies einen der folgenden Gründe haben.
Nachrichtenverteilung in Pub/Sub-Abos mit mehreren Nutzern
In Pub/Sub werden Nachrichten möglicherweise ungleichmäßig auf Nutzer desselben Abos verteilt. Pub/Sub verteilt die Nachrichtenlast auf alle aktiven Clients. Das Hauptziel ist jedoch, den Gesamtdurchsatz der Nachrichtenverarbeitung zu maximieren und den Rückstand zu minimieren, anstatt eine perfekt gleichmäßige Verteilung zu gewährleisten. Das System leitet dynamisch mehr Nachrichten an Verbraucher weiter, die eine höhere Kapazität aufweisen, d. h. solche, die Nachrichten schnell bestätigen und nicht durch ihre Einstellungen für die Flusssteuerung eingeschränkt sind. Verbraucher, die Nachrichten mit unterschiedlichen Geschwindigkeiten verarbeiten oder unter unterschiedlichen Bedingungen arbeiten (z.B. Ressourcenverfügbarkeit, Netzwerklatenz), verarbeiten wahrscheinlich unterschiedliche Nachrichtenmengen. In der Regel erhalten und verarbeiten schnellere und reaktionsfähigere Consumer einen größeren Teil der Nachrichtenlast.
Diese Verteilungsmethode auf mehrere Consumer bedeutet, dass die Reihenfolge, in der Nachrichten empfangen und verarbeitet werden, variieren kann. Wenn die Nachrichtenreihenfolge für das Abo nicht aktiviert ist und Publisher keine Reihenfolgeschlüssel angeben, werden Nachrichten nicht garantiert in der Reihenfolge verarbeitet, in der sie veröffentlicht wurden.
Beachten Sie, dass Nachrichten möglicherweise bereits an Clients ausstehen und ein Rückstand an nicht bestätigten Nachrichten nicht unbedingt bedeutet, dass Sie diese Nachrichten bei Ihrer nächsten Pull-Anfrage erhalten. Beachten Sie, dass ein Nutzer jemand sein kann, der Pull in der Google Cloud Console 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 einige Pull-Anfragen keine Nachrichten zurückgeben. Wie im Abschnitt Nicht genügend Abonnenten erläutert, wird empfohlen, mehrere ausstehende Pull-Anfragen zu verwalten, da einige Anfragen weniger als die maximal konfigurierte Anzahl von Nachrichten oder sogar null Nachrichten zurückgeben können, selbst wenn ein Backlog vorhanden ist. Das liegt daran, dass andere Consumer 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 Zustellungsversuch kann an jeden aktiven Consumer im Abo erfolgen, nicht unbedingt an den, der die Nachricht ursprünglich erhalten hat. Daher kann eine bestimmte Nachrichten-ID an mehrere verschiedene Nutzer, die mit dem Abo verbunden sind, zugestellt und von ihnen verarbeitet werden, bis einer von ihnen sie erfolgreich bestätigt.
Wenn Sie ein unerwartetes Verhalten bei der Nachrichtenverteilung vermuten, prüfen Sie, ob mehrere Nutzer 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. In diesem Fall erhalten Sie nur die Nachrichten, die dem Filter entsprechen. Der Pub/Sub-Dienst bestätigt automatisch die Nachrichten, die nicht mit dem Filter übereinstimmen. Berücksichtigen Sie, wie sich Filter auf Backlog-Messwerte auswirken.
Option returnImmediately verwenden
Wenn Ihr Client den unären Pull verwendet, prüfen Sie, ob das Feld returnImmediately auf „true“ gesetzt ist. Dies ist ein verworfenes 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-Anfragen mit 0 Nachrichten zurückgegeben werden, auch wenn ein Rückstand vorhanden ist.
Probleme bei der Clientkonfiguration
Wenn Sie die Java-Clientbibliothek verwenden und Ihren Subscriber mit einem benutzerdefinierten gRPC-Kanal über die Methode setChannelProvider() initialisieren, sollten Sie darauf achten, dass die Einstellung maxInboundMessageSize beim Erstellen von TransportChannelProvider mindestens 20 MB beträgt (entspricht dem Standardwert der Bibliothek). Wenn dieser Wert kleiner als 10 MB ist, werden Nachrichten, die größer als maxInboundMessageSize sind, nicht richtig empfangen. Einige gängige Methoden zum Konfigurieren dieser Einstellung sind InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize() und ManagedChannelBuilder.maxInboundMessageSize().
Umgang mit Duplikaten
In den folgenden Fällen kann ein Abonnent doppelte Nachrichten erhalten:
Erneute Übermittlung. Ein Client hat eine Nachricht negativ bestätigt oder die Bestätigungsfrist ist abgelaufen. Dieses Verhalten ist so vorgesehen.
Doppelte Übermittlung. Eine Nachricht wird nach einer erfolgreichen Bestätigung oder vor Ablauf der Bestätigungsfrist noch einmal gesendet. Abos mit aktivierter genau einmaligen Zustellung erhalten keine doppelten Zustellungen.
Doppelte Nachrichten vom Publisher. Der Publisher sendet eine Nachricht aufgrund der Anwendungslogik des Publishers zweimal. Der Pub/Sub-Dienst behandelt diese als separate Pub/Sub-Nachrichten und weist ihnen eindeutige Nachrichten-IDs zu.
Wenn die Nachrichten-IDs identisch sind, bedeutet das, dass Pub/Sub die Nachricht noch einmal gesendet oder zugestellt hat. Wenn die Nachrichten-IDs unterschiedlich sind, bedeutet dies, dass die Duplizierung vorgelagert beim Publisher aufgetreten ist.
Abgelaufene Bestätigungsfristen
Nachrichtenduplikate in Pub/Sub treten häufig auf, wenn Abonnenten Nachrichten nicht innerhalb der Bestätigungsfrist bestätigen können. Dies führt dazu, dass die Nachrichten noch einmal gesendet werden, was den Eindruck von Duplikaten erweckt. Mit dem Messwert subscription/expired_ack_deadlines_count können Sie die Rate messen, mit der Abonnenten die Bestätigungsfrist verpassen. Weitere Informationen zum Überwachen des Ablaufs der Bestätigungsfrist
Wenn Sie die Duplikationsrate reduzieren möchten, verlängern Sie die Nachrichtenfristen.
- Clientbibliotheken verlängern die Frist automatisch. Es gibt jedoch Standardlimits für die maximale Fristverlängerung, die Sie konfigurieren können.
- Wenn Sie eine eigene Clientbibliothek erstellen, verwenden Sie die Methode
modifyAckDeadline, um die Bestätigungsfrist zu verlä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 eine Fristverlängerung. Wenn der Abonnent jedoch weiterhin überfordert ist, schlagen wiederholte Fristverlängerungen irgendwann fehl. Im schlimmsten Fall kann dies dazu führen, dass ein Abonnent mit Duplikaten überlastet wird, was den Rückstand verschlimmert. Wenn Duplikate ablaufen, werden neue Duplikate generiert.
Um den Abonnenten nicht zu überfordern, reduzieren Sie die Anzahl der Nachrichten, die der Abonnent gleichzeitig abruft. So muss der Abonnent innerhalb der Frist weniger Nachrichten verarbeiten. Es laufen weniger Nachrichten ab und es werden weniger Nachrichten noch einmal zugestellt.
Wenn Sie die Anzahl der Nachrichten reduzieren möchten, die der Abonnent gleichzeitig abruft, müssen Sie die Einstellung für die maximale Anzahl ausstehender Nachrichten in der Ablaufsteuerung des Abonnenten reduzieren. Es gibt keinen allgemeingültigen Wert. Sie müssen das Limit für die maximale Anzahl ausstehender Nachrichten also an Ihren Durchsatz und die 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 Pub/Sub dazu zwingen möchten, eine Nachricht noch einmal zu senden, senden Sie eine nack-Anfrage. Wenn Sie die allgemeinen Clientbibliotheken nicht verwenden, senden Sie eine modifyAckDeadline-Anfrage, bei der ackDeadlineSeconds auf 0 gesetzt ist.
Sortierschlüssel
Wenn Pub/Sub eine Nachricht mit einem Reihenfolgeschlüssel noch einmal zustellt, werden auch alle nachfolgenden Nachrichten mit demselben Reihenfolgeschlüssel noch einmal zugestellt, auch wenn sie zuvor bestätigt wurden. Dadurch wird die Reihenfolge der Sequenz beibehalten. Es gibt jedoch keine strikte Garantie, dass abhängige Nachrichten erst nach der erfolgreichen Bestätigung vorheriger Nachrichten in der Sequenz gesendet werden.
Abonnent sendet negative Bestätigungen für die Nachrichten
Siehe Abonnent bestätigt die Nachrichten nicht.
Suchvorgänge
Wenn Sie einen Suchvorgang für einen Zeitstempel oder einen Snapshot ausführen, stellt Pub/Sub Nachrichten, die nach dem Zeitstempel veröffentlicht wurden oder im Snapshot enthalten sind, noch einmal zu. Diese erneute Zustellung ist ein erwartetes Verhalten und tritt auch dann auf, wenn die Funktion „Genau einmal zugestellt“ für das Abo aktiviert ist. Weitere Informationen finden Sie unter Seek mit Exactly-Once-Zustellung.
Nachgelagerte Deduplizierung
Abonnenten und andere Downstream-Systeme können Nachrichten deduplizieren. Dataflow unterstützt beispielsweise die genau einmalige Zustellung. Wenn unerwartet doppelte Nachrichten in nachgelagerten Prozessen angezeigt werden, liegt die Ursache möglicherweise eher beim Abonnenten als bei Pub/Sub.
Fehlerbehebung bei einem StreamingPull-Abo
Beziehung zwischen dem Messwert für die Anfragelatenz und der End-to-End-Zustellungslatenz
Bei StreamingPull stellt der Messwert serviceruntime.googleapis.com/api/request_latencies die Zeit dar, für die der Stream geöffnet ist. Der Messwert ist nicht hilfreich, um die End-to-End-Zustellungslatenz zu bestimmen.
Verwenden Sie anstelle des Messwerts für die Anfragelatenz den Zustandswert für die Zustellungslatenz, um zu prüfen, welche Faktoren zu einer erhöhten End-to-End-Zustellungslatenz beitragen.
StreamingPull-Verbindungen werden mit einem Status ungleich „OK“ 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. Auch wenn die StreamingPull API eine überraschende Fehlerrate von 100% hat, ist dieses Verhalten beabsichtigt.
Da StreamingPull-Streams immer mit einem Fehler geschlossen werden, ist es nicht hilfreich, die Messwerte für die Stream-Beendigung bei der Fehlerdiagnose zu untersuchen. Konzentrieren Sie sich stattdessen auf den StreamingPull-Antwortmesswert subscription/streaming_pull_response_count, gruppiert nach response_code oder response_class.
Suchen Sie nach diesen Fehlern:
Failed precondition-Fehler können auftreten, wenn sich im Abo-Backlog Nachrichten befinden, die mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind. Wenn Sie den Pull-Vorgang 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 existiert hat. Letzteres passiert, wenn Sie einen ungültigen Abopfad angegeben haben.