Política de SpikeArrest

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

La política de Spike Arrest protege contra aumentos repentinos de tráfico con el elemento <Rate>. Este elemento regula la cantidad de solicitudes que procesa un proxy de API y se envía a un backend, lo que protege contra los retrasos de rendimiento y el tiempo de inactividad.

Elemento <SpikeArrest>

Define la política de 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>

Este elemento tiene los siguientes atributos que son comunes a todas las políticas:

Ejemplos

En los siguientes ejemplos, se muestran algunas de las formas en las que puedes usar la política de Spike Arrest:

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

Referencia del elemento secundario

En esta sección, se describen los elementos secundarios de <SpikeArrest>.

<DisplayName>

Se usan además del atributo name para etiquetar la política en el editor de proxy de la IU de administración con un nombre de lenguaje natural diferente.

El elemento <DisplayName> es común a todas las políticas.

El elemento <DisplayName> usa la siguiente sintaxis:

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

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

El elemento <DisplayName> no tiene atributos ni elementos secundarios.

<Identifier>

Te permite elegir cómo agrupar las solicitudes para que se pueda aplicar la política de Spike Arrest según el cliente. Por ejemplo, puedes agrupar solicitudes por ID de desarrollador, en cuyo caso las solicitudes de cada desarrollador se contarán en su propia frecuencia de Spike Arrest y no todas las solicitudes al proxy.

Instala junto con el elemento <MessageWeight> para obtener un control más preciso sobre la regulación de solicitudes.

Si dejas el elemento <Identifier> vacío, se aplica un límite de frecuencia para todas las solicitudes a ese proxy de 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>

En la siguiente tabla, se describen los atributos de <Identifier>:

Este elemento también se analiza en la siguiente publicación de la comunidad de Apigee: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<MessageWeight>

Especifica la ponderación definida para cada mensaje. El peso de los mensajes modifica el impacto de una solicitud única en el cálculo de la tasa de Spike Arrest. El peso del mensaje puede ser cualquier variable de flujo, como un encabezado HTTP, un parámetro de consulta, un parámetro de formulario o contenido del cuerpo del mensaje. También puedes usar variables personalizadas mediante la política de JavaScript o la Política de AssignMessage.

Usa junto con <Identifier> para limitar aún más las solicitudes de clientes o apps específicos.

Por ejemplo, si el SpikeArrest <Rate> es 10pm y una app envía solicitudes con una ponderación de 2, solo se permiten cinco mensajes por minuto, porque cada solicitud cuenta como 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>

En la siguiente tabla, se describen los atributos de <MessageWeight>:

<Rate>

Especifica la frecuencia a la que se deben limitar los aumentos repentinos de tráfico (o aumentos de actividad) mediante la configuración de la cantidad de solicitudes permitidas en intervalos por minuto o por segundo. También puedes usar este elemento junto con <Identifier> y <MessageWeight> a fin de limitar el tráfico en el entorno de ejecución con facilidad. Para ello, debes aceptar valores del cliente.

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

En la siguiente tabla, se describen los atributos de <Rate>:

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

<UseEffectiveCount>

Distribuye los recuentos de Spike Arrest entre los procesadores de mensajes (MPs) cuando se usan grupos de ajuste de escala automático.

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

El elemento <UseEffectiveCount> es opcional. El valor predeterminado es false cuando el elemento se omite en tu política de Spike Arrest.

En la siguiente tabla, se describen los atributos del elemento <UseEffectiveCount>:

El efecto de <UseEffectiveCount> depende de su valor:

• true: El límite de frecuencia de picos de un MP es el resultado de dividir <Rate> por la cantidad actual de MPs en el mismo pod. El límite agregado es el valor de <Rate>. Cuando se agregan (o quitan) MPs de forma dinámica, sus límites de frecuencia individuales aumentan (o disminuyen), pero el límite agregado permanece igual.
• false: El límite de frecuencia de picos de cada MP es simplemente el valor de su <Rate>. El límite agregado es la suma de las tarifas de todas las MP. Cuando se agregan (o quitan) MPs, sus límites individuales de tasa de picos se mantienen, pero el límite agregado aumenta (o disminuye).

La política de SpikeArrest usa un algoritmo de "bucket de tokens" que disminuye los aumentos de tráfico dividiendo el límite de frecuencia que especifiques en intervalos más pequeños. Una desventaja de este enfoque es que posiblemente se denieguen varias solicitudes legítimas que ingresen en un intervalo de tiempo corto.

Por ejemplo, supongamos que ingresa una frecuencia de 30 pm (30 solicitudes por minuto). En las pruebas, podrías pensar que podrías enviar 30 solicitudes en 1 segundo, siempre que estén dentro de un minuto. Pero esa no es la forma en que la política aplica la configuración. Si lo piensas, 30 solicitudes en un período de 1 segundo se podrían considerar un pequeño aumento en algunos entornos.

• Las tarifas por minuto se suman a las solicitudes completas permitidas en intervalos de segundos.
  

  Por ejemplo, 30 pm se mitigan de la siguiente manera:
  60 segundos (1 minuto) / 30 pm = intervalos de 2 segundos o 1 solicitud permitida cada 2 segundos. Una segunda solicitud dentro de 2 segundos fallará. Además, fallará la solicitud 31 en un minuto.

• Las tarifas por segundo se suman a las solicitudes completas permitidas en intervalos de milisegundos.

  Por ejemplo, 10 ps se suavizan de la siguiente manera:
  1,000 milisegundos (1 segundo) / 10 ms = 100 milisegundos o 1 solicitud permitida cada 100 milisegundos. Una segunda solicitud dentro de los 100 ms fallarán. Además, fallará la solicitud 11 en un segundo error.

En la siguiente tabla, se muestra el efecto de <UseEffectiveCount> en el límite de frecuencia efectivo de cada MP:

En este ejemplo, observa que, cuando la cantidad de MPs se reduce de 4 a 2 y <UseEffectiveCount> es false, la tasa efectiva por MP se mantiene igual (en 10). Sin embargo, cuando <UseEffectiveCount> es true, la tasa efectiva por MP pasa de 10 a 20 cuando la cantidad de MP se reduce de 4 a 2.

Variables de flujo

Cuando se ejecuta una política de Spike Arrest, se propaga la siguiente variable de flujo:

Para obtener más información, consulta Referencia de variables de flujo.

Referencia de errores

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Example error response

Shown below is an example error response:

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

Example fault rule

Shown below is an example fault rule to handle a SpikeArrestViolation fault:

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

El código de estado HTTP actual para superar un límite de frecuencia establecido por una política de cuota o Spike Arrest es 429 (demasiadas solicitudes). Para cambiar el código de estado HTTP a 500 (error interno del servidor), configura la propiedad features.isHTTPStatusTooManyRequestEnabled como false con la API de Actualizar propiedades de la organización.

Por ejemplo:

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

Esquemas

Un esquema XML (.xsd) define cada tipo de política. Como referencia, los esquemas de políticas están disponibles en GitHub.

Temas relacionados

• Política de cuotas: Política de cuotas, para limitar el tráfico en clientes individuales
• Límite de frecuencia para una descripción general sobre el límite de frecuencia
• Compara políticas de cuota y de SpikeArrest
• Muestras de proxies de API que funcionan