SpikeArrest-Richtlinie

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

Die SpikeArrest-Richtlinie schützt mit dem Element <Rate> vor Trafficanstieg. 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 async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</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, sodass die SpikeArrest-Richtlinie basierend auf dem Client angewendet werden kann. Sie können beispielsweise Anfragen nach Entwickler-ID gruppieren. In diesem Fall werden die Anfragen jedes Entwicklers auf die eigene SpikeArrest-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 Auswirkungen einer einzelnen Anfrage auf die Berechnung der SpikeArrest-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 async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

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

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

<UseEffectiveCount>

Die Anzahl der Spike Arrest-Ereignisse wird bei Verwendung von automatisch skalierten Gruppen auf Nachrichtenprozessoren verteilt.

<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 aus Ihrer Spike Arrest-Richtlinie ausgeschlossen ist.

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

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

• true: Die Spitze der Auslastungsrate eines Multi-Processing-Clusters ist <Rate> geteilt durch die aktuelle Anzahl der Multi-Processing-Cluster im selben Pod. Das Gesamtlimit ist der Wert <Rate>. Wenn dynamische Anzeigenblöcke hinzugefügt oder entfernt werden, erhöhen (oder verringern) sich die individuellen Limits für die Auslieferungsrate bei Spitzen, das Gesamtlimit bleibt jedoch gleich.
• false (dies ist der Standardwert, wenn nichts angegeben wird): Das Limit für die Spitzenrate jedes MPs entspricht einfach dem Wert seines <Rate>. Das Gesamtlimit ist die Summe der Preise aller Preismodelle. Wenn MP hinzugefügt oder entfernt werden, bleiben die individuellen Limits für die Spitzenrate gleich, aber das Gesamtlimit erhöht (oder verringert) sich.

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

In diesem Beispiel wird die Anzahl der Anzeigenblöcke von 4 auf 2 reduziert und <UseEffectiveCount> ist false. Die effektive Rate pro Anzeigenblock bleibt gleich (10). Wenn <UseEffectiveCount> = true ist, steigt die effektive Rate pro Anzeigenblock von 10 auf 20, wenn die Anzahl der Anzeigenblöcke von 4 auf 2 reduziert 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 einer Ratenbegrenzung, die von einer Kontingent- oder Spike Arrest-Richtlinie festgelegt wurde, lautet 429 (Zu viele Anfragen). Wenn Sie den HTTP-Statuscode in 500 ändern möchten (Interner Serverfehler), setzen Sie das Attribut features.isHTTPStatusTooManyRequestEnabled über die API Organisationsattribute aktualisieren 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 vergleichen
• Übungsbeispiele für API-Proxys