Wiederholungsereignisse

Ein Ereignis kann aus mehreren Gründen abgelehnt werden. Beispielsweise ist der Dienst des Ereignisempfängers aufgrund eines Ausfalls möglicherweise vorübergehend nicht verfügbar, beim Verarbeiten eines Ereignisses kann ein Fehler auftreten oder die Ressourcen des Dienstes können erschöpft sein. Bei solchen vorübergehenden Fehlern können Wiederholungsversuche unternommen werden.

Ein Ereignis kann auch nicht an den Ereignisempfänger zugestellt werden. Beispielsweise entspricht das Ereignis möglicherweise nicht dem konfigurierten erwarteten 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 dauerhafte Fehler auf.

Vorübergehende Fehler

Eventarc Advanced bietet Ihnen die Möglichkeit, vorübergehende Fehler zu beheben. Bei diesen vorübergehenden Fehlern können Wiederholungsversuche unternommen werden. Dazu gehören 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 umfassen dauerhafte Fehler Folgendes:

  • Fehler, die auftreten, wenn die Anzahl der konfigurierten Wiederholungsversuche 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 dauerhafte Fehler manuell identifizieren und entsprechend beheben.

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 maximal 60 Sekunden und fünf Versuchen).

Sie können die Standardrichtlinie für Wiederholungsversuche über die Google Cloud Console oder den gcloud eventarc pipelines update Befehl ä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 Pipelinendetails auf Bearbeiten.

  4. Ändern Sie auf der Seite Pipeline bearbeiten im Bereich Richtlinie für Wiederholungsversuche die folgenden Felder:

    • Maximale Anzahl von Versuchen: Die Anzahl der Zustellungsversuche. Der Standardwert ist 5 Versuche. Kann eine beliebige positive Ganzzahl sein. Wenn dieser Wert auf 1 festgelegt ist, wird keine Richtlinie für Wiederholungsversuche angewendet. Es wird nur ein Versuch unternommen, eine Nachricht zuzustellen.
    • Minimale Verzögerung (Sekunden): Die anfängliche Verzögerung in Sekunden. Der Standardwert ist 1 Sekunde. Muss zwischen 1 und 600 liegen.
    • Maximale Verzögerung (Sekunden): Die maximale Verzögerung in Sekunden. Der Standardwert ist 60 Sekunden. Muss zwischen 1 und 600 liegen.

    Sie können einen linearen Backoff konfigurieren, indem Sie die minimale und maximale Verzögerung auf denselben Wert festlegen.

  5. Klicken Sie auf Speichern.

gcloud 

gcloud 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. Der Standardwert ist 1 Sekunde. Muss zwischen 1 und 600 liegen.
  • MAX_DELAY: die maximale Verzögerung in Sekunden. Der Standardwert ist 60 Sekunden. Muss zwischen 1 und 600 liegen.
  • MAX_ATTEMPTS: die Anzahl der Zustellungsversuche. Der Standardwert ist 5 Versuche. Kann eine beliebige positive Ganzzahl sein. Wenn dieser Wert auf 1 festgelegt ist, wird keine Richtlinie für Wiederholungsversuche angewendet. Es wird nur ein Versuch unternommen, eine Nachricht zuzustellen.

Im folgenden Beispiel wird ein linearer Backoff konfiguriert, indem die minimale und maximale Verzögerung auf denselben Wert festgelegt werden:

gcloud 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 beheben.

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

  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 von Exportabo, das Nachrichten beim Empfang in eine vorhandene BigQuery-Tabelle schreibt. Alternativ können Sie die Tabelle erstellen, wenn Sie das BigQuery-Abo erstellen.

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

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

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

    gcloud 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 Pipelinelogs an ein anderes BigQuery-Dataset weiter.

    Sie sollten jetzt zwei separate BigQuery-Datasets haben: eines, in dem alle Nachrichten gespeichert sind, die von Ihrem Eventarc Advanced-Bus empfangen wurden, und eines, in dem Ihre Pipelinelogs gespeichert sind.

  6. Verwenden Sie eine Abfrageanweisung, um Nachrichten zu identifizieren, die nicht zugestellt werden konnten, und verknüpfen Sie beide BigQuery-Datasets über das Feld message_uid.

  7. Nachdem Sie alle fehlgeschlagenen 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 sie 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 Quelle + ID für jedes einzelne Ereignis eindeutig sind.)
  • Außerdem können Sie ein CloudEvents-Attribut, xgooglemessageuid, verwenden, um Idempotenz zu gewährleisten. Der Wert dieses Attributs entspricht dem Feld message_uid in Eventarc Advanced-Nachrichten. Es identifiziert die Aktion des Veröffentlichens 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 Event-Handler 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