Configuração de nova tentativa de solicitação de nuvem

Se uma solicitação for limitada por um provedor de nuvem durante a Descoberta, a configuração de nova tentativa de solicitação de nuvem fornecerá um método personalizável para tentar novamente as solicitações. Padrões de descoberta e mapeamento de serviços inclui uma configuração de nova tentativa para AWS e Azure. Você pode personalizar a configuração incluída ou criar a sua própria.

Os administradores de descoberta e os administradores de nuvem podem acessar a configuração de nova tentativa de solicitação em Todos > Descoberta > Configuração de nova tentativa de solicitação de nuvem. Você pode criar uma configuração para cada provedor.

Quando uma solicitação é limitada, a estrutura de nova tentativa usa a configuração de nova tentativa definida para o provedor lidar com novas tentativas antes de retornar a resposta final para as classes ApiCommand:

• AWSApiCommand
• AzureApiCommand

As configurações de nova tentativa são sincronizadas com MID Servers por meio da propriedade [ MID Server, mid.cloud.discovery.retry.configuration.

Existem as seguintes estratégias de nova tentativa:

• Espera exponencial
• Espera do cabeçalho de resposta
• Espera personalizada

Espera exponencial

Para a configuração de exemplo a seguir:

Configuração	Valor
Máximo de tentativas	3
Códigos de resposta	429
Atraso básico em ms	1000
Atraso máximo em ms	10000
Janela de atraso adicional em ms	1500

A estratégia de nova tentativa de espera exponencial funciona da seguinte forma:

• Primeira tentativa: o multiplicador de espera é selecionado aleatoriamente entre 0 e 1. O valor máximo de atraso é 400 ms (400 * 1).
• Segunda nova tentativa: o multiplicador de espera é selecionado aleatoriamente entre 0 e 3. O valor máximo de atraso é 1200 ms (400 * 3).
• Terceira tentativa: o multiplicador de espera é selecionado aleatoriamente entre 0 e 7. O valor máximo de atraso é 2800 ms (400 * 7).

Em novas tentativas subsequentes, se o atraso exceder 10.000 (o atraso máximo), 10.000 será usado como atraso inicial.

Depois que o atraso inicial é gerado, o jitter é adicionado ao atraso. A janela de jitter é definida pelo campo Janela de atraso adicional em ms. O sistema seleciona um valor aleatório entre 0 e 1500 e o adiciona ao atraso inicial.

Se o atraso inicial for 500, o atraso final (com jitter) poderá ser um valor entre 500 e 2000 ms.

Espera do cabeçalho de resposta

Para a configuração de exemplo a seguir:

Configuração	Valor
Máximo de tentativas	3
Códigos de resposta	429
Cabeçalho de resposta	Repetir-Após
Unidade de atraso do cabeçalho de resposta	segundos
Janela de atraso adicional em ms	1500

A estratégia de espera do cabeçalho de resposta funciona da seguinte forma:

• Obtenha o valor do cabeçalho Retry-After da resposta do servidor.
• Converta o Retry-After em milissegundos multiplicando por 1000.

Depois que o atraso inicial é gerado, o jitter é adicionado ao atraso. A janela de jitter é definida pelo campo Janela de atraso adicional em ms. O sistema seleciona um valor aleatório entre 0 e 1500 e o adiciona ao atraso inicial.

Se o atraso inicial for 2000, o atraso final (com jitter) poderá ser um valor entre 2000 e 3500 ms.

Espera personalizada

Com uma estratégia de nova tentativa de espera personalizada, você define o máximo de novas tentativas e os códigos de resposta e cria sua própria inclusão de script MID que define como as solicitações são repetidas usando a função getDelay(). Para obter mais informações, consulte Inclusões de script.