Dieses Dokument enthält einige allgemeine Tipps zur Fehlerbehebung bei Pub/Sub-Pull-Abos. Weitere Informationen zu Pull-Abos finden Sie im Pull-Abonnentenleitfaden.
Um dein Pub/Sub-Abo effektiv zu überwachen, solltest du dir zuerst die Systemdiagnose für die Übermittlungslatenz (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 ständig zu.
Der oldest_unacked_message_age ist ein wichtiger Messwert für das Monitoring der Integrität von Pub/Sub-Abos. Sie misst in Sekunden das Alter der ältesten Nachricht im Rückstand eines Abos, die noch nicht von einem Abonnenten bestätigt (bestätigt) wurde. Dieser Messwert bietet wertvolle Einblicke in potenzielle Verarbeitungsverzögerungen oder -engpässe.
Das Überwachen des Nachrichtenrückstands sorgt für eine zeitnahe und effiziente Nachrichtenverarbeitung. Indem Sie das Alter der ältesten unbestätigten Nachricht erfassen, können Sie proaktiv Situationen erkennen, in denen Nutzer in Rückstand geraten. So können frühzeitig potenzielle Probleme im Zusammenhang mit Leistungseinbußen behoben werden.
Zu den häufigen Rückstandsproblemen, die Sie untersuchen können, gehören:
Probleme bei der Clientkonfiguration
Wenn die Messwerte „oldest_unacked_message_age“ und „num_undelivered_messages“ gleichzeitig steigen, kann das bedeuten, dass die Abonnenten nicht mit dem Nachrichtenvolumen Schritt halten. Konzentriere dich in diesem Fall bei deiner Untersuchung 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: Überprüfen Sie die letzten Codeänderungen und prüfen Sie die Fehlerprotokolle. Fehler oder Ineffizienzen im Abonnentencode können die Verarbeitungsraten von Nachrichten erheblich beeinträchtigen. Beachten Sie, dass es bei bestimmten Nachrichten Probleme geben kann. Beispielsweise müssen möglicherweise mehrere Nachrichten gleichzeitig auf dieselbe Zeile in einer Datenbank zugreifen. Dies kann zu Konflikten und hoher Latenz führen.
Kontingentbeschränkungen: Achten Sie darauf, dass Sie keine Pub/Sub-Kontingente oder -Beschränkungen Ihres Hostingdienstes überschritten haben. Wenn die Abonnenten in Google Cloud gehostet 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 (nacks), signalisiert er Pub/Sub, dass die Nachricht nicht erfolgreich verarbeitet werden konnte. Pub/Sub versucht dann, dieselbe Nachricht noch einmal zu senden. Wenn eine Nachricht wiederholt wiederholt wird, führt dies zu Duplikaten und möglicherweise zu einer hohen Verzögerung bei der Zustellung.
Beachten Sie, dass das Anfügen einer Nachricht nicht garantiert, dass der nächste Abruf eine andere Nachricht abruft. Die Pub/Sub-Richtlinie für die erneute Zustellung stellt nackte Nachrichten möglicherweise weiterhin vor neuen Nachrichten bereit. Verlassen Sie sich daher nicht auf "nacks" zum Filtern oder Überspringen bestimmter Nachrichten. Legen Sie stattdessen eine Richtlinie für Wiederholungsversuche fest, vorzugsweise einen exponentiellen Backoff, um einzelne Nachrichten zurückzuhalten, die wahrscheinlich später verarbeitet werden können, aber vor der erneuten Übermittlung etwas länger dauern.
Wenn Sie bestimmte Nachrichten absichtlich überspringen müssen, wird empfohlen, sie zu bestätigen, auch wenn Sie sie nicht verarbeiten. Dadurch werden sie aus dem Abo entfernt, unnötige erneute Bereitstellungen werden vermieden und der Ressourcenverbrauch verringert. Wenn Nachrichten absichtlich nicht bestätigt werden, führt dies zu Rückstandsproblemen und doppelten Übermittlungen.
Hohe Bereitstellungslatenz
Die Zustellungslatenz in Pub/Sub ist die Zeit, die eine Nachricht von einem Publisher benötigt, um einen Abonnenten zu erreichen. In den nächsten Abschnitten werden einige mögliche Ursachen für eine hohe Übermittlungslatenz beschrieben.
Nicht genügend Abonnenten
Behalte für Clients, die StreamingPull verwenden, mehrere offene StreamingPull-Verbindungen zu deinem Abo bei, um eine konstant niedrige Latenz zu erreichen. Ohne aktive Abonnentenverbindungen kann Pub/Sub Nachrichten nicht sofort 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 bietet einen Einblick in die Anzahl der aktiven Streamingverbindungen. Damit sorgst du dafür, dass immer genügend Streams vorhanden sind, um eingehende Nachrichten zu verarbeiten.
Für Clients, die unäre Pull-Anfragen verwenden, sollten Sie mehrere ausstehende Pull-Anfragen für Ihr Abo verwalten, um eine konstant niedrige Latenz zu erreichen. Seltene Anfragen können potenziell Nachrichten im Rückstand ansammeln und die Latenz erhöhen. Dieser Ansatz trägt dazu bei, Verbindungslücken zu minimieren und die Lieferlatenz zu verbessern.
Die allgemeine Clientbibliothek wird empfohlen, wenn Sie einen hohen Durchsatz und eine niedrige Latenz bei minimalem operativem Aufwand und minimalen Verarbeitungskosten benötigen. Standardmäßig verwendet die übergeordnete Clientbibliothek die StreamingPull API, da sie in der Regel besser geeignet ist, um die Latenz zu minimieren. Die übergeordneten Clientbibliotheken enthalten vordefinierte Funktionen und Klassen, die die zugrunde liegenden API-Aufrufe für Authentifizierung, Durchsatz- und Latenzoptimierung, Nachrichtenformatierung und andere Funktionen verarbeiten.
Probleme bei der Clientkonfiguration
Siehe Probleme bei der Clientkonfiguration.
Hoher Rückstand
Beachten Sie, dass ein Nachrichtenrückstand von nicht bestätigten Nachrichten in einem Pub/Sub-Abo grundsätzlich die End-to-End-Latenz erhöht, da Nachrichten von Abonnenten nicht sofort verarbeitet werden.
Schlüsselbestellung und genau einmalige Zustellung
Schlüsselreihenfolge und genau einmalige Übermittlung sind wertvolle Funktionen. Sie erfordern jedoch eine zusätzliche Koordination in Pub/Sub, um eine korrekte Übermittlung zu gewährleisten. Diese Koordination kann die Verfügbarkeit verringern und die Latenz erhöhen. Im stabilen Zustand ist der Unterschied minimal, notwendige Koordinationsschritte können jedoch zu einer vorübergehenden Erhöhung 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 Sortierungsschlüssel bestätigt wurden.
Überlegen Sie, ob die Reihenfolge der Nachrichten oder die genau einmalige Zustellung für Ihre Anwendung absolut notwendig ist. Wenn niedrige Latenz für Ihre oberste Priorität ist, können Sie durch die Minimierung der Nutzung dieser Funktionen Verzögerungen bei der Nachrichtenverarbeitung reduzieren.
Größere Nachricht
Ein plötzlicher Anstieg der Nachrichtengröße kann möglicherweise die Übertragungszeit zwischen Pub/Sub und Ihrem Client erhöhen und die Verarbeitung der Nachrichten auf der Clientseite verlangsamen.
Bei einer erhöhten Zustellungslatenz können Sie die Nachrichtengrößen mithilfe des Messwerts 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 einer der folgenden Gründe dafür verantwortlich sein.
Nachrichtenverteilung in Pub/Sub-Abos mit mehreren Nutzern
In Pub/Sub werden Nachrichten möglicherweise ungleichmäßig auf die Nutzer verteilt. Dieses Verhalten ist darauf zurückzuführen, dass Pub/Sub aus Effizienzgründen Nachrichten unter aktiven Nutzern verteilt. Es kann vorkommen, dass ein einzelner Nutzer weniger Nachrichten als erwartet erhält oder eine andere Teilmenge von Nachrichten als andere Nutzer erhält.
Beachten Sie, dass Nachrichten möglicherweise bereits für Clients ausstehen und ein Rückstand nicht bestätigter Nachrichten nicht unbedingt bedeutet, dass Sie diese Nachrichten bei Ihrer nächsten Pull-Anfrage erhalten. Beachten Sie, dass ein Nutzer möglicherweise jemand ist, der in der Google Cloud Console oder der Google Cloud CLI Pull verwendet oder lokal einen benutzerdefinierten Abonnenten 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 genug Abonnenten erläutert, wird empfohlen, mehrere ausstehende Pull-Anfragen beizubehalten, da einige Anfragen möglicherweise weniger als die maximal konfigurierte Anzahl von Nachrichten oder gar keine Nachrichten zurückgeben.
Wenn Sie eines dieser Verhaltensweisen vermuten, prüfen Sie, ob mehrere Nutzer gleichzeitig mit dem Abo verknüpft sind.
Nach 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 dem Filter entsprechen. Überlegen Sie, wie sich Filter auf Rückstandsmesswerte auswirken.
Mit der Option returnImmediately
Wenn Ihr Client den unären Pull-Modus 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 sie ohne Nachrichten zurückgegeben wird. Dies kann dazu führen, dass Pull-Anfragen mit 0 Nachrichten zurückgegeben werden, selbst wenn es einen Rückstand gibt.
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, wodurch der Eindruck entsteht, dass es sich um Duplikate handelt. Mit dem Messwert subscription/expired_ack_deadlines_count kannst du messen, wie viele Abonnenten die Bestätigungsfrist nicht einhalten. Weitere Informationen zum Überwachen des Ablaufdatums für die Bestätigung
Verlängern Sie die Nachrichtenfristen, um die Duplizierungsrate zu reduzieren.
- Clientbibliotheken erledigen die Fristverlängerung 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 schneller beim Abonnenten 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 überfordert bleibt, schlagen wiederholte Fristverlängerungen irgendwann fehl. Im Worst-Case-Szenario kann dies dazu führen, dass ein Abonnent mit Duplikaten überläuft, was den Rückstand verschlimmert. Wenn Duplikate ablaufen, werden neue Duplikate generiert.
Reduzieren Sie die Anzahl der Nachrichten, die der Abonnent gleichzeitig abruft, um eine Überlastung des Abonnenten zu vermeiden. Auf diese Weise hat der Abonnent weniger Nachrichten, die er innerhalb der Frist verarbeiten muss. Weniger Nachrichten laufen ab und weniger Nachrichten werden erneut 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 Ablaufsteuerungskonfiguration Ihres Abonnenten reduzieren. Es gibt keinen universellen Wert, daher müssen Sie die maximale Anzahl ausstehender Nachrichten entsprechend Ihrem Durchsatz und der Abonnentenkapazität anpassen. Bedenken Sie, dass Nachrichten von jeder Anwendung unterschiedlich verarbeitet und unterschiedlich lange für die Bestätigung benötigt werden.
Wiederholungsversuche erzwingen
Wenn Sie erzwingen möchten, dass Pub/Sub eine Nachricht wiederholt, senden Sie eine nack-Anfrage. Wenn Sie keine der übergeordneten Clientbibliotheken verwenden, senden Sie eine modifyAckDeadline-Anfrage und setzen Sie ackDeadlineSeconds auf 0.
Schlüssel anordnen
Wenn Pub/Sub eine Nachricht mit einem Reihenfolgeschlüssel noch einmal sendet, werden auch alle nachfolgenden Nachrichten mit demselben Sortierungsschlüssel noch einmal zugestellt, selbst wenn sie zuvor bestätigt wurden. Dies geschieht, um die Reihenfolge der Sequenz beizubehalten. Es gibt jedoch keine strenge Garantie, dass abhängige Nachrichten erst nach erfolgreicher Bestätigung vorheriger Nachrichten in der Sequenz gesendet werden.
Abonnent schickt Nachrichten an
Siehe Der Abonnent nimmt die Nachrichten an.
Fehlerbehebung bei einem StreamingPull-Abo
StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Im Gegensatz zu einem Fehlerstatus bei unären RPCs ist dieser Status bei StreamingPull nur ein Hinweis darauf, dass der Stream getrennt ist. Die Anfragen schlagen nicht fehl. Daher kann die StreamingPull API eine überraschende Fehlerrate von 100% haben, dieses Verhalten ist aber so vorgesehen.
Da StreamingPull-Streams immer mit einem Fehler geschlossen werden, ist es nicht hilfreich, die Messwerte zur Beendigung von Streams 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:
Fehler vom Typ Fehler bei der Vorbedingung können auftreten, wenn sich im Aborückstand Nachrichten befinden, die mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind. Stellen Sie den Zugriff auf den Schlüssel wieder her, um den Abruf fortzusetzen.
Fehler „Nicht verfügbar“ können auftreten, wenn Pub/Sub eine Anfrage nicht verarbeiten kann. Dies ist höchstwahrscheinlich ein vorübergehender Zustand. Die Anfragen werden von der Clientbibliothek wiederholt. Wenn Sie eine Clientbibliothek verwenden, müssen Sie nichts weiter tun.
Fehler vom Typ „Nicht gefunden“ können auftreten, wenn das Abo gelöscht wird oder es nie gegeben hat. Der zweite Fall tritt auf, wenn du einen ungültigen Abopfad angegeben hast.