---
sourceDocument: Xanadu IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/xanadu/it-operations-management

 Release :

    - xanadu

ft:locale :

    - pt-BR

ft:publication_title :

    - Xanadu IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

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

# Configuração de nova tentativa de solicitação de nuvem {#ariaid-title1}

* Versão de lançamento: Xanadu
* 
* Atualizado 1 de ago. de 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 min. de leitura

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 TodosDescobertaConfiguraçã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
{#cloud-request-retry-configuration__ul_vnx_nb1_b5b}

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
{#cloud-request-retry-configuration__ul_ipy_1h1_b5b}

## Espera exponencial {#cloud-request-retry-configuration__section_lgs_2h1_b5b}

Para a configuração de exemplo a seguir:{#cloud-request-retry-configuration__table_chm_xw1_b5b__entry__2}

| 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 |
[ ]

{#cloud-request-retry-configuration__table_chm_xw1_b5b}  
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).
{#cloud-request-retry-configuration__ul_rwr_fx1_b5b}

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 {#cloud-request-retry-configuration__section_ffr_2y1_b5b}

Para a configuração de exemplo a seguir:{#cloud-request-retry-configuration__table_a4m_gy1_b5b__entry__2}

| 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 |
[ ]

{#cloud-request-retry-configuration__table_a4m_gy1_b5b}  
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.
{#cloud-request-retry-configuration__ul_e14_sy1_b5b}

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 {#cloud-request-retry-configuration__section_ipx_byx_f5b}

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.