---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - de-DE

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Wiederholung von Cloud-Anforderungen konfigurieren

# Wiederholung von Cloud-Anforderungen konfigurieren {#ariaid-title1}

* Freigeben Version: Yokohama
* 
* Aktualisiert 30. Januar 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 Minuten Lesedauer

Wenn eine Anforderung während der Discovery von einem Cloud-Anbieter gedrosselt wird, bietet die Konfiguration der Wiederholung von Cloud-Anforderungen eine anpassbare Methode zum erneuten Versuch von Anforderungen. Muster für Discovery und Service-MappingEnthält eine Wiederholungskonfiguration für AWSUnd Azure. Sie können die enthaltene Konfiguration anpassen oder eine eigene erstellen.
Discovery-Administratoren und Cloud-Administratoren können unter auf die Konfiguration der Anforderungswiederholung zugreifen AlleDiscoveryWiederholung von Cloud-Anforderungen konfigurierenan. Sie können eine Konfiguration für jeden Anbieter erstellen.  
Wenn eine Anforderung gedrosselt wird, verwendet das Wiederholungs-Framework die für den Provider definierte Wiederholungskonfiguration, um Wiederholungen zu verarbeiten, bevor die endgültige Antwort an die ApiCommand-Klassen zurückgegeben wird:

* AwsApiCommand
* AzureApiCommand
{#cloud-request-retry-configuration__ul_vnx_nb1_b5b}

Die Wiederholungskonfigurationen werden mit synchronisiert MID ServersDurch MID-ServerEigenschaft, mid.cloud.discovery.retry.configuration.  
Es gibt die folgenden Wiederholungsstrategien:

* Exponentieller Backoff
* Antwortheader-Backoff
* Anwenderdefiniertes Backoff
{#cloud-request-retry-configuration__ul_ipy_1h1_b5b}

## Exponentieller Backoff {#cloud-request-retry-configuration__section_lgs_2h1_b5b}

Für die folgende Beispielkonfiguration:{#cloud-request-retry-configuration__table_chm_xw1_b5b__entry__2}

| Einstellung | Wert |
|-|-|
| Max. Wiederholungen | 3 |
| Antwortcodes | 429 |
| Basisverzögerung in ms | 1000 |
| Max. Verzögerung in ms | 10000 |
| Zusätzliches Verzögerungsfenster in ms | 1500 |
[ ]

{#cloud-request-retry-configuration__table_chm_xw1_b5b}  
Die Wiederholungsstrategie für exponentielle Backoff funktioniert wie folgt:

* Erster Versuch: Der Backoff-Multiplikator wird zufällig zwischen 0 und 1 ausgewählt. Der maximale Verzögerungswert beträgt 400 ms (400 \* 1).
* 2. Wiederholung: Der Backoff-Multiplikator wird zufällig zwischen 0 und 3 ausgewählt. Der maximale Verzögerungswert beträgt 1200 ms (400 \* 3).
* 3. Wiederholung: Der Backoff-Multiplikator wird zufällig zwischen 0 und 7 ausgewählt. Der maximale Verzögerungswert beträgt 2800 ms (400 \* 7).
{#cloud-request-retry-configuration__ul_rwr_fx1_b5b}

Wenn die Verzögerung bei nachfolgenden Wiederholungen 10000 (die maximale Verzögerung) überschreitet, werden 10000 als anfängliche Verzögerung verwendet.

Sobald die anfängliche Verzögerung generiert wurde, wird der Verzögerung ein Jitter hinzugefügt. Das Jitter-Fenster wird durch definiert Zusätzliches Verzögerungsfenster in ms Feld. Das System wählt einen zufälligen Wert zwischen 0 und 1500 aus und fügt ihn der anfänglichen Verzögerung hinzu.

Wenn die anfängliche Verzögerung 500 beträgt, kann die endgültige Verzögerung (mit Jitter) ein Wert zwischen 500 und 2000 ms sein.

## Antwortheader-Backoff {#cloud-request-retry-configuration__section_ffr_2y1_b5b}

Für die folgende Beispielkonfiguration:{#cloud-request-retry-configuration__table_a4m_gy1_b5b__entry__2}

| Einstellung | Wert |
|-|-|
| Max. Wiederholungen | 3 |
| Antwortcodes | 429 |
| Antwortheader | Erneut Versuchen Nach |
| Verzögerungseinheit des Antwortheaders | Sekunden |
| Zusätzliches Verzögerungsfenster in ms | 1500 |
[ ]

{#cloud-request-retry-configuration__table_a4m_gy1_b5b}  
Die Backoff-Strategie für den Antwortheader funktioniert wie folgt:

* Rufen Sie den Wert des Headers ab Retry-AfterAus der Serverantwort.
* Konvertieren Sie Retry-AfterAuf Millisekunden durch Multiplikation mit 1000.
{#cloud-request-retry-configuration__ul_e14_sy1_b5b}

Sobald die anfängliche Verzögerung generiert wurde, wird der Verzögerung ein Jitter hinzugefügt. Das Jitter-Fenster wird durch definiert Zusätzliches Verzögerungsfenster in ms Feld. Das System wählt einen zufälligen Wert zwischen 0 und 1500 aus und fügt ihn der anfänglichen Verzögerung hinzu.

Wenn die anfängliche Verzögerung 2000 beträgt, kann die endgültige Verzögerung (mit Jitter) ein Wert zwischen 2000 und 3500 ms sein.

## Anwenderdefiniertes Backoff {#cloud-request-retry-configuration__section_ipx_byx_f5b}

Mit einer anwenderdefinierten Backoff-Wiederholungsstrategie definieren Sie Max. Wiederholungen Und Antwortcodes Und erstellen Sie eigene Mid-Skripteinbindung Das definiert, wie Anforderungen mit wiederholt werden getDelay()Funktion. Weitere Informationen finden Sie unter Skripteinbindungen .