Passar para o conteúdo principal
Todas as coleçõesConfigurações
Lidando com "Pipeline execution was aborted"
Lidando com "Pipeline execution was aborted"

Como corrigir este erro e otimizar seus deployments

Aline Rodrigues avatar
Escrito por Aline Rodrigues
Atualizado ontem

A plataforma Digibee foi projetada para garantir o funcionamento contínuo das integrações através de estratégias de alta disponibilidade. No entanto, é necessário aplicar configurações adequadas a cada publicação (deployment) para evitar que execuções acima da capacidade do pipeline o tornem indisponível ainda que por um breve período de tempo.

Neste artigo iremos abordar como proceder caso o seu fluxo esteja apresentando o erro abaixo na aba Monitor => Execuções Concluídas:

This pipeline execution was aborted and cannot be automatically retried because it was configured to disallow redeliveries.

(Resposta de execução abortada com código 500)

Cenários de alerta e como solucionar

Este erro ocorre principalmente quando há uma requisição excessiva de memória e/ou CPU. Deve-se ter em mente que até mesmo o tamanho large possui uma capacidade limitada a que consegue atender. Então, para solucionar, será preciso seguir os passos abaixo:

1. Abrir a aba Monitor => Métricas e filtrar pelo período do erro em questão. Atenção: quanto menor o período selecionado, mais precisos serão os valores nos gráficos (artigo).

2. Verificar se houve estouro de memória ou CPU. Atenção: o limite de memória é 100%, porém o de CPU é 20% para small, 40% para medium e 80% para large (artigo).

3. Verificar se o tamanho dos payloads de entrada ou de saída atingiu 5 MB ou o limite configurado na trigger.

4. Abrir a aba Monitor => Execuções Concluídas ou Pipeline Logs e verificar quais foram os últimos passos antes da interrupção.

5. Abrir o pipeline na aba Build e analisar se ele se encaixa em algum dos seguintes cenários de alerta:

- Carregamento de arquivo grande (por exemplo, acima de 7 MB ou acima do limite configurado no conector de arquivo)

- Carregamento de muitos dados via conector DB

- REST ou SOAP onerosos ao processamento

- Grande quantidade de conectores com interação externa (REST/SOAP/DB/Script/arquivo)

- Blocos em loop contendo conectores externos e rodando em paralelo ou não

- Parallel Execution seguido por múltiplos conectores externos

- Logs em excesso ou muito extensos

6. Solução: feito o diagnóstico, recomenda-se aplicar uma ou mais das estratégias a seguir:

- Aumentar o tamanho do deployment to pipeline

- Diminuir a quantidade de execuções simultâneas (ATENÇÃO: A memória alocada para o deployment é compartilhada entre as execuções simultâneas. Por exemplo, em um deployment large com 40 execuções, a memória será dividida por 40. Já com 30 execuções, a mesma quantidade de memória será dividida por 30, resultando em uma maior capacidade de processamento para cada execução, já que a divisão da memória ocorre entre um número menor de chamadas concorrentes.)

- Diminuir a quantidade de dados na entrada ou saída do pipeline

- Controlar a carga de dados no corpo do pipeline com limites, filtros e paginação

- Aumentar a frequência do pipeline para assim fazer processamentos mais leves

- Remover ou diminuir logs com payloads muito grandes

- Limpar a memória de componentes session management com a operação DELETE

- Preferir execuções sequenciais ao invés de paralelas

- Dividir o processamento em múltiplos pipelines

Otimizando o deployment

Para uma configuração de deployment otimizada e livre de falhas, é necessário primeiramente publicar o pipeline e observar o seu desempenho para determinar se irá precisar de refinamento.

Além da alocação adequada dos recursos computacionais (escala vertical), deve-se ajustar o número de execuções simultâneas (escala horizontal) de maneira equilibrada, conferindo um ritmo regular aos processamentos.

Outros fatores a se considerar são o tamanho de fila tolerado e a taxa de vazão desejada, que é a relação entre execuções por segundo (EPS) e tempo de resposta do pipeline.

Respondeu à sua pergunta?