Novas tentativas de eventos

Um evento pode ser rejeitado por vários motivos. Por exemplo, o serviço de recebimento de eventos pode ficar temporariamente indisponível devido a uma interrupção. Um erro pode ser encontrado pelo serviço ao processar um evento ou os recursos do serviço podem ficar esgotados. Erros temporários como esse podem ser tentados novamente.

Um evento também pode não ser entregue ao receptor. Por exemplo, o evento pode não corresponder ao esquema esperado que foi configurado ou a mediação do evento pode falhar antes que a mensagem do evento seja roteada para o destino final. Esses casos resultam em erros persistentes.

Erros transitórios

O Eventarc Advanced oferece a capacidade de lidar com erros temporários. Esses erros temporários podem ser tentados novamente 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

Em contraste com os 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 roteado para o destino
  • Erros que resultam em um código de erro considerado não reutilizável. Por exemplo, códigos de erro diferentes dos listados para erros transitórios.

É possível identificar manualmente e processar erros persistentes corretamente.

Tentar novamente erros temporários

O Eventarc Advanced usa um atraso de espera exponencial para lidar com erros que podem ser tentados novamente. A política de nova tentativa padrão começa com um atraso de um segundo, e o atraso é duplicado 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 beta eventarc pipelines update.

O fator de desistência padrão de 2 não pode ser alterado.

Console

  1. No console do Google Cloud, 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 nova tentativa, modifique os seguintes campos:

    • Tentativas máximas: o número de novas tentativas. O padrão é 5 tentativas. Pode ser qualquer número real positivo. Se definido como 1, nenhuma política de repetição será aplicada e apenas uma tentativa de envio de mensagem será feita.
    • Atraso mínimo (segundos): o atraso inicial em segundos. O padrão é de 1 segundos. O valor precisa estar entre 1 e 600.
    • Atraso máximo (segundos): o atraso máximo em segundos. O padrão é 60 segundos. O valor 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 beta 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 é 1 segundo. O valor 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 novas tentativas. O padrão é 5 tentativas. Pode ser qualquer número real positivo. Se definido como 1, nenhuma política de repetição será aplicada e apenas uma tentativa de envio de mensagem será feita.

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

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

Arquivar mensagens para lidar com erros persistentes

É possível gravar mensagens em uma tabela do BigQuery conforme elas são recebidas. Isso permite identificar manualmente erros persistentes e gerenciá-los de maneira adequada.

Confira a seguir 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 bus adequadamente. Por exemplo, para publicar eventos de origens do Google.
  2. Crie um tópico do Pub/Sub. Esse tópico do Pub/Sub será o destino de 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 à medida que são recebidas. Como alternativa, você pode criar a tabela ao criar a assinatura do BigQuery.

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

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

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

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

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

  7. Depois de identificar as mensagens com falha, é possível publicá-las novamente no bus 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 bus avançado do Eventarc.

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, é possível usar um atributo do CloudEvents, xgooglemessageuid, para fornecer idempotencia. O valor desse atributo é igual ao 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 bus, cada evento terá um valor xgooglemessageuid diferente quando enviado para 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