Wiederholungsereignisse

Ein Ereignis kann aus mehreren Gründen abgelehnt werden. So kann der Ereignisempfängerdienst beispielsweise aufgrund eines Ausfalls vorübergehend nicht verfügbar sein, der Dienst bei der Verarbeitung eines Ereignisses auf einen Fehler stoßen oder die Dienstressourcen erschöpft sein. Bei vorübergehenden Fehlern kann es noch einmal versucht werden.

Es kann auch vorkommen, dass ein Ereignis nicht an den Ereignisempfänger gesendet wird. Das Ereignis entspricht beispielsweise möglicherweise nicht dem erwarteten konfigurierten Schema oder die Vermittlung des Ereignisses schlägt fehl, bevor die Ereignisnachricht an ihr endgültiges Ziel weitergeleitet werden kann. In solchen Fällen kommt es zu dauerhaften Fehlern.

Vorübergehende Fehler

Mit Eventarc Advanced können Sie vorübergehende Fehler behandeln. Diese vorübergehenden Fehler können wiederholt werden. Dazu gehören auch Fehler mit den folgenden Fehlercodes:

  • HTTP 408 Request Timeout
  • HTTP 409 Conflict
  • HTTP 429 Too Many Requests
  • HTTP 500 Internal Server Error
  • HTTP 502 Bad Gateway
  • HTTP 503 Service Unavailable
  • HTTP 504 Gateway Time-out

Dauerhafte Fehler

Im Gegensatz zu vorübergehenden Fehlern sind dauerhafte Fehler:

  • Fehler, die auftreten, wenn die Anzahl der konfigurierten Wiederholungen aufgebraucht ist
  • Fehler, die auftreten, wenn ein Ereignis fehlschlägt, bevor es an sein Ziel weitergeleitet werden kann
  • Fehler, die zu einem Fehlercode führen, der nicht wiederholt werden kann, z. B. andere Fehlercodes als die für vorübergehende Fehler aufgeführten

Sie können wiederkehrende Fehler manuell identifizieren und entsprechend behandeln.

Vorübergehende Fehler noch einmal versuchen

Eventarc Advanced verwendet den exponentiellen Backoff mit einer Verzögerung zum Behandeln von Fehlern, für die Wiederholungsversuche möglich sind. Die Standardwiederholrichtlinie beginnt mit einer Verzögerung von einer Sekunde. Nach jedem fehlgeschlagenen Versuch wird die Verzögerung verdoppelt (bis zu einem Maximum von 60 Sekunden und fünf Versuchen).

Sie können die Standardwiederholrichtlinie mit der Google Cloud Console oder dem Befehl gcloud beta eventarc pipelines update ändern.

Der Standard-Backoff-Faktor von 2 kann nicht geändert werden.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Eventarc > Pipelines auf.

    Zu Pipelines

  2. Klicken Sie auf den Namen der Pipeline.

  3. Klicken Sie auf der Seite Pipelinedetails auf Bearbeiten.

  4. Ändern Sie auf der Seite Pipeline bearbeiten im Bereich Wiederholrichtlinie die folgenden Felder:

    • Max. Versuche: Die Anzahl der Wiederholungsversuche. Standardmäßig sind 5 Versuche festgelegt. Kann eine beliebige positive reelle Zahl sein. Wenn dieser Wert auf 1 gesetzt ist, wird keine Wiederholungsrichtlinie angewendet. Es wird nur ein Versuch unternommen, die Nachricht zuzustellen.
    • Minimale Verzögerung (Sekunden): die anfängliche Verzögerung in Sekunden; Standardwert: 1 Sekunde. Muss zwischen 1 und 600 liegen.
    • Max. Verzögerung (Sekunden): Die maximale Verzögerung in Sekunden. Standardmäßig ist 60 Sekunden festgelegt. Muss zwischen 1 und 600 liegen.

    Sie können eine lineare Backoff-Zeit konfigurieren, indem Sie die Mindest- und die maximale Verzögerung auf denselben Wert festlegen.

  5. Klicken Sie auf Speichern.

gcloud 

gcloud beta eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

Ersetzen Sie Folgendes:

  • PIPELINE_NAME: die ID oder voll qualifizierte Kennzeichnung der Pipeline.
  • MIN_DELAY: die anfängliche Verzögerung in Sekunden; Standardwert ist 1 Sekunde. Muss zwischen 1 und 600 liegen.
  • MAX_DELAY: Die maximale Verzögerung in Sekunden. Standardmäßig ist 60 Sekunden festgelegt. Muss zwischen 1 und 600 liegen.
  • MAX_ATTEMPTS: Die Anzahl der Wiederholungen. Standardmäßig sind 5 Versuche festgelegt. Kann eine beliebige positive reelle Zahl sein. Wenn dieser Wert auf 1 gesetzt ist, wird keine Wiederholungsrichtlinie angewendet. Es wird nur ein Versuch unternommen, die Nachricht zuzustellen.

Im folgenden Beispiel wird ein linearer Backoff konfiguriert, indem die Mindest- und Höchstverzögerung auf denselben Wert festgelegt werden:

gcloud beta eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

Nachrichten archivieren, um hartnäckige Fehler zu beheben

Sie können Nachrichten beim Empfang in eine BigQuery-Tabelle schreiben. So können Sie hartnäckige Fehler manuell identifizieren und entsprechend behandeln.

Im Folgenden finden Sie eine Übersicht über die Schritte, die erforderlich sind, um Ihre Ereignismeldungen zu archivieren, hartnäckige Fehler zu identifizieren und die betroffenen Ereignisse noch einmal zu versuchen.

  1. Erstellen Sie einen Bus. Konfigurieren Sie den Bus entsprechend, z. B. um Ereignisse aus Google-Quellen zu veröffentlichen.
  2. Erstellen Sie ein Pub/Sub-Thema. Dieses Pub/Sub-Thema ist das Ziel für Ihre Pipeline.
  3. Erstellen Sie ein BigQuery-Abo für das Pub/Sub-Thema. Ein BigQuery-Abo ist eine Art Exportabo, bei dem Nachrichten beim Empfang in eine vorhandene BigQuery-Tabelle geschrieben werden. Alternativ können Sie die Tabelle auch beim Erstellen des BigQuery-Abos erstellen.

  4. Erstellen Sie eine Pipeline und eine Registrierung, die jede vom Bus empfangene Nachricht (mit --cel-match="true") an das Pub/Sub-Thema weiterleitet. Konfigurieren Sie eine Wiederholungsrichtlinie für die Pipeline.

    Mit den folgenden Befehlen werden beispielsweise eine Pipeline und eine Registrierung erstellt:

    gcloud beta eventarc pipelines create my-archive-pipeline \
    --destinations=pubsub_topic='my-archive-topic',network_attachment='my-network-attachment' \
    --min-retry-delay=1 \
    --max-retry-delay=20 \
    --max-retry-attempts=6 \
    --location=us-central1

    gcloud beta eventarc enrollments create my-archive-enrollment \
    --cel-match="true" \
    --destination-pipeline=my-archive-pipeline \
    --message-bus=my-message-bus \
    --message-bus-project=my-google-cloud-project \
    --location=us-central1

  5. Leiten Sie Ihre Pipeline-Logs an ein anderes BigQuery-Dataset weiter.

    Sie sollten jetzt zwei separate BigQuery-Datasets haben: eines, in dem jede Nachricht gespeichert wird, die von Ihrem Eventarc Advanced-Bus empfangen wird, und eines, in dem Ihre Pipelineprotokolle gespeichert werden.

  6. Um fehlgeschlagene Nachrichten zu identifizieren, können Sie mit einer Abfrageanweisung beide BigQuery-Datasets am Feld message_uid zusammenführen.

  7. Nachdem Sie fehlgeschlagene Nachrichten identifiziert haben, können Sie sie mit der Eventarc Publishing API noch einmal auf Ihrem Bus veröffentlichen. Sie können beispielsweise einen Cloud Run-Dienst oder -Job bereitstellen, um die Nachrichten aus BigQuery zu lesen und direkt im Eventarc Advanced-Bus zu veröffentlichen.

Event-Handler idempotent machen

Event-Handler, für die Wiederholungsversuche gemacht werden können, sollten gemäß den folgenden allgemeinen Richtlinien idempotent sein:

  • Bei vielen externen APIs können Sie einen Idempotenzschlüssel als Parameter bereitstellen. Wenn Sie eine solche API verwenden, sollten Sie die Ereignisquelle und ‑ID als Idempotenzschlüssel verwenden. (Produzenten müssen dafür sorgen, dass source + id für jedes einzelne Ereignis eindeutig ist.)
  • Außerdem können Sie das CloudEvents-Attribut xgooglemessageuid verwenden, um für Idempotency zu sorgen. Der Wert dieses Attributs entspricht dem Feld message_uid in erweiterten Eventarc-Nachrichten. Er identifiziert die Veröffentlichung eines Ereignisses eindeutig. Wenn beispielsweise dasselbe Ereignis zweimal auf einem Bus veröffentlicht wird, hat jedes Ereignis einen anderen xgooglemessageuid-Wert, wenn es an einen Ereignishandler gesendet wird.
  • Idempotenz funktioniert gut bei mindestens einmaliger Übermittlung, weil Wiederholungsversuche dadurch problemlos erfolgen können. Eine allgemeine Best Practice für das Schreiben von zuverlässigem Code ist also, Idempotenz mit Wiederholungsversuchen zu kombinieren.
  • Achten Sie darauf, dass der Code intern idempotent ist. Beispiele:
    • Sorgen Sie dafür, dass Mutationen mehr als einmal passieren können, ohne das Ergebnis zu verändern.
    • Fragen Sie den Datenbankstatus in einer Transaktion ab, bevor der Status mutiert wird.
    • Stellen Sie sicher, dass alle Nebenwirkungen selbst idempotent sind.
  • Erzwingen Sie eine Transaktionsprüfung außerhalb des Dienstes und unabhängig vom Code. Beispiel: Zustand an einem Punkt persistent machen, um aufzuzeichnen, dass eine bestimmte Ereignis-ID bereits verarbeitet wurde.
  • Nutzen Sie ein Verfahren für doppelte Aufrufe "out of band". Verwenden Sie beispielsweise einen separaten Bereinigungsprozess, der nach doppelten Aufrufen eine Bereinigung durchführt.

Nächste Schritte