Criterio di SpikeArrest

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Il criterio Spike Arrest protegge dai picchi di traffico con l'elemento <Rate>. Questo limita il numero di richieste elaborate da un proxy API e inviate a un backend, per una protezione contro tempi di inattività e ritardi delle prestazioni.

<SpikeArrest> elemento

Definisce il criterio di arresto dei picchi.

<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 modi in cui è possibile utilizzare il criterio Arresto tramite spike:

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

Riferimento elemento secondario

In questa sezione vengono descritti gli elementi secondari di <SpikeArrest>.

<DisplayName>

Da utilizzare in aggiunta all'attributo name per etichettare il criterio in editor proxy UI di gestione con un nome diverso e più naturale.

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

L'elemento <DisplayName> utilizza la seguente sintassi:

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

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

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

<Identifier>

Consente di scegliere come raggruppare le richieste in modo che il criterio di arresto dei picchi possa essere applicato in base sul cliente. Ad esempio, puoi raggruppare le richieste per ID sviluppatore, nel qual caso ogni le richieste degli sviluppatori verranno conteggiate ai fini del proprio tasso di arresto dei picchi e non di tutte le richieste al proxy.

Da utilizzare insieme all'elemento <MessageWeight> per avere un'impostazione più granulare sulla limitazione delle richieste.

Se lasci vuoto l'elemento <Identifier>, viene applicato un limite di frequenza per tutte le richieste in quel 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>

Nella tabella seguente vengono descritti 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 dei picchi. Il peso del messaggio può essere qualsiasi 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 variabili personalizzate usando il criterio JavaScript o il metodo CriterioAssignMessage:

Da utilizzare insieme a <Identifier> per limitare ulteriormente le richieste del per client o app specifici.

Ad esempio, se l'arresto di picco <Rate> è 10pm e un'app invia richieste con una ponderazione di 2, allora sono consentiti solo cinque messaggi al minuto da perché ogni richiesta viene conteggiata come 2.

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

Nella tabella seguente vengono descritti gli attributi di <MessageWeight>:

<Rate>

Specifica la frequenza con cui limitare i picchi di traffico (o burst) impostando il numero di richieste consentite in intervalli al minuto o al secondo. Puoi utilizzare questo elemento anche in abbinamento con <Identifier> e <MessageWeight> per limitare in modo fluido il traffico in fase di runtime accettando 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 name="Spike-Arrest-1">
  <Rate>12pm</Rate>
</SpikeArrest>

Nella tabella seguente vengono descritti gli attributi di <Rate>:

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

<UseEffectiveCount>

Distribuisce il conteggio dei picchi di arresto tra i processori di messaggi (MP) quando si utilizza la scalabilità automatica gruppi.

<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 dalle norme relative all'arresto dei picchi.

Nella tabella seguente vengono descritti gli attributi dell'elemento <UseEffectiveCount>:

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

• true: il limite di frequenza di picco di un MP è <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, il loro singolo picco i limiti di frequenza aumenterà (o diminuiranno), ma il limite aggregato rimarrà invariato.
• false (questo è il valore predefinito se omesso): il limite di frequenza di picco di ogni MP è ma semplicemente il valore del suo <Rate>. Il limite aggregato è la somma delle tariffe di tutti i MP. Quando vengono aggiunti (o rimossi) MP, i singoli limiti di percentuale di picco rimarranno invariati, ma il limite aggregato aumenterà (oppure diminuiscono).

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

In questo esempio, puoi notare che quando il numero di MP viene ridotto da 4 a 2, e <UseEffectiveCount> è false, la tariffa effettiva per MP rimane invariata (a 10). Ma quando <UseEffectiveCount> è true, la tariffa effettiva per MP passa da Da 10 a 20 quando il numero di MP diminuisce da 4 a 2.

Variabili di flusso

Quando viene eseguito un criterio di arresto dei picchi, viene compilata la seguente variabile di flusso:

Per saperne di più, consulta Riferimento per le 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 per le quote o i picchi di arresto è 429 (troppe richieste). Per modificare il codice di stato HTTP in 500 (Errore interno del server), imposta il valore features.isHTTPStatusTooManyRequestEnabled per false utilizzando Aggiorna l'API delle proprietà dell'organizzazione.

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 criterio è definito da uno schema XML (.xsd). Come riferimento, consulta gli schemi dei criteri sono disponibili su GitHub.

Argomenti correlati

• Criteri per le quote: quota per limitare il traffico su singoli client
• Limitazione di frequenza per una limitazione di frequenza panoramica
• Confronto Norme relative a quote e SpikeArrest
• Esempi operativi di proxy API