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 se esgotar. Erros temporários como esse podem ser repetidos.

Um evento também pode não ser entregue ao receptor de eventos. 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 permite 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.

É possível 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 novas tentativas 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 Google Cloud ou o comando gcloud beta eventarc pipelines update.

Não é possível mudar o fator de espera padrão de 2.

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

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 lidar com eles de maneira adequada.

A seguir, apresentamos uma visão geral das etapas necessárias para arquivar as 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 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. 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 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 unir os dois conjuntos de dados do BigQuery no campo message_uid.

7. Depois de identificar as mensagens com falha, você pode publicá-las novamente no barramento usando a API Publishing do Eventarc. 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 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 diferente.
• Além disso, você pode usar um atributo do CloudEvents, xgooglemessageuid, para fornecer idempotência. O valor desse atributo é igual ao campo message_uid nas mensagens avançadas do Eventarc. 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

• Resolver problemas
• Ver registros de auditoria