Fehlerbehebung bei Pull-Abos

Dieses Dokument enthält 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.

Das Alter der ältesten unbestätigten Nachricht nimmt ständig zu

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 (bestätigt) wurde. Dieser Messwert bietet wertvolle Informationen zu möglichen Verzögerungen oder Engpässen bei der Verarbeitung.

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 die Messwerte oldest_unacked_message_age und num_undelivered_messages gleichzeitig zunehmen, kann dies bedeuten, dass die Abonnenten nicht mit dem Nachrichtenvolumen Schritt halten. Konzentrieren Sie sich in dieser Situation auf die Abonnentenkomponenten:

  • Clientzustand: 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 Zustellungslatenz in Pub/Sub ist die Zeit, die eine Nachricht von einem Publisher benötigt, um einen Abonnenten zu erreichen. 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 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 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. Dieser Ansatz trägt dazu bei, Verbindungslücken zu minimieren und die Bereitstellungslatenz 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 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 Rückstand

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. Während der Unterschied im stabilen Zustand minimal ist, können notwendige Koordinationsschritte zu einer vorübergehenden Erhöhung der Latenz oder einer höheren 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 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 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 Nachrichten aus Effizienzgründen auf aktive Nutzer 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 einige Anfragen weniger als die maximal konfigurierte Anzahl von Nachrichten oder sogar null Nachrichten zurückgeben können.

Wenn Sie eines dieser Verhaltensweisen vermuten, untersuchen Sie, ob mehrere Nutzer gleichzeitig mit dem Abo verknüpft sind, und prüfen Sie diese.

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. 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 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. Auf diese Weise muss der Abonnent weniger Nachrichten innerhalb der Frist 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 universellen Wert. Daher müssen Sie das Limit für die maximale Anzahl ausstehender Nachrichten basierend auf Ihrem Durchsatz und Ihrer Abonnentenkapazität 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 Sortierschlüssel noch einmal sendet, werden auch alle nachfolgenden Nachrichten mit demselben Reihenfolgeschlüssel noch einmal zugestellt, selbst wenn sie zuvor bestätigt wurden. Dies geschieht, um die Reihenfolge der Sequenz beizubehalten. Es gibt jedoch keine strikte Garantie, dass abhängige Nachrichten erst nach der erfolgreichen Bestätigung vorheriger Nachrichten in der Sequenz gesendet werden.

Abonnent schließt die Nachrichten

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

Fehlerbehebung bei StreamingPull-Abos

StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Im Gegensatz zu einem Fehlerstatus bei unären RPCs ist dieser Status für StreamingPull nur ein Hinweis darauf, dass der Stream getrennt ist. Die Anfragen schlagen nicht fehl. Obwohl die StreamingPull API eine Fehlerrate von überraschend 100% aufweisen kann, ist dieses Verhalten beabsichtigt.

Da StreamingPull-Streams immer mit einem Fehler geschlossen werden, ist es nicht hilfreich, die Messwerte für die 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:

  • Fehlgeschlagene Vorbedingungen können auftreten, wenn Nachrichten im Aborückstand mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind. Stellen Sie den Zugriff auf den Schlüssel wieder her, um den Abruf fortzusetzen.

  • Nicht verfügbare Fehler 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 wird oder es nie existiert hat. Letzteres passiert, wenn du einen ungültigen Abopfad angegeben hast.