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
oldest_unacked_message_age ist ein wichtiger Messwert für die Überwachung der Systemintegrität 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 und mögliche Probleme im Zusammenhang mit einer beeinträchtigten Leistung beheben.
Zu den häufigen Problemen mit dem Backlog, 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 dem Nachrichtenvolumen 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: Prüfe die letzten Codeänderungen und sieh dir die Fehlerprotokolle an. Fehler oder Ineffizienzen im Abonnentencode können sich erheblich auf die Verarbeitungsraten von Nachrichten auswirken. Beachten Sie, dass es bei bestimmten Nachrichten zu Problemen kommen 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.
Der Abonnent hat die Nachrichten negativ bestätigt.
Wenn ein Abonnent eine Nachricht negativ bestätigt (Nack), signalisiert er Pub/Sub, dass die Nachricht nicht erfolgreich verarbeitet werden konnte. Pub/Sub versucht dann, dieselbe Nachricht noch einmal zu senden. Wiederholte NAK-Antworten für eine Nachricht führen zu Duplikaten und möglicherweise zu einer großen Verzögerung bei der Nachrichtenübermittlung.
Wenn eine Nachricht abgelehnt wird, ist nicht garantiert, dass beim nächsten Pull eine andere Nachricht abgerufen wird. Gemäß der Pub/Sub-Richtlinie für die erneute Zustellung werden möglicherweise weiterhin nackte Nachrichten vor neuen Nachrichten zugestellt. 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öchten, sollten Sie sie 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. In den folgenden Abschnitten werden einige mögliche Ursachen für eine hohe Übermittlungslatenz beschrieben.
Nicht genügend Abonnenten
Bei Clients, die StreamingPull verwenden, solltest du mehrere offene StreamingPull-Verbindungen zu deinem Abo aufrechterhalten, um eine konstant niedrige Latenz zu erreichen. Ohne aktive Abonnentenverbindungen kann Pub/Sub Nachrichten nicht zeitnah 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 gibt Aufschluss über die Anzahl der aktiven Streamingverbindungen. So sorgen Sie dafür, dass immer genügend Streams vorhanden sind, um eingehende Nachrichten zu verarbeiten.
Bei Clients, die unary pull verwenden, sollten Sie mehrere ausstehende Pull-Anfragen an Ihr Abo senden, um eine gleichbleibend 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 Clientbibliothek der höheren Ebene die StreamingPull API, da sie in der Regel die bessere Wahl ist, um die Latenz zu minimieren. 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 mit der Clientkonfiguration
Weitere Informationen finden Sie unter Probleme mit der Clientkonfiguration.
Hoher Backlog
Beachten Sie, dass ein Nachrichtenrückstand 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.
Sortierschlüssel und genau einmal zugestellt
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 Reihenfolgeschlüssel erst dann 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öße der Nachrichten erhöht
Ein plötzlicher Anstieg der Nachrichtengröße kann die Übertragungszeit zwischen Pub/Sub und Ihrem Client verlängern 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. Stellen Sie einen Zusammenhang zwischen Spitzen bei der Nachrichtengröße und beobachteten Leistungsproblemen her.
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 Abnehmern
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 in der Google Cloud Console oder in der Google Cloud CLI Pull-Vorgänge ausführt oder einen benutzerdefinierten Abonnenten lokal ausführt, um Nachrichten zu prüfen.
Bei unary Pull-Clients kann es vorkommen, dass bei einigen Pull-Anfragen keine Nachrichten zurückgegeben werden. Wie im Abschnitt Nicht genügend Abonnenten erläutert, wird empfohlen, mehrere ausstehende Pull-Anfragen zu haben, da einige Anfragen möglicherweise weniger als die konfigurierte maximale Anzahl von Nachrichten oder sogar keine Nachrichten zurückgeben.
Wenn du den Verdacht hast, dass eines dieser Verhaltensweisen vorliegt, solltest du prüfen, ob dem Abo mehrere Nutzer gleichzeitig zugewiesen sind.
Nach 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?
Option returnImmediately verwenden
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. Das kann dazu führen, dass Pull-Requests mit 0 Nachrichten zurückgegeben werden, auch wenn es einen Rückstau 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 gesendet, was den Anschein von Duplikaten erweckt. 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 des Fristlimits für die Bestätigung
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, verwenden Sie die Methode
modifyAckDeadline, um die Bestätigungsfrist zu verlängern.
Wenn Nachrichten schneller im Abonnenten abgerufen werden, als sie verarbeitet und bestätigt werden können, laufen einige Nachrichten möglicherweise ab und es sind Fristverlängerungen erforderlich. Wenn der Abonnent jedoch weiterhin überfordert ist, schlagen wiederholte Fristverlängerungen irgendwann fehl. Im schlimmsten Fall kann das dazu führen, dass ein Abonnent mit Duplikaten überflutet wird, was den Rückstau verschärft. Auslaufende Duplikate generieren dann neue Duplikate.
Reduzieren Sie die Anzahl der Nachrichten, die der Abonnent gleichzeitig abrufen kann, um eine Überlastung zu vermeiden. So muss der Abonnent innerhalb der Frist weniger Nachrichten verarbeiten. Weniger Nachrichten laufen ab und weniger Nachrichten werden noch einmal 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 des Abonnenten verringern. 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
Wenn Sie Pub/Sub dazu zwingen möchten, eine Nachricht noch einmal zu senden, senden Sie eine nack-Anfrage. Wenn Sie die Clientbibliotheken der höheren Ebene nicht verwenden, senden Sie eine modifyAckDeadline-Anfrage mit einer ackDeadlineSeconds, die 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. So bleibt die Reihenfolge der Sequenz erhalten. Es gibt jedoch keine Garantie dafür, dass abhängige Nachrichten erst nach der erfolgreichen Bestätigung der vorherigen Nachrichten in der Sequenz gesendet werden.
Der Abonnent nackt die Nachrichten
Weitere Informationen finden Sie unter Abonnent nackt die Nachrichten.
Fehlerbehebung bei einem StreamingPull-Abo
Beziehung zwischen dem Messwert „Anfragelatenz“ und der End-to-End-Übermittlungslatenz
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-Übermittlungslatenz zu bestimmen.
Verwenden Sie anstelle des Messwerts „Anfragelatenz“ den Status der Zustellungslatenz, um zu prüfen, welche Faktoren zu einer erhöhten End-to-End-Zustellungslatenz 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 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 Messwert „StreamingPull-Antwort“ subscription/streaming_pull_response_count, gruppiert nach response_code oder response_class.
Achten Sie auf folgende Fehler:
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. Wenn Sie das Abrufen fortsetzen möchten, stellen Sie den Zugriff auf den Schlüssel wieder her.
Nicht verfügbare Fehler können auftreten, wenn Pub/Sub eine Anfrage nicht verarbeiten kann. Dies ist höchstwahrscheinlich nur ein vorübergehender Zustand und die Clientbibliothek 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 wurde oder nie existiert hat. Letzteres ist der Fall, wenn du einen ungültigen Abopfad angegeben hast.