Novas tentativas de eventos

Ao configurar políticas de nova tentativa, você pode reenviar eventos automaticamente após falhas de entrega. Isso ajuda a garantir o processamento confiável de mensagens quando os receptores de eventos sofrem interrupções temporárias no serviço.

Um evento pode ser rejeitado devido a erros temporários, como quando um receptor de eventos fica indisponível temporariamente, encontra um erro ao processar um evento ou esgota os recursos do serviço. Você pode tentar novamente erros temporários assim. Já os erros persistentes ocorrem quando um evento não corresponde ao esquema configurado ou quando a mediação falha antes que a mensagem possa ser encaminhada para o destino.

Erros transitórios

O Eventarc Advanced oferece a capacidade de lidar com erros temporários. Esses erros temporários podem ser repetidos e incluem aqueles com os seguintes códigos de erro:

  • 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

Erros persistentes

Ao contrário dos erros transitórios, os erros persistentes incluem:

  • Erros que ocorrem quando o número de novas tentativas configuradas é esgotado
  • Erros que ocorrem quando um evento falha antes de ser encaminhado para o destino
  • Erros que resultam em um código de erro considerado não passível de novas tentativas, por exemplo, códigos de erro diferentes dos listados para erros transitórios.

Você pode identificar e processar manualmente erros persistentes de maneira adequada.

Tentar novamente erros temporários

O Eventarc Advanced usa um atraso de espera exponencial para lidar com erros que podem ser repetidos. A política de repetição padrão começa com um atraso de um segundo, que é dobrado após cada tentativa com falha (até um máximo de 60 segundos e cinco tentativas).

É possível mudar a política de nova tentativa padrão usando o console do Google Cloud ou o comando gcloud eventarc pipelines update.

O fator de espera padrão de 2 não pode ser alterado.

Console

  1. No Google Cloud console, acesse a página Eventarc > Pipelines.

    Acessar "Pipelines"

  2. Clique no nome do pipeline.

  3. Na página Detalhes do pipeline, clique em Editar.

  4. Na página Editar pipeline, na seção Política de novas tentativas, modifique os seguintes campos:

    • Tentativas máximas: o número de tentativas de entrega. O padrão é 5 tentativas. Pode ser qualquer número inteiro positivo. Se definido como 1, nenhuma política de repetição será aplicada e apenas uma tentativa de envio da mensagem será feita.
    • Atraso mínimo (segundos): o atraso inicial em segundos. O padrão é 1 segundo. Precisa estar entre 1 e 600.
    • Atraso máximo (segundos): o atraso máximo em segundos. O padrão é 60 segundos. Precisa estar entre 1 e 600.

    É possível configurar um backoff linear definindo os atrasos mínimo e máximo com o mesmo valor.

  5. Clique em Salvar.

gcloud 

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

Substitua:

  • PIPELINE_NAME: o ID ou identificador totalmente qualificado do pipeline.
  • MIN_DELAY: o atraso inicial em segundos. O padrão é de 1 segundo. Precisa estar entre 1 e 600.
  • MAX_DELAY: o atraso máximo em segundos. O padrão é 60 segundos. Precisa estar entre 1 e 600.
  • MAX_ATTEMPTS: o número de tentativas de entrega; o padrão é 5 tentativas. Pode ser qualquer número inteiro positivo. Se definido como 1, nenhuma política de repetição será aplicada e apenas uma tentativa de envio da mensagem será feita.

O exemplo a seguir configura um backoff linear definindo os atrasos mínimo e máximo com o mesmo valor:

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

Arquivar mensagens para lidar com erros persistentes

Você pode gravar mensagens em uma tabela do BigQuery conforme elas são recebidas. Isso permite identificar manualmente erros persistentes e processá-los adequadamente.

A seguir, apresentamos uma visão geral das etapas necessárias para arquivar suas mensagens de evento, identificar erros persistentes e tentar novamente os eventos afetados.

  1. Crie um barramento. Configure o barramento adequadamente, por exemplo, para publicar eventos de fontes do Google.
  2. Crie um tópico do Pub/Sub. Esse tópico do Pub/Sub será o destino do seu pipeline.
  3. Crie uma assinatura do BigQuery para o tópico do Pub/Sub. Uma assinatura do BigQuery é um tipo de assinatura de exportação que grava mensagens em uma tabela do BigQuery conforme elas são recebidas. Como alternativa, é possível criar a tabela ao criar a assinatura do BigQuery.

  4. Crie um pipeline e uma inscrição que encaminhe todas as mensagens recebidas pelo barramento (usando --cel-match="true") para o tópico do Pub/Sub. Configure uma política de novas tentativas para o pipeline.

    Por exemplo, os comandos a seguir criam um pipeline e uma inscrição:

    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. Encaminhe os registros do pipeline para outro conjunto de dados do BigQuery.

    Agora você tem dois conjuntos de dados separados do BigQuery: um que armazena todas as mensagens recebidas pelo barramento Eventarc Advanced e outro que armazena os registros do pipeline.

  6. Para identificar mensagens com falha, use uma instrução de consulta para unir os dois conjuntos de dados do BigQuery no campo message_uid.

  7. Depois de identificar as mensagens com falha, publique-as novamente no barramento usando a API Eventarc Publishing. Por exemplo, é possível implantar um serviço ou job do Cloud Run para ler as mensagens do BigQuery e publicá-las diretamente no barramento do Eventarc Advanced.

Tornar manipuladores de eventos idempotentes

Os manipuladores de eventos que podem ser repetidos precisam ser idempotentes. Para isso, siga as seguintes diretrizes gerais:

  • Muitas APIs externas permitem o fornecimento de uma chave de idempotência como um parâmetro. Se você estiver usando uma API como essa, utilize a origem e o ID do evento como a chave de idempotência. Os produtores precisam garantir que source + id seja exclusivo para cada evento distinto.
  • Além disso, você pode usar um atributo do CloudEvents, xgooglemessageuid, para fornecer idempotência. O valor desse atributo é o mesmo do campo message_uid nas mensagens do Eventarc Advanced. Ele identifica de forma exclusiva a ação de publicar um evento. Por exemplo, se o mesmo evento for publicado duas vezes em um barramento, cada evento terá um valor de xgooglemessageuid diferente quando enviado a um manipulador de eventos.
  • A idempotência funciona bem com a entrega do tipo "pelo menos uma vez", porque torna as novas tentativas mais seguras. Dessa forma, para escrever um código confiável, a prática recomendada é combinar idempotência com tentativas.
  • Verifique se o código é idempotente internamente. Por exemplo:
    • Garanta que mutações possam ocorrer mais de uma vez sem alterar o resultado.
    • Consulte o estado do banco de dados em uma transação antes de alterar o estado.
    • Certifique-se de que todos os efeitos colaterais sejam idempotentes.
  • Execute uma verificação transacional fora do serviço, independente do código. Por exemplo, mantenha a persistência de estado em algum local e registre que um determinado código de evento já foi processado.
  • Lide com chamadas duplicadas fora da banda. Por exemplo, tenha um processo de limpeza separado que seja executado após chamadas duplicadas.

A seguir