Wiederholungsereignisse

Ein Ereignis kann aus verschiedenen Gründen abgelehnt werden. Der Dienst für den Empfang von Ereignissen ist beispielsweise aufgrund eines Ausfalls möglicherweise vorübergehend nicht verfügbar, beim Verarbeiten eines Ereignisses kann ein Fehler auftreten oder die Dienstressourcen können erschöpft sein. Bei vorübergehenden Fehlern wie diesem kann es sich lohnen, es noch einmal zu versuchen.

Ein Ereignis kann auch nicht an den Ereignisempfänger gesendet werden. Das Ereignis entspricht beispielsweise nicht dem 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 treten persistente Fehler auf.

Vorübergehende Fehler

Mit Eventarc Advanced können Sie vorübergehende Fehler behandeln. Diese vorübergehenden Fehler können wiederholt werden und umfassen 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

Permanente Fehler

Im Gegensatz zu vorübergehenden Fehlern umfassen persistente Fehler Folgendes:

• Fehler, die auftreten, wenn die Anzahl der konfigurierten Wiederholungen erschöpft 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 als nicht wiederholbar gilt, z. B. Fehlercodes, die nicht für vorübergehende Fehler aufgeführt sind

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

Vorübergehende Fehler wiederholen

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

Sie können die Standardrichtlinie für Wiederholungsversuche über die Google Cloud -Konsole oder den Befehl gcloud beta eventarc pipelines update ändern.

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

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

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

Nachrichten archivieren, um dauerhafte Fehler zu beheben

Sie können Nachrichten beim Empfang in eine BigQuery-Tabelle schreiben. So können Sie dauerhafte Fehler manuell identifizieren und entsprechend reagieren.

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

1. Bus erstellen Konfigurieren Sie den Bus entsprechend, z. B. um Ereignisse aus Google-Quellen zu veröffentlichen.
2. Pub/Sub-Thema erstellen 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, das Nachrichten beim Empfang in eine vorhandene BigQuery-Tabelle schreibt. Alternativ können Sie die Tabelle beim Erstellen des BigQuery-Abos erstellen.

4. Erstellen Sie eine Pipeline und Registrierung, die jede Nachricht, die vom Bus empfangen wird (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 alle Nachrichten gespeichert werden, die von Ihrem Eventarc Advanced-Bus empfangen werden, und eines, in dem Ihre Pipeline-Logs gespeichert werden.

6. Um fehlgeschlagene Nachrichten zu ermitteln, verwenden Sie eine Abfrageanweisung zum Verknüpfen beider BigQuery-Datasets über das Feld message_uid.

7. Nachdem Sie fehlgeschlagene Nachrichten identifiziert haben, können Sie sie mit der Eventarc Publishing API noch einmal in 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 Idempotenz zu erreichen. Der Wert dieses Attributs entspricht dem Feld message_uid in Eventarc Advanced-Nachrichten. Sie kennzeichnet die Aktion zum Veröffentlichen eines Ereignisses eindeutig. Wenn beispielsweise dasselbe Ereignis zweimal in 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

• Fehlerbehebung
• Audit-Logs ansehen