Novas tentativas de eventos

Um evento pode ser rejeitado por vários motivos. Por exemplo, o serviço de receptor de eventos pode estar temporariamente indisponível devido a uma interrupção do serviço, um erro pode ser encontrado pelo serviço ao processar um evento ou os recursos do serviço podem se esgotar. É possível tentar novamente erros transitórios como esse.

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

Erros transitórios

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

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

Erros persistentes

Em contraste com erros transitórios, os erros persistentes incluem o seguinte:

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

É possível identificar manualmente erros persistentes e processá-los adequadamente.

Tentar novamente erros transitórios

O Eventarc Advanced usa um atraso de espera exponencial para lidar com erros que permitam novas tentativas. A política de nova tentativa padrão começa com um atraso de um segundo, e o atraso é 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 Google Cloud console ou o gcloud eventarc pipelines update comando.

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

Console

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

    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:

    • Número máximo de tentativas: 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 nova tentativa será aplicada e apenas uma tentativa será feita para entregar uma mensagem.
    • 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 é 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 nova tentativa será aplicada e apenas uma tentativa será feita para entregar uma mensagem.

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

É possível gravar mensagens em uma tabela do BigQuery à medida que 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 as mensagens de eventos, 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 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, é 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 nova tentativa 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 do 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, é possível publicá-las 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 chave de idempotência. Os produtores precisam garantir que a origem + ID seja exclusiva para cada evento distinto.
  • Além disso, é possível usar um atributo do CloudEvents, xgooglemessageuid, para fornecer idempotência. O valor desse atributo é o mesmo que o campo message_uid nas mensagens do Eventarc Advanced. Ele identifica exclusivamente 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 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