SpikeArrest-Richtlinie

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Die Spike Arrest-Richtlinie schützt mit dem Element <Rate> vor Verkehrsanstiegen. 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>

Hier können Sie auswählen, wie die Anfragen gruppiert werden sollen, damit die Spike Arrest-Richtlinie basierend auf auf der Kundschaft. Du kannst beispielsweise Anfragen nach Entwickler-ID gruppieren. Anfragen des Entwicklers werden auf ihre eigene Spike Arrest-Rate angerechnet und nicht auf alle Anfragen an die Proxy.

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 Gewichtung der Nachricht ändert die Auswirkung eines einzelnen Ersuchens zur 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-Anzahl auf die Message Processors (MPs) bei Verwendung von Autoscaling Gruppen.

<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 Das Element wird in Ihrer Spike Arrest-Richtlinie weggelassen.

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

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

• true: Das Spitzenlimit eines MP ist der <Rate> geteilt durch die aktuelle Anzahl der MP im selben Pod. Der aggregierte Grenzwert ist der Wert von <Rate>. Werden Parlamentsmitglieder dynamisch hinzugefügt (oder entfernt), wird ihr jeweiliger Ausschlag Ratenbegrenzungen werden erhöht (oder gesenkt), der aggregierte Grenzwert bleibt jedoch unverändert.
• false (dies ist der Standardwert, wenn keine Angabe gemacht wird): Das Spitzenlimit jedes MP beträgt einfach der Wert seiner <Rate>. Der aggregierte Grenzwert ist die Summe der Raten aller Abgeordneten. Wenn Abgeordnete hinzugefügt (oder entfernt) werden, bleiben ihre individuellen Ratenbegrenzungen für Spitzen gleich, aber der aggregierte Grenzwert wird erhöht (oder verringern).

In der folgenden Tabelle sehen Sie die Auswirkungen von <UseEffectiveCount> auf das effektive Ratenlimit von jeder Abgeordnete:

Beachten Sie in diesem Beispiel Folgendes: Wenn die Anzahl der Abgeordneten von 4 auf 2 verringert wird, <UseEffectiveCount> beträgt false, die effektive Rate pro MP bleibt gleich (bei 10). Wenn <UseEffectiveCount> jedoch true ist, geht die effektive Rate pro MP von 10 auf 20, wenn die Anzahl der Parlamentsmitglieder 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

Dieser Abschnitt beschreibt die zurückgegebenen Fehlercodes und Fehlermeldungen 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 zum Überschreiten eines von einer Kontingent- oder Spike Arrest-Richtlinie festgelegten Ratenlimits ist 429 (Zu viele Anfragen). Um den HTTP-Statuscode in 500 zu ändern (Interner Serverfehler) Property features.isHTTPStatusTooManyRequestEnabled auf false mithilfe von die Organisationseigenschaften aktualisieren API

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
• Vergleich Kontingent- und SpikeArrest-Richtlinien
• Übungsbeispiele für API-Proxys