Konfiguration für Wiederholung von Cloud-Anforderungen

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 2 Minuten Lesedauer
  • Wenn eine Anforderung während der Erkennung von einem Cloud-Provider gedrosselt wird, bietet die Wiederholungskonfiguration für Cloud-Anforderungen eine anpassbare Methode, um Anforderungen zu wiederholen. 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 für Anforderungswiederholungen zugreifen Alle > Discovery > Konfiguration für Wiederholung von Cloud-Anforderungen. 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 Serversn synchronisiert.

    Es gibt die folgenden Wiederholungsstrategien:
    • Exponentielles Backoff
    • Antwortheader – Backoff
    • Benutzerdefiniertes 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.

    Benutzerdefiniertes Backoff

    Mit einer benutzerdefinierten Backoff-Wiederholungsstrategie definieren Sie die maximalen Wiederholungsversuche und Antwortcodes und erstellen Ihre eigene MID- Skripteinbindung, die definiert, wie Anforderungen mit der Funktion getDelay() wiederholt werden. Weitere Informationen finden Sie unter Skripteinbindungen.