Fehlerbehebung bei Pull-Abos

In diesem Dokument finden Sie einige allgemeine Tipps zur Fehlerbehebung bei Pub/Sub-Pull-Abos. Weitere Informationen zu Pull-Abos finden Sie im Pull-Abonnentenleitfaden.

Wenn Sie Ihr Pub/Sub-Abo effektiv überwachen möchten, sollten Sie zuerst den Status der Zustellungslatenz (subscription/delivery_latency_health_score) prüfen, um zu sehen, welche Faktoren zu einer unerwarteten oder erhöhten Latenz beitragen können.

Alter der ältesten unbestätigten Nachricht steigt immer weiter

Der 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 Rückstand eines Abos in Sekunden, die noch nicht von einem Abonnenten bestätigt wurde. Dieser Messwert bietet wertvolle Informationen zu potenziellen Verarbeitungsverzögerungen oder Engpässen.

Durch das Überwachen 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 Nutzer in Verzug geraten. So können Sie frühzeitig eingreifen, um potenzielle Probleme im Zusammenhang mit Leistungseinbußen zu beheben.

Zu den häufigen Backlog-Problemen, die Sie untersuchen können, gehören:

Probleme mit der Clientkonfiguration

Wenn sich sowohl der Messwert oldest_unacked_message_age als auch num_undelivered_messages gleichzeitig erhöhen, kann das bedeuten, dass die Abonnenten mit der Nachrichtenmenge nicht Schritt halten. Konzentriere dich in diesem Fall auf die Komponenten für Abonnenten:

  • Clientstatus: Analysiere die Ressourcennutzung auf Computern, auf denen Abonnenten-Clients 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 die Fehlerlogs. Fehler oder Ineffizienzen im Abonnentencode können die Verarbeitungsraten von Nachrichten 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.

  • Kontingenteinschränkungen: Prüfen Sie, ob Sie keine Pub/Sub-Kontingente oder Einschrä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.

Abonnent hat die Nachrichten negativ bestätigt

Wenn ein Abonnent eine Nachricht negativ bestätigt (nacks), signalisiert dies Pub/Sub, dass die Nachricht nicht erfolgreich verarbeitet werden konnte. Pub/Sub versucht dann, dieselbe Nachricht noch einmal zu senden. Das wiederholte Schließen einer Nachricht kann zu Duplikaten und möglicherweise zu einer langen Verzögerung bei der Nachrichtenzustellung führen.

Wenn eine Nachricht abgelehnt wird, ist nicht garantiert, dass beim nächsten Pull eine andere Nachricht abgerufen wird. Die Pub/Sub-Richtlinie für die erneute Zustellung sendet möglicherweise weiterhin leere Nachrichten vor neuen Nachrichten. Verwende daher keine NACKs, um bestimmte Nachrichten zu filtern oder zu überspringen. Legen Sie stattdessen eine Wiederholungsrichtlinie fest, vorzugsweise ein exponentielles Backoff, um einzelne Nachrichten zu verwerfen, die wahrscheinlich später verarbeitet werden können, aber etwas mehr Zeit für die erneute Zustellung benötigen.

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 Übermittlungen werden vermieden und der Ressourcenverbrauch wird reduziert. Wenn Nachrichten nicht bestätigt werden, ob absichtlich oder nicht, führt dies zu Rückstaus und doppelten Zustellungen.

Hohe Übermittlungslatenz

Die Übermittlungslatenz in Pub/Sub ist die Zeit, die vergeht, bis eine Nachricht von einem Publisher einen Abonnenten erreicht. Einige mögliche Ursachen für eine hohe Bereitstellungslatenz werden in den nächsten Abschnitten beschrieben.

Nicht genügend Abonnenten

Pflegen Sie für Clients, die StreamingPull verwenden, mehrere offene StreamingPull-Verbindungen zu Ihrem Abo, 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 bietet einen Einblick in die Anzahl der aktiven Streamingverbindungen. So sorgen Sie dafür, dass Sie immer genügend Streams haben, um eingehende Nachrichten zu verarbeiten.

Verwalten Sie für Clients, die unäre Pull-Anfragen verwenden, mehrere ausstehende Pull-Anfragen an Ihr Abo, um eine konstant niedrige Latenz zu erreichen. Bei seltenen Anfragen können sich Nachrichten im Backlog ansammeln und die Latenz erhöhen. So lassen sich Verbindungslücken minimieren und die Übermittlungslatenz verbessern.

Die Clientbibliothek der höheren Ebene wird empfohlen, wenn Sie einen hohen Durchsatz und eine niedrige Latenz bei minimalem Betriebsaufwand und Verarbeitungskosten benötigen. Standardmäßig verwendet die übergeordnete Clientbibliothek die StreamingPull API, da sie für die Minimierung der Latenz in der Regel besser geeignet ist. Die Clientbibliotheken der höheren Ebene 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 Backlog

Beachten Sie, dass ein Nachrichtenstau aus nicht bestätigten Nachrichten in einem Pub/Sub-Abo die Ende-zu-Ende-Latenz grundsätzlich erhöht, da Nachrichten nicht sofort von Abonnenten verarbeitet werden.

Bestellschlüssel und genau einmalige Zustellung

Reihenfolgeschlüssel und die genau einmalige Zustellung sind wertvolle Funktionen, erfordern jedoch eine 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. Im Steady State ist der Unterschied zwar minimal, aber alle erforderlichen Koordinationsschritte können zu vorübergehenden Latenzsteigerungen oder einer erhöhten Fehlerrate führen. Wenn die Sortierung aktiviert ist, können Nachrichten mit einem Bestellschlü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 absolut notwendig ist. Wenn niedrige Latenz für Sie oberste Priorität hat, können Sie die Nutzung dieser Funktionen minimieren, um Verzögerungen bei der Nachrichtenverarbeitung zu reduzieren.

Größere Nachricht

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 Zustellungslatenz feststellen, können Sie die Nachrichtengröße mit dem Messwert topic/message_sizes prüfen und nach topic_id gruppieren. Korrelieren Sie etwaige Spitzen bei der Größe der Nachricht mit beobachteten Leistungsproblemen.

Fehlende Nachrichten

Wenn Sie vermuten, dass Nachrichten nicht an Ihre Abonnenten zugestellt werden, kann einer der folgenden Gründe der Grund dafür sein.

Nachrichtenverteilung in Pub/Sub-Abos mit mehreren Nutzern

Bei Pub/Sub werden Nachrichten möglicherweise ungleichmäßig auf die Abnehmer verteilt. Dieses Verhalten tritt auf, weil Pub/Sub Nachrichten aus Effizienzgründen auf aktive Abnehmer verteilt. Manchmal erhält ein einzelner Nutzer weniger Nachrichten als erwartet oder eine andere Teilmenge von Nachrichten als andere Nutzer.

Beachten Sie, dass Nachrichten für Kunden möglicherweise bereits ausstehend sind. Ein Rückstau von nicht bestätigten Nachrichten bedeutet nicht unbedingt, dass Sie diese Nachrichten bei Ihrem nächsten Pull-Request erhalten. Ein Verbraucher kann jemand sein, der Pull-Vorgänge in der Google Cloud Console oder der Google Cloud CLI ausführt oder einen benutzerdefinierten Abonnenten lokal ausführt, um Nachrichten zu prüfen.

Bei unären Pull-Clients kann es sein, dass einige Pull-Anfragen keine Nachrichten zurückgeben. Wie im Abschnitt Nicht genügend Abonnenten beschrieben, empfiehlt es sich, mehrere ausstehende Pull-Anfragen beizubehalten, da bei einigen Anfragen möglicherweise weniger als die maximal konfigurierte Anzahl von Nachrichten oder sogar null Nachrichten zurückgegeben werden.

Wenn du den Verdacht hast, dass eines dieser Verhaltensweisen vorliegt, solltest du prüfen, ob dem Abo mehrere Nutzer gleichzeitig zugeordnet sind.

Abo filtern

Prüfen Sie, ob dem Abo ein Filter zugewiesen 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. Welche Auswirkungen haben Filter auf Backlog-Messwerte?

Mit der Option returnImmediately

Wenn Ihr Kunde unary Pull verwendet, prüfen Sie, ob das Feld returnImmediately auf „wahr“ gesetzt ist. Dieses nicht mehr unterstützte Feld weist den Pub/Sub-Dienst an, sofort auf den Pull-Vorgang 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 es einen Rückstand gibt.

Umgang mit Duplikaten

In Pub/Sub treten Nachrichtenduplikate 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 erzeugt. Mit dem Messwert subscription/expired_ack_deadlines_count können Sie die Rate messen, bei der Abonnenten die Bestätigungsfrist verpassen. Weitere Informationen zum Überwachen des Ablaufs der Bestätigungsfrist

Verlängern Sie die Nachrichtenfristen, um die Duplizierungsrate zu reduzieren.

  • 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 modifyAckDeadline verlängern.

Wenn Nachrichten beim Abonnenten schneller abgerufen werden, als sie verarbeitet und bestätigt werden können, laufen einige Nachrichten möglicherweise ab und erfordern eine Fristverlängerung. Bleibt der Abonnent jedoch überlastet, schlagen wiederholte Fristverlängerungen fehl. Im schlimmsten Fall kann dies dazu führen, dass Abonnenten mit Duplikaten überlaufen, was den Rückstand verschlimmert. Ablaufende Duplikate generieren dann neue Duplikate.

Reduziere die Anzahl der Nachrichten, die der Abonnent gleichzeitig abruft, um eine Überlastung des Abonnenten zu vermeiden. So hat der Abonnent weniger Nachrichten innerhalb der Frist zu verarbeiten. Weniger Nachrichten laufen ab und weniger Nachrichten werden neu 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 Ihres Abonnenten reduzieren. Es gibt keinen Wert, der für alle passt. Sie müssen das Limit für ausstehende Nachrichten an Ihren Durchsatz und die Kapazität der Abonnenten anpassen. Beachten Sie, dass jede Anwendung Nachrichten unterschiedlich verarbeitet und die Bestätigung einer Nachricht unterschiedlich lange dauert.

Wiederholungsversuche erzwingen

Senden Sie eine nack-Anfrage, um Pub/Sub dazu zu zwingen, eine Nachricht noch einmal zu senden. Wenn Sie nicht die übergeordneten Clientbibliotheken verwenden, senden Sie eine modifyAckDeadline-Anfrage, wobei ackDeadlineSeconds auf 0 gesetzt ist.

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. Dies geschieht, um die Reihenfolge der Sequenz beizubehalten. Es gibt jedoch keine strenge dass abhängige Nachrichten erst nach der erfolgreichen der Bestätigung vorheriger Nachrichten in der Sequenz.

Abonnent schließt die Nachrichten

Weitere Informationen finden Sie unter Abonnent schließt die Nachrichten ab.

Fehlerbehebung bei einem StreamingPull-Abo

Beziehung zwischen dem Messwert „Anfragelatenz“ und der End-to-End-Übermittlungslatenz

Bei StreamingPull steht der Messwert serviceruntime.googleapis.com/api/request_latencies für die Zeit, während der der Stream geöffnet ist. Der Messwert ist nicht hilfreich, um die End-to-End-Bereitstellungslatenz zu bestimmen.

Anstatt den Messwert für die Anfragelatenz zu verwenden, können Sie anhand der Systemdiagnose für die Bereitstellungslatenz ermitteln, welche Faktoren zu einer erhöhten End-to-End-Bereitstellungslatenz beitragen.

StreamingPull-Verbindungen werden mit einem Nicht-OK-Status geschlossen

StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Im Gegensatz zu einem Fehlerstatus für unary RPCs ist dieser Status für StreamingPull nur ein Hinweis darauf, dass die Verbindung zum Stream getrennt wurde. Die Anfragen schlagen nicht fehl. Während das Die StreamingPull API kann eine Fehlerrate von unerwarteten 100% aufweisen. Dieses Verhalten Design.

Da StreamingPull-Streams immer mit einem Fehler geschlossen werden, ist es nicht hilfreich, die Messwerte für das Beenden von Streams untersuchen und dabei Fehler diagnostizieren. Konzentrieren Sie sich stattdessen auf den Messwert „StreamingPull-Antwort“ subscription/streaming_pull_response_count, gruppiert nach response_code oder response_class.

Suchen Sie nach diesen Fehlern:

  • Fehler vom Typ Vorbedingung fehlgeschlagen können auftreten, wenn sich im Abobacklog Nachrichten befinden, die mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind. Bis den Abruf fortsetzen, den Zugriff auf den Schlüssel wiederherstellen.

  • Nicht verfügbare Fehler können auftreten, wenn Pub/Sub eine Anfrage nicht verarbeiten kann. Dies ist höchstwahrscheinlich ein vorübergehender Zustand und der Client wiederholt die Anfragen. Wenn Sie eine Clientbibliothek verwenden, sind keine Maßnahmen Ihrerseits erforderlich.

  • Fehler vom Typ „Nicht gefunden“ können auftreten, wenn das Abo gelöscht wird oder es nie überhaupt existiert hat. Letzteres ist der Fall, wenn du einen ungültigen Abopfad angegeben hast.