In diesem Dokument finden Sie einige allgemeine 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 Zustelllatenz-Gesundheitswert (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 nimmt weiter zu
Der oldest_unacked_message_age ist ein wichtiger Messwert für die Überwachung der Systemintegrität von Pub/Sub-Abos. Er 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 bietet wertvolle Einblicke in potenzielle Verarbeitungsverzögerungen oder Engpässe.
Durch die Überwachung des Nachrichtenrückstands wird eine zeitnahe und effiziente Nachrichtenverarbeitung gewährleistet. Wenn Sie das Alter der ältesten unbestätigten Nachricht verfolgen, können Sie proaktiv Situationen erkennen, in denen die Verarbeitung durch die Abonnenten hinterherhinkt. So können Sie frühzeitig eingreifen, um potenzielle Probleme im Zusammenhang mit einer verminderten Leistung zu beheben.
Einige der häufigsten Probleme mit dem Rückstand, die Sie untersuchen können, sind:
Probleme bei der Clientkonfiguration
Wenn die Messwerte oldest_unacked_message_age und num_undelivered_messages gleichzeitig steigen, bedeutet das möglicherweise, dass die Abonnenten mit dem Nachrichtenvolumen nicht mithalten können. In dieser Situation sollten Sie sich auf die Abonnentenkomponenten konzentrieren:
Client-Systemdiagnose: Analysieren Sie die Ressourcennutzung auf den Computern, auf denen Abonnentenclients gehostet werden, z. B. CPU, Arbeitsspeicher und Netzwerkbandbreite. Suchen Sie nach Engpässen, die die Verarbeitungseffizienz beeinträchtigen könnten.
Clientcode: Überprüfen Sie die letzten Codeänderungen und Fehlerlogs. Fehler oder Ineffizienzen im Abonnentencode können sich erheblich auf die Nachrichtenverarbeitungsraten auswirken. Beachten Sie, dass es Probleme mit 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 Kontingente oder Beschränkungen für Pub/Sub überschritten haben, die von Ihrem Hostingdienst auferlegt wurden. Wenn die Abonnenten in Google Cloudgehostet werden, prüfen Sie die Compute Engine oder GKE Ressourcenkontingente, um potenzielle Engpässe zu vermeiden.
Abonnent hat die Nachrichten negativ bestätigt
Wenn ein Abonnent eine Nachricht negativ bestätigt, 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 Zustellung von Nachrichten.
Beachten Sie, dass eine negative Bestätigung für eine Nachricht nicht garantiert, dass beim nächsten Pull eine andere Nachricht abgerufen wird. Die Richtlinie für die erneute Zustellung von Pub/Sub kann weiterhin negativ bestätigte Nachrichten vor neuen Nachrichten zustellen. Verlassen Sie sich daher nicht auf negative Bestätigungen als Methode zum Filtern oder Überspringen bestimmter Nachrichten. 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, sollten Sie sie bestätigen, auch wenn Sie sie nicht verarbeiten. Dadurch werden sie aus dem Abo entfernt, unnötige erneute Zustellungen vermieden und der Ressourcenverbrauch reduziert. Wenn Nachrichten nicht bestätigt werden, unabhängig davon, ob dies beabsichtigt ist oder nicht, entstehen Probleme mit dem Rückstand und doppelte Zustellungen.
Hohe Zustelllatenz
Die Zustelllatenz in Pub/Sub ist die Zeit, die eine Nachricht vom Publisher zum Abonnenten benötigt. Einige mögliche Ursachen für eine hohe Zustelllatenz werden in den nächsten Abschnitten beschrieben.
Nicht genügend Abonnenten
Damit bei Clients, die StreamingPull verwenden, eine konstant niedrige Latenz erreicht wird, sollten Sie mehrere offene StreamingPull-Verbindungen zu Ihrem Abo aufrechterhalten. Ohne aktive Abonnentenverbindungen kann Pub/Sub Nachrichten nicht zeitnah zustellen. Ein einzelner Stream kann ein Single Point of Failure sein, wodurch das Risiko von Verzögerungen steigt. 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.
Damit bei Clients, die den unären Pull verwenden, eine konstant niedrige Latenz erreicht wird, sollten Sie mehrere ausstehende Pull-Anfragen an Ihr Abo senden. Seltene Anfragen können dazu führen, dass sich Nachrichten im Rückstand ansammeln und die Latenz steigt. Dieser Ansatz trägt dazu bei, Lücken bei der Verbindung zu minimieren und die Zustelllatenz 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 die Authentifizierung, die Optimierung von Durchsatz und Latenz, die 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 unbestätigten Nachrichten in einem Pub/Sub-Abo erhöht die End-to-End-Latenz, da Nachrichten nicht sofort von Abonnenten verarbeitet werden.
Reihenfolgeschlüssel und genau einmalige Zustellung
Reihenfolgeschlüssel und genau einmalige Zustellung sind wertvolle Funktionen, erfordern jedoch zusätzliche Abstimmung in Pub/Sub, um die korrekte Zustellung zu gewährleisten. Diese Abstimmung kann die Verfügbarkeit verringern und die Latenz erhöhen. Im Normalzustand ist der Unterschied minimal, aber alle erforderlichen Abstimmungsschritte können zu vorübergehenden Erhöhungen der Latenz oder einer erhöhten Fehlerrate führen. Wenn die Reihenfolge 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 Ihre oberste Priorität ist, kann es helfen, die Verwendung dieser Funktionen zu minimieren, um Verzögerungen bei der Nachrichtenverarbeitung zu reduzieren.
Zunahme der Nachrichtengröße
Eine plötzliche Zunahme 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 Zunahme der Zustelllatenz feststellen, können Sie die Nachrichtengrößen mit dem topic/message_sizes Messwert 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 einer der folgenden Gründe dafür verantwortlich sein.
Nachrichtenverteilung in Pub/Sub-Abos mit mehreren Abonnenten
In Pub/Sub werden Nachrichten möglicherweise ungleichmäßig auf Abonnenten desselben Abos verteilt. Pub/Sub führt einen Lastenausgleich für Nachrichten auf alle aktiven Clients durch. Das Hauptziel besteht jedoch darin, den Gesamtdurchsatz bei der Nachrichtenverarbeitung zu maximieren und den Rückstand zu minimieren, anstatt eine gleichmäßige Verteilung zu gewährleisten. Das System leitet dynamisch mehr Nachrichten an Abonnenten weiter, die eine höhere Kapazität aufweisen – also an diejenigen, die Nachrichten schnell bestätigen und nicht durch ihre Einstellungen für die Ablaufsteuerung eingeschränkt sind. Abonnenten, die Nachrichten mit unterschiedlichen Geschwindigkeiten 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 Abonnenten einen größeren Teil der Nachrichtenlast.
Diese Verteilungsmethode auf mehrere Abonnenten 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 einfügen, ist nicht garantiert, dass Nachrichten von Abonnenten in der Reihenfolge verarbeitet werden, in der sie veröffentlicht wurden.
Beachten Sie, dass Nachrichten möglicherweise bereits an Clients ausstehen und ein Rückstand von unbestätigten Nachrichten nicht unbedingt bedeutet, dass Sie diese Nachrichten bei Ihrer nächsten Pull-Anfrage erhalten. Ein Abonnent kann jemand sein, 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 senden, da einige Anfragen möglicherweise weniger als die maximal konfigurierte Anzahl von Nachrichten oder sogar keine Nachrichten zurückgeben, auch wenn ein Rückstand vorhanden ist. Das liegt daran, dass andere Abonnenten möglicherweise Leases für die verfügbaren Nachrichten haben.
Wenn ein Abonnent eine Nachricht nicht innerhalb der Bestätigungsfrist bestätigt oder sie negativ bestätigt, versucht Pub/Sub, sie noch einmal zuzustellen. Dieser Zustellversuch kann an jeden aktiven Abonnenten des Abos erfolgen, nicht unbedingt an den, der sie ursprünglich erhalten hat. Daher kann eine bestimmte Nachrichten-ID im Laufe der Zeit an mehrere verschiedene Abonnenten zugestellt werden, die mit dem Abo verbunden sind, und die Verarbeitung kann von mehreren Abonnenten versucht werden, bis einer von ihnen sie erfolgreich bestätigt.
Wenn Sie unerwartete Verhaltensweisen bei der Nachrichtenverteilung vermuten, prüfen Sie, ob mehrere Abonnenten gleichzeitig mit dem Abo verbunden sind, und untersuchen Sie ihre individuellen Leistungsmesswerte und Konfigurationen.
Filter für das Abo
Prüfen Sie, ob dem Abo ein Filter angehängt 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. Überlegen Sie, wie sich Filter auf Rückstandsmesswerte auswirken.
Option returnImmediately verwenden
Wenn Ihr Client den unären Pull verwendet, prüfen Sie, ob das returnImmediately Feld auf „true“ gesetzt ist. Dies ist ein veraltetes 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 Abonnenten
mit einem benutzerdefinierten gRPC-Kanal initialisieren, indem Sie die
setChannelProvider()
Methode verwenden, sollten Sie darauf achten, dass die maxInboundMessageSize Einstellung beim Erstellen von TransportChannelProvider mindestens
20 MB beträgt (entsprechend dem Standardwert der Bibliothek)
). Wenn dieser Wert weniger als 10 MB beträgt, 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
Die Nachrichtenduplizierung 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 subscription/expired_ack_deadlines_count Messwert messen. Weitere Informationen zum Überwachen des Ablaufs der Bestätigungsfrist
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
modifyAckDeadlineMethode 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 müssen verlängert werden. Wenn der Abonnent jedoch weiterhin überlastet ist, schlagen wiederholte Fristverlängerungen schließlich fehl. Im schlimmsten Fall kann dies dazu führen, dass der Abonnent mit Duplikaten überflutet wird, was den Rückstand noch verschlimmert. Abgelaufene Duplikate generieren dann neue Duplikate.
Um den Abonnenten nicht zu überlasten, reduzieren Sie die Anzahl der Nachrichten, die der Abonnent gleichzeitig abruft. So hat der Abonnent weniger Nachrichten, die er innerhalb der Frist verarbeiten muss. Weniger Nachrichten laufen ab und weniger Nachrichten werden noch einmal zugestellt.
Um die Anzahl der Nachrichten zu reduzieren, die der Abonnent gleichzeitig abruft, müssen Sie die Einstellung für die maximale Anzahl ausstehender Nachrichten in der Konfiguration der Ablaufsteuerung Ihres Abonnenten reduzieren. Es gibt keinen Wert, der für alle Fälle geeignet ist. Sie müssen das Limit für die maximale Anzahl ausstehender Nachrichten an Ihren Durchsatz und die Kapazität des Abonnenten anpassen. Beachten Sie, dass jede Anwendung Nachrichten anders verarbeitet und unterschiedlich viel Zeit benötigt, 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 Clientbibliotheken auf hoher Ebene nicht verwenden, senden Sie eine modifyAckDeadline-Anfrage mit einem auf 0 gesetzten ackDeadlineSeconds.
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. So wird die Reihenfolge der Sequenz beibehalten. Es gibt jedoch keine strikte Garantie dafür, dass abhängige Nachrichten erst nach der erfolgreichen Bestätigung der vorherigen Nachrichten in der Sequenz gesendet werden.
Abonnent bestätigt die Nachrichten negativ
Weitere Informationen finden Sie unter Abonnent bestätigt die Nachrichten negativ.
Fehlerbehebung bei einem StreamingPull-Abo
Beziehung zwischen dem Messwert für die Anfragelatenz und der End-to-End-Zustelllatenz
Bei StreamingPull gibt der Messwert serviceruntime.googleapis.com/api/request_latencies die Zeit an, für die der Stream geöffnet ist. Der Messwert ist nicht hilfreich, um die End-to-End-Zustelllatenz zu bestimmen.
Verwenden Sie anstelle des Messwerts für die Anfragelatenz den Zustelllatenz-Gesundheitswert, um zu prüfen, welche Faktoren zu einer erhöhten End-to-End-Zustelllatenz beitragen.
StreamingPull-Verbindungen werden mit einem Fehlerstatus geschlossen
StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Anders als bei 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 StreamingPull-Messwert für die Antwort
subscription/streaming_pull_response_count,
gruppiert nach response_code oder response_class.
Suchen Sie nach folgenden Fehlern:
Fehler vom Typ Failed precondition können auftreten, wenn noch nicht versendete Nachrichten 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 Unavailable 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, sind keine Maßnahmen erforderlich.
Fehler vom Typ Not found können auftreten, wenn das Abo gelöscht wurde oder nie vorhanden war. Der zweite Fall tritt ein, wenn Sie einen ungültigen Abo-Pfad angegeben haben.