Wiederholung von Cloud-Anforderungen konfigurieren

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-Mapping Enthält eine Wiederholungskonfiguration für AWS Und 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 Alle > Discovery > Wiederholung von Cloud-Anforderungen konfigurierenan. Sie können eine Konfiguration für jeden Provider erstellen.

Wenn eine Anforderung eingeschränkt wird, wird vom Framework für Wiederholungen die für den Provider definierte Wiederholungskonfiguration dazu verwendet, Wiederholungen zu verarbeiten, bevor die endgültige Antwort an die ApiCommand-Klassen zurückgegeben wird:

• AwsApiCommand
• AzureApiCommand

Die Wiederholungskonfigurationen werden über die MID-Server-Eigenschaft mid.cloud.discovery.retry.configuration mit den MID Servers n synchronisiert.

Es gibt die folgenden Wiederholungsstrategien:

• Exponentielles Backoff
• Antwortheader – Backoff
• Anwenderdefiniertes Backoff

Exponentielles Backoff

Für die folgende Beispielkonfiguration …

Einstellung	Wert
Max. Wiederholungen	3
Antwortcodes	429
Basisverzögerung in ms	1.000
Max. Verzögerung in ms	10000
Additional delay window in ms (Fenster „Weitere Verzögerung“ in ms)	1500

… funktioniert die Wiederholungsstrategie „Exponentielles Backoff“ wie folgt:

• 1. Wiederholung: 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 1.200 ms (400 * 3).
• 3. Wiederholung: Der Backoff-Multiplikator wird zufällig zwischen 0 und 7 ausgewählt. Der maximale Verzögerungswert beträgt 2.800 ms (400 * 7).

Wenn die Verzögerung bei nachfolgenden Wiederholungen 10.000 überschreitet (die maximale Verzögerung), wird der Wert 10.000 als anfängliche Verzögerung verwendet.

Sobald die anfängliche Verzögerung generiert wurde, wird der Verzögerung Jitter hinzugefügt. Das Fenster „Jitter“ wird durch das Feld Additional delay window in ms (Fenster „Weitere Verzögerung“ in ms) definiert. Vom System wird ein zufälliger Wert zwischen 0 und 1.500 ausgewählt und zur anfänglichen Verzögerung addiert.

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

Antwortheader – Backoff

Für die folgende Beispielkonfiguration …

Einstellung	Wert
Max. Wiederholungen	3
Antwortcodes	429
Antwortheader	Retry-After (Wiederholen-nach)
Verzögerungseinheit für Antwortheader	Sekunden
Additional delay window in ms (Fenster „Weitere Verzögerung“ in ms)	1500

… funktioniert die Backoff-Strategie für Antwortheader wie folgt:

• Rufen Sie den Wert des Headers Retry-After aus der Serverantwort ab.
• Konvertieren Sie den Wert von Retry-After in Millisekunden, indem Sie ihn mit 1.000 multiplizieren.

Sobald die anfängliche Verzögerung generiert wurde, wird der Verzögerung Jitter hinzugefügt. Das Fenster „Jitter“ wird durch das Feld Additional delay window in ms (Fenster „Weitere Verzögerung“ in ms) definiert. Vom System wird ein zufälliger Wert zwischen 0 und 1.500 ausgewählt und zur anfänglichen Verzögerung addiert.

Wenn die anfängliche Verzögerung 2.000 beträgt, kann die endgültige Verzögerung (mit Jitter) einen Wert zwischen 2.000 und 3.500 ms annehmen.

Anwenderdefiniertes Backoff

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 .