Criterio SpikeArrest

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

Il criterio di Arresto dei picchi 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 tempi di inattività.

Elemento <SpikeArrest>

Definisce il criterio di Spike Arrest.

<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 Arrest 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 per l'elemento secondario

Questa sezione descrive gli elementi secondari di <SpikeArrest>.

<DisplayName>

Utilizzalo in aggiunta all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso e dal suono 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 al client. Ad esempio, puoi raggruppare le richieste per ID sviluppatore. In questo caso, le richieste di ogni sviluppatore verranno conteggiate ai fini del proprio tasso di arresto dei picchi e non di tutte le richieste al proxy.

Da utilizzare in combinazione con l'elemento <MessageWeight> per avere 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>

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

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

<MessageWeight>

Specifica la ponderazione definita per ciascun messaggio. Il peso del messaggio modifica l'impatto di una singola richiesta sul calcolo del tasso di arresto anomalo. Il peso del messaggio può essere qualsiasi variabile di flusso, come un'intestazione HTTP, un parametro di query, un parametro del modulo o il contenuto del corpo del messaggio. Puoi anche utilizzare le variabili personalizzate mediante i criteri JavaScript o AssignMessage.

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

Ad esempio, se l'arresto anomalo <Rate> è 10pm e un'app invia richieste con una ponderazione di 2, allora sono consentiti solo cinque messaggi al minuto da quel client 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 (o i burst) di traffico impostando il numero di richieste consentite in intervalli al minuto o al secondo. Puoi anche utilizzare questo elemento in combinazione con <Identifier> e <MessageWeight> per limitare facilmente 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 numero di Spike Arrest tra i processori di messaggi (MP) quando utilizzi i gruppi a 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 Spike Arrest.

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

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

• true: il limite di frequenza dei picchi di un MP è pari a <Rate> diviso per il numero attuale di MP nello stesso pod. Il limite aggregato è il valore di <Rate>. Quando i MP vengono aggiunti (o rimossi in modo dinamico), i limiti di frequenza dei picchi individuali aumentano (o diminuiscono), ma il limite aggregato rimane 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 i MP. Quando vengono aggiunti o rimossi MP, i limiti di frequenza dei picchi individuali rimangono invariati, ma il limite aggregato aumenta (o diminuisce).

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

In questo esempio, nota 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 va da 10 a 20 quando il numero di MP viene ridotto da 4 a 2.

Variabili di flusso

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

Per ulteriori informazioni, consulta la documentazione di riferimento sulle variabili di flusso.

Messaggi di errore

Questa sezione descrive i codici e i messaggi di errore restituiti e le variabili di errore impostate da Edge quando questo criterio attiva un errore. Queste informazioni sono importanti per sapere se si stanno sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta Cosa devi sapere sugli errori relativi alle norme e Gestione degli errori.

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 maggiori informazioni, consulta la sezione Cosa devi sapere sugli errori relativi ai criteri.

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 quota o arresto anomalo è 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 Aggiorna proprietà 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>"

Schema

Ogni tipo di criterio è definito da uno schema XML (.xsd). Come riferimento, gli schemi dei criteri sono disponibili su GitHub.

Argomenti correlati

• Criteri per le quote: criteri per le quote, per limitare il traffico su singoli client
• Limitazione di frequenza per una panoramica della limitazione di frequenza
• Confronto dei criteri di quota e SpikeArrest
• Esempi funzionanti di proxy API