SpikeArrest-Richtlinie

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Die Spike Arrest-Richtlinie schützt mit dem Element <Rate> vor Trafficspitzen. Dieses Element drosselt die Anzahl der Anfragen, die von einem API-Proxy verarbeitet und an ein Back-End gesendet werden, um Leistungsverzögerungen und Ausfallzeiten zu verhindern.

Element <SpikeArrest>

Definiert die Spike Arrest-Richtlinie.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <DisplayName>display_name</DisplayName>
  <Properties/>
  <Identifier ref="flow_variable"/>
  <MessageWeight ref="flow_variable"/>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
  <DisplayName>Spike Arrest-1</DisplayName>
  <Properties/>
  <Identifier ref="request.header.some-header-name"/>
  <MessageWeight ref="request.header.weight"/>
  <Rate>30ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Dieses Element hat folgende Attribute, die allen Richtlinien gemeinsam sind:

Beispiele

Die folgenden Beispiele zeigen Möglichkeiten, wie Sie die Spike Arrest-Richtlinie verwenden können:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

Verweis auf untergeordnetes Element

In diesem Abschnitt werden die untergeordneten Elemente von <SpikeArrest> beschrieben.

<DisplayName>

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen, natürlicher klingenden Namen zu versehen.

Das Element <DisplayName> ist für alle Richtlinien gleich.

Das <DisplayName>-Element verwendet die folgende Syntax:

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

Das <DisplayName>-Element hat keine Attribute oder untergeordneten Elemente.

<Identifier>

Lässt Sie wählen, wie die Anfragen gruppiert werden sollen, damit die Spike Arrest-Richtlinie auf der Grundlage des Clients angewendet werden kann. Sie können beispielsweise Anfragen nach Entwickler-ID gruppieren. In diesem Fall werden die Anfragen jedes Entwicklers auf seine eigene Spike Arrest-Rate und nicht auf alle Anfragen an den Proxy angerechnet.

Wird in Verbindung mit dem Element <MessageWeight> für eine genauere Steuerung der Anfragedrosselung verwendet.

Wenn Sie das Element <Identifier> leer lassen, wird für alle Anfragen an diesen API-Proxy eine Ratenbegrenzung erzwungen.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>
        

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

In der folgenden Tabelle werden die Attribute von <Identifier> beschrieben:

Dieses Element wird auch im folgenden Apigee-Communitybeitrag diskutiert: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<MessageWeight>

Gibt die für jede Nachricht definierte Gewichtung an. Die Nachrichtengewichtung ändert die Auswirkung einer einzelnen Anfrage auf die Berechnung der Spike Arrest-Rate. Die Nachrichtengewichtung kann eine beliebige Ablaufvariable sein, z. B. ein HTTP-Header, Abfrageparameter, Formularparameter oder Inhalt des Nachrichtentexts. Sie können auch benutzerdefinierte Variablen mithilfe der JavaScript-Richtlinie oder der AssignMessage-Richtlinie verwenden.

Wird in Verbindung mit <Identifier> verwendet, um Anfragen von bestimmten Clients oder Anwendungen drosseln zu können.

Wenn der Spike Arrest <Rate> beispielsweise 10pm ist und eine Anwendung Anfragen mit einer Gewichtung von 2 sendet, sind von diesem Client nur fünf Nachrichten pro Minute zulässig, weil jede Anfrage als 2 zählt.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

In der folgenden Tabelle werden die Attribute von <MessageWeight> beschrieben:

<Rate>

Gibt die Rate an, mit der die Trafficspitzen (oder Bursts) durch Begrenzung der Anzahl der Anfragen pro Minute oder pro Sekunde eingeschränkt werden. Sie können dieses Element auch zusammen mit <Identifier> und <MessageWeight> verwenden, um den Traffic während der Laufzeit reibungslos zu drosseln, indem Sie Werte vom Client akzeptieren.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
</SpikeArrest>

In der folgenden Tabelle werden die Attribute von <Rate> beschrieben:

<Rate ref="request.header.custom_rate">1pm</Rate>

<UseEffectiveCount>

Verteilt die Spike Arrest-Zahlen auf Message Processors (MPs), wenn Autoscaling-Gruppen verwendet werden.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Das <UseEffectiveCount>-Element ist optional. Der Standardwert ist false, wenn das Element in Ihrer Spike Arrest-Richtlinie weggelassen wird.

In der folgenden Tabelle werden die Attribute des <UseEffectiveCount> -Elements beschrieben:

Die Auswirkung von <UseEffectiveCount> hängt von seinem Wert ab:

• true: Das Grenzwert für die Spitzenrate einer MP ist der <Rate> geteilt durch die aktuelle Anzahl von MPs im selben Pod. Das aggregierte Limit ist der Wert von <Rate>. Wenn MPs dynamisch hinzugefügt oder entfernt werden, erhöhen oder verringern sich die individuellen Spitzenratenlimits, das Aggregatlimit bleibt jedoch gleich.
• false (Dies ist der Standardwert, wenn nicht angegeben): Das Grenzwert für die Spitzenrate jeder MP ist einfach der Wert ihrer <Rate>. Das Limit für die Abstimmung ist die Summe der Raten aller Abgeordneten. Wenn MPs hinzugefügt oder entfernt werden, bleiben die jeweiligen Grenzwerte für die Spitzenrate gleich, aber das aggregierte Limit wird erhöht (oder verringert).

Die folgende Tabelle zeigt die Auswirkungen von <UseEffectiveCount> auf die effektive Ratenbegrenzung jeder MP:

Beachten Sie in diesem Beispiel, dass die effektive Rate pro MP gleich bleibt (bei 10), wenn die Anzahl der MPs von 4 auf 2 verringert wird und <UseEffectiveCount> auf false gesetzt ist. Wenn <UseEffectiveCount> jedoch true ist, sinkt die effektive Rate pro MP von 10 auf 20, wenn die Anzahl der MP von 4 auf 2 verringert wird.

Ablaufvariablen

Beim Ausführen einer Spike Arrest-Richtlinie wird die folgende Ablaufvariable ausgefüllt:

Weitere Informationen finden Sie unter Referenz zu Ablaufvariablen.

Fehlerreferenz

In diesem Abschnitt werden die Fehlercodes und Fehlermeldungen beschrieben, die zurückgegeben werden, sowie die Fehlervariablen, die von Edge festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Bereitstellungsfehler

Diese Fehler können auftreten, wenn Sie einen Proxy mit dieser Richtlinie bereitstellen.

Fehlervariablen

Diese Variablen werden bei Laufzeitfehlern festgelegt. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.

Beispiel für eine Fehlerantwort

Im Folgenden sehen Sie ein Beispiel für eine Fehlerantwort:

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.SpikeArrestViolation"
      },
      "faultstring":"Spike arrest violation. Allowed rate : 10ps"
   }
}

Beispiel für eine Fehlerregel

Unten sehen Sie ein Beispiel für eine Fehlerregel zum Verarbeiten eines SpikeArrestViolation-Fehlers:

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

Der aktuelle HTTP-Statuscode für die Überschreitung einer durch eine Kontingent- oder Spike Arrest-Richtlinie festgelegten Ratenbegrenzung ist 429 (zu viele Anfragen). Wenn Sie den HTTP-Statuscode in 500 (Interner Serverfehler) ändern möchten, setzen Sie das Attribut features.isHTTPStatusTooManyRequestEnabled mithilfe der API zum Aktualisieren der Organisationsattribute auf false.

Beispiel:

curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

Schemas

Jeder Richtlinientyp wird durch ein XML-Schema (.xsd) definiert. Zu Referenzzwecken sind Richtlinienschemas auf GitHub verfügbar.

Weitere Informationen

• Kontingentrichtlinie: Kontingentrichtlinie zum Beschränken des Traffics auf einzelne Clients
• Ratenbegrenzung für eine Übersicht über Ratenbegrenzungen
• Kontingent- und SpikeArrest-Richtlinien im Vergleich
• Übungsbeispiele für API-Proxys