Criterio SpikeArrest

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info

Il criterio SpikeArrest protegge dai picchi di traffico con l'elemento <Rate>. Questo elemento limita il numero di richieste elaborate da un proxy API e inviate a un backend, proteggendo da ritardi nelle prestazioni e da tempi di riposo.

Elemento <SpikeArrest>

Definisce il criterio SpikeArrest.

<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>

Questo elemento ha i seguenti attributi comuni a tutti i criteri:

Esempi

I seguenti esempi mostrano alcuni dei modi in cui puoi utilizzare il criterio 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>

<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'

Riferimento all'elemento secondario

Questa sezione descrive gli elementi secondari di <SpikeArrest>.

<DisplayName>

Da utilizzare insieme all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso e più naturale.

L'elemento <DisplayName> è comune a tutti i criteri.

La sintassi dell'elemento <DisplayName> è la seguente:

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

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

L'elemento <DisplayName> non ha attributi o elementi secondari.

<Identifier>

Ti consente di scegliere come raggruppare le richieste in modo che il criterio SpikeArrest possa essere applicato in base al client. Ad esempio, puoi raggruppare le richieste per ID sviluppatore, in questo caso le richieste di ogni sviluppatore verranno conteggiate per il proprio tasso di arresto degli picchi e non per tutte le richieste al proxy.

Da utilizzare in combinazione con l'elemento <MessageWeight> per un controllo più granulare sulla limitazione delle richieste.

Se lasci vuoto l'elemento <Identifier>, viene applicato un limite di frequenza per tutte le richieste al proxy API.

<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>

La tabella seguente descrive gli attributi di <Identifier>:

Questo elemento è discusso anche nel seguente post della community Apigee: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<MessageWeight>

Specifica la ponderazione definita per ogni messaggio. Il peso del messaggio modifica l'impatto di una singola richiesta sul calcolo del tasso di arresto picco. Il peso del messaggio può essere qualsiasi variabile di flusso, ad esempio un'intestazione HTTP, un parametro di query, un parametro di modulo o i contenuti del corpo del messaggio. Puoi anche utilizzare le variabili personalizzate utilizzando il criterio JavaScript o il criterio Assegna messaggio.

Da utilizzare in combinazione con <Identifier> per limitare ulteriormente le richieste da client o app specifici.

Ad esempio, se il blocco degli picchi <Rate> è 10pm e un'app invia richieste con un peso di 2, da quel cliente sono consentiti solo cinque messaggi al minuto perché ogni richiesta viene conteggiata come due.

<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>

La tabella seguente descrive gli attributi di <MessageWeight>:

<Rate>

Specifica la frequenza con cui limitare i picchi (o gli aumenti improvvisi) di traffico impostando il numero di richieste consentite in intervalli di un minuto o di un secondo. Puoi anche utilizzare questo elemento insieme a <Identifier> e <MessageWeight> per limitare gradualmente il traffico in fase di esecuzione accettando i valori dal client.

<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>

La tabella seguente descrive gli attributi di <Rate>:

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

<UseEffectiveCount>

Distribuisce i conteggi di arresti di picco tra i processori di messaggi (MP) quando si utilizzano gruppi con scalabilità automatica.

<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>

L'elemento <UseEffectiveCount> è facoltativo. Il valore predefinito è false quando l'elemento viene omesso dal criterio di arresto picchi.

La tabella seguente descrive gli attributi dell'elemento <UseEffectiveCount>:

L'effetto di <UseEffectiveCount> dipende dal suo valore:

• true: il limite di frequenza di picco di un MP è uguale a <Rate> diviso per il numero corrente di MP nello stesso pod. Il limite aggregato è il valore di <Rate>. Quando gli MP vengono aggiunti (o rimossi) in modo dinamico, i relativi limiti di frequenza di picco singolari aumenteranno (o diminuiranno), ma il limite aggregato rimarrà invariato.
• false (questo è il valore predefinito se omesso): il limite di frequenza di picco di ogni MP è semplicemente il valore del relativo <Rate>. Il limite aggregato è la somma delle tariffe di tutti gli MP. Quando vengono aggiunti (o rimossi) gli MP, i singoli limiti di frequenza degli picchi rimangono invariati, ma il limite aggregato aumenta (o diminuisce).

La tabella seguente mostra l'effetto di <UseEffectiveCount> sul limite di tariffa effettivo di ogni MP:

In questo esempio, tieni presente che quando il numero di MP diminuisce da 4 a 2 e <UseEffectiveCount> è false, il tasso effettivo per MP rimane invariato (10). Tuttavia, quando <UseEffectiveCount> è true, il tasso effettivo per parlamentare passa da 10 a 20 quando il numero di parlamentari diminuisce da 4 a 2.

Variabili di flusso

Quando viene eseguito un criterio SpikeArrest, viene compilata la seguente variabile di flusso:

Per ulteriori informazioni, consulta la sezione Riferimento alle variabili di flusso.

Messaggi di errore

Questa sezione descrive i codici e i messaggi di errore restituiti, nonché le variabili di errore. impostate da Edge quando questo criterio attiva un errore. È importante sapere se stai sviluppando regole di errore per per gestire gli errori. Per saperne di più, vedi Cosa devi sapere sugli errori relativi ai criteri e sulla gestione di errore.

Errori di runtime

Questi errori possono verificarsi quando il criterio viene eseguito.

Errori di deployment

Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.

Variabili di errore

Queste variabili vengono impostate quando si verifica un errore di runtime. Per ulteriori informazioni, vedi Cosa devi sapere sugli errori relativi alle norme.

Esempio di risposta di errore

Di seguito è riportato un esempio di risposta di errore:

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

Esempio di regola di errore

Di seguito è riportato un esempio di regola di errore per gestire un errore SpikeArrestViolation:

<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>

L'attuale codice di stato HTTP per il superamento di un limite di frequenza impostato da un criterio di arresto per picchi o quota è 429 (Troppe richieste). Per modificare il codice di stato HTTP in 500 (Errore interno del server), imposta la proprietà features.isHTTPStatusTooManyRequestEnabled su false utilizzando l'API Update organization properties.

Ad esempio:

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>"

Schemi

Ogni tipo di norma è definito da uno schema XML (.xsd). Come riferimento, gli schemi delle norme sono disponibili su GitHub.

Argomenti correlati

• Criteri per le quote: criteri per le quote per limitare il traffico sui singoli client
• Limitazione di frequenza per una panoramica della limitazione di frequenza
• Confronto tra i criteri Quota e SpikeArrest
• Esempi funzionanti di proxy API