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.

Damit Sie Ihr Pub/Sub-Abo effektiv überwachen können, sollten Sie sich zuerst die Integritätsbewertung für die Bereitstellungslatenz (subscription/delivery_latency_health_score) ansehen, um zu ermitteln, 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.

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 ermitteln, in welchen Situationen Nutzer zurückbleiben. 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 bei 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. Konzentrieren Sie sich in dieser Situation auf die Abonnentenkomponenten:

  • Clientstatus: Analysieren Sie die Ressourcenauslastung auf Maschinen, auf denen Abonnentenclients gehostet werden, z. B. CPU, Arbeitsspeicher und Netzwerkbandbreite. Achten Sie auf Druckpunkte, 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.

  • 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.

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.

Beachten Sie, dass durch das Entpacken einer Nachricht nicht garantiert wird, dass beim nächsten Abruf eine andere Nachricht abgerufen wird. Die Pub/Sub-Richtlinie für die erneute Zustellung sendet möglicherweise weiterhin leere Nachrichten vor neuen Nachrichten. Verlassen Sie sich daher zum Filtern oder Überspringen bestimmter Nachrichten nicht auf Nacks. Legen Sie stattdessen eine Richtlinie für Wiederholungsversuche fest, vorzugsweise einen exponentiellen Backoff, um einzelne Nachrichten zurückzustellen, die wahrscheinlich später verarbeitet werden können, aber etwas länger dauern, bevor sie noch einmal gesendet werden.

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 unbestätigt bleiben, ob absichtlich oder nicht, führt dies zu Backlog-Problemen und doppelten Übermittlungen.

Hohe Bereitstellungslatenz

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 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. So können Sie sicherstellen, dass Sie immer genügend Streams für die Verarbeitung eingehender Nachrichten haben.

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. Seltene Anfragen könnten sich potenziell Nachrichten im Rückstand ansammeln und die Latenz erhöhen. So lassen sich Verbindungslücken minimieren und die Übermittlungslatenz 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 für die Minimierung der Latenz in der Regel besser geeignet ist. 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 Backlog

Ein Nachrichtenrückstand von unbestätigten Nachrichten in einem Pub/Sub-Abo erhöht grundsätzlich die End-to-End-Latenz, da Nachrichten von Abonnenten nicht sofort verarbeitet werden.

Schlüssel bestellen und genau einmalige Zustellung

Das Bestellen von Schlüsseln und die genau einmalige Zustellung sind wertvolle Funktionen. Sie erfordern jedoch eine zusätzliche Koordination in Pub/Sub, um eine korrekte Zustellung sicherzustellen. 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 Nachrichtensortierung oder die Zustellung genau einmal für Ihre Anwendung unbedingt erforderlich sind. Wenn eine geringe Latenz für Sie an erster Stelle steht, können Sie Verzögerungen bei der Nachrichtenverarbeitung reduzieren, indem Sie die Verwendung dieser Funktionen minimieren.

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 die Zustellungslatenz ansteigt, können Sie die Nachrichtengrößen mithilfe des Messwerts topic/message_sizes überprüfen, indem Sie nach topic_id gruppieren. Korrelieren Sie etwaige Spitzen bei der Nachrichtengröße 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 die 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 eine Person ist, die in der Google Cloud Console oder der Google Cloud CLI Pull verwendet 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 Sie eines dieser Verhaltensweisen vermuten, untersuchen Sie, ob mehrere Nutzer gleichzeitig mit dem Abo verknüpft sind, und prüfen Sie sie.

Nach Abo filtern

Prüfen Sie, ob das Abo einen Filter hat. In diesem Fall erhalten Sie nur die Nachrichten, die dem Filter entsprechen. Der Pub/Sub-Dienst bestätigt Nachrichten, die nicht mit dem Filter übereinstimmen, automatisch. Überlegen Sie, wie sich Filter auf Backlog-Messwerte 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 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. Dadurch werden die Nachrichten noch einmal gesendet, was den Anschein von Duplikaten erweckt. Mit dem Messwert subscription/expired_ack_deadlines_count können Sie messen, wie oft 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 verarbeiten 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, 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 für die Bestätigung einer Nachricht unterschiedlich lange Zeit in Anspruch nimmt.

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.

Schlüssel anordnen

Wenn Pub/Sub eine Nachricht mit einem Bestellschlüssel haben, werden alle nachfolgenden Nachrichten mit demselben Reihenfolgeschlüssel, 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 StreamingPull-Abos

Beziehung zwischen dem Messwert für die Anfragelatenz und der End-to-End-Zustellungslatenz

Bei StreamingPull entspricht der Messwert serviceruntime.googleapis.com/api/request_latencies der Zeit, für die 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. Gefällt mir nicht mehr für Fehlerstatus Bei unären RPCs ist dieser Status für StreamingPull nur ein Hinweis darauf, dass der Stream ist nicht verbunden. Die Anfragen schlagen nicht fehl. Das heißt, während der Die StreamingPull API kann eine Fehlerrate von unerwarteten 100% aufweisen. Dieses Verhalten Design.

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 „StreamingPull-Antwort“ subscription/streaming_pull_response_count, gruppiert nach response_code oder response_class.

Suchen Sie nach diesen Fehlern:

  • Fehlgeschlagene Vorbedingungen-Fehler können auftreten, wenn sich Nachrichten in der Aborückstand, 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 nicht einen Antrag zu verarbeiten. 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.