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 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.
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 sichergestellt. 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 sind einige häufige Probleme mit dem 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 der 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 Trusted Cloud by S3NSgehostet 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 Nachrichtenübermittlung.
Das Nacken einer Nachricht garantiert nicht, dass beim nächsten Pull eine andere Nachricht abgerufen wird. Gemäß der Richtlinie zur erneuten Zustellung von Pub/Sub werden möglicherweise weiterhin Nachrichten, die mit „nack“ 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, ob absichtlich oder nicht, führt dies zu Problemen mit dem Rückstand und zu doppelten 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 mehrere StreamingPull-Verbindungen zu Ihrem Abo offen gehalten werden. 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 High-Level-Clientbibliothek 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. Alle erforderlichen Koordinierungsschritte können jedoch 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 Zustellung 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 Nutzern
In Pub/Sub werden Nachrichten möglicherweise ungleichmäßig auf die Consumer verteilt. Dieses Verhalten tritt auf, weil Pub/Sub Nachrichten aus Effizienzgründen auf aktive Consumer verteilt. Manchmal erhält ein einzelner Kunde weniger Nachrichten als erwartet oder eine andere Teilmenge von Nachrichten als andere Kunden.
Es kann sein, dass Nachrichten 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 Trusted Cloud Konsole oder der Google Cloud CLI verwendet oder einen benutzerdefinierten Abonnenten lokal ausführt, um Nachrichten zu prüfen.
Bei Pull-Clients mit unärem Aufruf 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.
Wenn Sie eines dieser Verhaltensmuster vermuten, prüfen Sie, ob mehrere Nutzer gleichzeitig mit dem Abo verknüpft sind.
Nach dem Abo filtern
Prüfen Sie, ob dem Abo ein Filter zugewiesen 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. Das kann dazu führen, dass Pull-Requests mit 0 Nachrichten zurückgegeben werden, auch wenn es einen Rückstand gibt.
Probleme bei der Clientkonfiguration
Wenn Sie die Java-Clientbibliothek verwenden und Ihren Abonnenten mit einem benutzerdefinierten gRPC-Channel mit der Methode setChannelProvider() initialisieren, 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
Nachrichtenduplikate in Pub/Sub treten 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 es sind Fristverlängerungen erforderlich. 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. Ablaufende Duplikate generieren dann neue Duplikate.
Um den Abonnenten nicht zu überlasten, sollten Sie die Anzahl der Nachrichten reduzieren, die der Abonnent 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 des 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.
Sortierschlü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 der Messwertanfrage-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.