Esta página se aplica a Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.
Descripción general
Una cuota es una asignación de mensajes de solicitud que un proxy de API puede controlar durante un período, como un minuto, una hora, un día, una semana o un mes. La política de cuotas mantiene contadores que recopilan la cantidad de solicitudes recibidas por el proxy de API. Esta capacidad permite que los proveedores de API apliquen límites a la cantidad de llamadas a la API que realizan las aplicaciones en un intervalo de tiempo. Mediante las políticas de cuotas, puedes, por ejemplo, limitar las apps a 1 solicitud por minuto o 10,000 solicitudes por mes.
Esta política es una política extensible, y el uso de esta puede tener implicaciones de costo o uso, según tu licencia de Apigee. Para obtener información sobre los tipos de políticas y sus implicaciones de uso, consulta Tipos de políticas.
Por ejemplo, si una cuota se define como 10,000 mensajes por mes, el límite de frecuencia comienza después del mensaje 10,000. No importa si se cuentan 10,000 mensajes el primer día o el último día de ese período. No se permiten solicitudes adicionales hasta que el contador de cuota se restablezca automáticamente al final del intervalo de tiempo especificado o hasta que la cuota se restablezca de manera explícita mediante la política ResetQuota.
Una variación de la política de cuotas, política SpikeArrest, evita los aumentos repentinos del tráfico (o los aumentos de actividad) que pueden deberse a un aumento repentino en el uso, a los clientes defectuosos o a los ataques maliciosos.
Usa la política de cuotas para configurar la cantidad de mensajes de solicitud que permite el proxy de API durante un período, como un minuto, una hora, un día, una semana o un mes. Puedes configurar la cuota para que sea la misma para todas las apps que acceden al proxy de API. También puedes configurar la cuota en función de lo siguiente:
- El producto que contiene el proxy de API
- La app que solicita la API
- El programador de apps
- Muchos otros criterios
No uses la política de cuotas para protegerte contra los incrementos de tráfico repentinos generales. Para eso, usa la política SpikeArrest.
Videos
En estos videos, se presenta la administración de cuotas con la política de cuotas:
Introducción
Cuota dinámica
Sincrónico y distribuido
Peso del mensaje
Calendario
Ventana móvil
Flexi
Cuota condicional
Variables de flujo
Manejo de errores
Tipos de políticas de cuotas
La política de cuotas admite varias formas diferentes en las que el contador de cuotas se inicia y se restablece.
Puedes definir cuál usar con el atributo type
en el elemento <Quota>
, como se muestra en el siguiente ejemplo:
<Quota name="QuotaPolicy" type="calendar"> ... </Quota>
Los valores válidos de type
incluyen lo siguiente:
calendar
: Configura una cuota según una hora de inicio explícita. El contador de cuotas para cada app se actualiza según los valores<StartTime>
,<Interval>
y<TimeUnit>
que establezcas.rollingwindow
: Configura una cuota que use una “ventana móvil” para determinar el uso de la cuota. Conrollingwindow
, determina el tamaño de la ventana con los elementos<Interval>
y<TimeUnit>
. Por ejemplo, 1 día. Cuando llega una solicitud, Apigee analiza la hora exacta de la solicitud (por ejemplo, 5:01 p.m.), cuenta la cantidad de solicitudes que llegaron entre entonces y las 5:01 p.m. del día anterior (1 día) y determina si se superó o no la cuota durante ese período.flexi
: Configura una cuota que genere que el contador comience cuando se reciba el primer mensaje de solicitud de una app y se restablezca según los valores<Interval>
y<TimeUnit>
.
En la siguiente tabla, se describen los restablecimientos de cuota para cada tipo:
Unidad de tiempo | Tipo | ||
---|---|---|---|
default (o nulo) |
calendar |
flexi |
|
minuto | Inicio del próximo minuto | Un minuto después de <StartTime> |
Un minuto después de la primera solicitud |
hora | Parte superior de la próxima hora | Una hora después de <StartTime> |
Una hora después de la primera solicitud |
día | Medianoche GMT del día actual | 24 horas después del <StartTime> |
24 horas después de la primera solicitud |
semana | El domingo a la medianoche GMT cuando termina la semana | Una semana después de <StartTime> |
Una semana después de la primera solicitud |
mes | Medianoche GMT del último día del mes | Un mes (28 días) después de <StartTime> |
Un mes (28 días) después de la primera solicitud |
Para type="calendar"
, debes especificar el valor de <StartTime>
.
La tabla no enumera el valor del tipo rollingwindow
. Las cuotas de ventana móvil funcionan si configuras el tamaño de una ventana de cuota, como una ventana de una hora o un día.
Cuando llega una solicitud nueva, la política determina si se superó la cuota en el período anterior de tiempo.
Por ejemplo, puedes definir un período de dos horas que permita 1,000 solicitudes. Se envía una solicitud nueva a las 4:45 p.m. La política calcula la cantidad de cuotas para las últimas dos horas, lo que significa la cantidad de solicitudes desde las 2:45 p.m. Si el límite de cuota no se excede en esa ventana de dos horas, se permite la solicitud.
Un minuto después, a las 4:46 p.m., ingresa otra solicitud. Ahora la política calcula el recuento de cuotas desde las 2:46 p.m. para determinar si se superó el límite.
Para el tipo rollingwindow
, el contador nunca se restablece, pero se vuelve a calcular en cada solicitud.
Obtén información sobre los contadores de cuota
Cuando una política de cuotas se ejecuta en un flujo del proxy de API, se reduce un contador de cuota. Cuando el contador alcanza su límite, no se permiten más llamadas a la API asociadas con ese contador. Según la configuración que uses, la política de cuotas puede emplear uno o más contadores. Es importante comprender cuándo se emplean varios contadores y cómo se comportan.
Cómo se cuentan las cuotas para los productos de API
Si tu proxy de API se incluye en un producto de API, puedes configurar la política de cuotas para usar las reglas de cuota que se definen en ese producto. Un producto de API puede especificar reglas de cuota a nivel de producto o a nivel de operaciones individuales.
Se mantiene un contador de cuota separado para cada operación definida en un producto de API, y se observan las siguientes reglas:
- Si una operación tiene una cuota definida para ella, las reglas de cuota de la operación tienen prioridad sobre las de cuota definidas a nivel del producto. Se crea un contador de cuotas por separado para cada operación. Cualquier llamada a la API a la ruta de una operación aumenta su contador.
- Si una operación no tiene una cuota definida para ella, se aplica la regla de cuota a nivel del producto. Sin embargo, se mantiene un contador de cuota independiente para la operación. Es importante comprender en este caso que, aunque la regla de cuota se toma de la definición a nivel de producto, la operación mantiene su propio contador.
- Si el producto de API no incluye ninguna definición de cuota, ni a nivel del producto ni de la operación, se aplican las reglas de cuota especificadas en la política. Sin embargo, en este caso también se mantiene un contador de cuota individual para cada operación en el producto de API.
En las siguientes secciones, se describen las opciones y el comportamiento de los contadores con más detalle.
Configura contadores a nivel del proxy de API
Es posible configurar un producto de API para mantener un recuento de cuota en el alcance del proxy de API. En este caso, todas las operaciones que no tienen su propia cuota comparten la configuración de cuota especificada en el nivel de producto de la API. El efecto de esta configuración es crear un contador global a nivel del proxy de API para este producto de API.
Para lograr esta configuración, debes usar la API de Apigee /apiproducts para crear o actualizar el producto y establecer el atributo quotaCountScope
como PROXY
en la solicitud de creación o actualización.
Con la configuración PROXY
, todas las operaciones definidas para el producto de API que estén asociadas con el mismo proxy y no tengan su propio contador compartirán el mismo contador de cuota establecido a nivel de producto de la API.
En la Figura 1, la operación 1 y 2 se asocian con el Proxy1 y las operaciones 4 y 5 están asociadas con el Proxy3. Debido a que quotaCounterScope=PROXY
se establece en el producto de API, cada una de estas operaciones comparte la configuración de cuota a nivel de producto de la API. Ten en cuenta que, aunque estas operaciones comparten la misma configuración de cuota, usan contadores independientes según su asociación de proxy. Por otro lado, la operación 3 tiene su propia configuración de cuota y, por lo tanto, no se ve afectada por la marca quotaCounterScope
.
Figura 1: Uso de la marca cuotaCounterScope
De forma predeterminada, si una operación no tiene una cuota definida para ella, se aplica la regla de cuota a nivel del producto. Sin embargo, se mantiene un contador de cuota independiente para la operación.
Cómo se cuentan las cuotas si no se usan productos de API
Si no hay un producto de API asociado con un proxy de API, una política de cuotas mantiene un solo contador, sin importar cuántas veces hagas referencia a él en un proxy de API. El nombre del contador de cuotas se basa en el atributo name
de la política.
Por ejemplo, creas una política de cuotas llamada MyQuotaPolicy
con un límite de 5 solicitudes y la coloca en varios flujos (flujo A, B y C) en el proxy de API. Aunque se usa en varios flujos, mantiene un solo contador que se actualiza en todas las instancias de la política:
- Se ejecuta el flujo A -> Se ejecuta MyQuotaPolicy y su contador = 1
- Se ejecuta el flujo B -> Se ejecuta MyQuotaPolicy y el contador = 2
- Se ejecuta el flujo A -> Se ejecuta MyQuotaPolicy y el contador = 3
- Se ejecuta el flujo C -> MyQuotaPolicy se ejecuta y su contador = 4
- Se ejecuta el flujo A -> Se ejecuta MyQuotaPolicy y su contador = 5
La siguiente solicitud a cualquiera de los tres flujos es rechazada porque el contador de cuota alcanzó su límite.
El uso de la misma política de cuotas en más de un lugar en un flujo de proxy de API, que puede provocar de forma involuntaria que la cuota se ejecute más rápido de lo esperado, es un antipatrón descrito en Introducción a los antipatrones.
Como alternativa, puedes definir varias políticas de cuotas en tu proxy de API y usar una política diferente en cada flujo. Cada política de cuota mantiene su propio contador, según el atributo name
de la política.
Crea varios contadores a través de la configuración de la política
Puedes usar los elementos <Class>
o <Identifier>
en la política de cuotas para definir varios contadores únicos en una sola política. Si usas estos elementos, una sola política puede mantener diferentes contadores según la aplicación que realice la solicitud, el desarrollador de la aplicación que realiza la solicitud, un ID de cliente o cualquier otro identificador de cliente y más. Consulta los ejemplos anteriores para obtener más información sobre el uso de los elementos <Class>
o <Identifier>
.
Notación de tiempo
Todas las horas de la cuota se establecen en la zona horaria Horario universal coordinado (UTC).
La notación de hora de la cuota sigue la notación de fechas estándar internacional que se define en ISO 8601.
Las fechas se definen como año, mes y día, con el siguiente formato: YYYY-MM-DD.
Por ejemplo, 2021-02-04
representa el 4 de febrero de 2021.
La hora del día se define como horas, minutos y segundos con el siguiente formato: hours:minutes:seconds
. Por ejemplo, 23:59:59
representa la hora un segundo antes de la medianoche.
Ten en cuenta que dos notaciones, 00:00:00
y 24:00:00
, están disponibles para distinguir las dos medianoches que se pueden asociar con una fecha. Por lo tanto, 2021-02-04
24:00:00
tiene la misma fecha y hora que 2021-02-05 00:00:00
. Esta última suele ser la notación preferida.
Obtén la configuración de cuotas desde la configuración de productos de la API
Puedes establecer límites de cuota en las configuraciones de productos de API. Esos límites no aplican automáticamente la cuota. En su lugar, puedes hacer referencia a la configuración de la cuota de productos en una política de cuotas. Estas son algunas ventajas de establecer una cuota en el producto para la referencia de las políticas de cuota:
- Las políticas de cuotas pueden usar una configuración uniforme en todos los proxies de API del producto de la API.
- Puedes realizar cambios en el entorno de ejecución a la configuración de cuotas en un producto de API y las políticas de cuota que hacen referencia al valor tienen automáticamente valores de cuota actualizados.
Si deseas obtener más información para usar la configuración de cuota desde un producto de la API, consulta el ejemplo de “Cuota dinámica” anterior.
Si deseas obtener más información para configurar productos de API con límites de cuota, consulta Administra productos de la API.
Configura contadores de cuotas compartidas
Por lo general, la política de cuotas cuenta todas las solicitudes enviadas a un proxy de API. En algunos casos de uso, es posible que desees aplicar el recuento de cuotas de solicitudes entrantes, pero también aumentarlo para las respuestas de destino que cumplan con una condición específica.
Tres elementos de la política de cuotas cuando se usan en conjunto, <SharedName>
, <CountOnly>
y <EnforceOnly>
, te permiten personalizar la política de cuotas para aplicar la cuota de solicitud entrante y contar las respuestas de destino en función de un condición que especifiques.
Por ejemplo, supongamos que deseas aumentar el contador de la cuota para un proxy de API en el que las respuestas del destino de backend tienen un código de estado HTTP 200
. Para lograr este conteo especializado, haz lo siguiente:
- Agrega una política de cuotas al flujo de solicitudes de ProxyEndpoint con el elemento
<SharedName>
establecido con un valor de nombre y el elemento<EnforceOnly>
establecido contrue
. - Agrega otra política de cuotas al flujo de respuesta de ProxyEndpoint con el elemento
<SharedName>
configurado con el mismo valor de nombre que la primera política y el elemento<CountOnly>
configurado comotrue
. - Coloca la segunda política de cuotas (la con
<CountOnly>
) en un paso condicional que establezca la condición para aumentar el recuento de cuotas.
Para ver un ejemplo de cómo usar los contadores compartidos, consulta Contadores compartidos en la sección Ejemplos.
Ejemplos
En estos ejemplos de código de política, se muestra cómo comenzar y finalizar los períodos de cuota:
Más cuota dinámica
<Quota name="CheckQuota"> <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval> <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit> <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/> </Quota>
Las cuotas dinámicas te permiten configurar una política de Cuota única que aplique una configuración de cuota diferente según la información que se pase a la política de cuotas. Otro término para la configuración de cuotas en este contexto es el plan de servicio. La cuota dinámica comprueba el plan de servicio de las apps y, luego, aplica esa configuración.
Por ejemplo, cuando creas un producto de API, tienes la opción de configurar el límite de cuota, la unidad de tiempo y el intervalo permitidos. Sin embargo, establecer este valor en el producto de API no impone su uso en un proxy de API. También debes agregar una política de cuota al proxy de API que lea estos valores. Consulta Crea productos de API para obtener más información.
En el ejemplo anterior, el proxy de API que contiene la política de cuotas usa una política VerifyAPIKey, llamada verify-api-key
, para validar la clave de API que se pasa en una solicitud. Luego, la política de cuotas accede a las variables de flujo de la política VerifyAPIKey para leer los valores de cuota establecidos en el producto de API.
Otra opción es configurar atributos personalizados en desarrolladores o apps individuales y, luego, leer esos valores en la política de cuotas. Por ejemplo, para establecer diferentes valores de cuota por desarrollador, establece atributos personalizados en el desarrollador que contengan el límite, la unidad de tiempo y el intervalo. Luego, debes hacer referencia a estos valores en la política de cuotas como se muestra a continuación:
<Quota name="DeveloperQuota"> <Identifier ref="verifyapikey.verify-api-key.client_id"/> <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/> <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/> <Allow countRef="verifyapikey.verify-api-key.developer.limit"/> </Quota>
En este ejemplo, también se usan las variables de flujo VerifyAPIKey para hacer referencia a los atributos personalizados establecidos en el desarrollador.
Puedes usar cualquier variable para configurar los parámetros de la política de cuotas. Estas variables pueden provenir de las siguientes fuentes:
- Variables de flujo
- Propiedades en el producto, la app o el desarrollador de la API
- Un mapa de clave-valor (KVM)
- Un encabezado, parámetro de búsqueda, parámetro de formulario y otros
Para cada proxy de API, puedes agregar una política de cuotas que haga referencia a la misma variable que todas las demás políticas de cuotas, o la política de cuotas puede hacer referencia a variables únicas para esa política y proxy.
Hora de inicio
<Quota name="QuotaPolicy" type="calendar"> <StartTime>2021-02-18 10:30:00</StartTime> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
Para una cuota con type
establecido como calendar
, debes definir un valor <StartTime>
explícito. El valor de tiempo es la hora GMT, no la hora local. Si no proporcionas un valor <StartTime>
para una política del tipo calendar
, Apigee emite un error.
El contador de cuotas para cada app se actualiza en función de los valores <StartTime>
, <Interval>
y <TimeUnit>
. En este ejemplo, la cuota comienza a contar a las 10:30 a.m. GMT del 18 de febrero de 2021 y se actualiza cada 5 horas. Por lo tanto, la próxima actualización es a las 3:30 p.m. GMT del 18 de febrero de 2021.
Contador de acceso
<Quota name="QuotaPolicy"> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
Un proxy de API tiene acceso a las variables de flujo que configura la política de cuotas. Puedes acceder a estas variables de flujo en el proxy de API para realizar el procesamiento condicional, supervisar la política a medida que se acerca al límite de la cuota, mostrar el recuento de cuota actual a una app o por otras razones.
Debido a que el acceso a las variables de flujo para la política se basa en el atributo name
de las políticas, para la política anterior <Quota>
, puedes acceder a sus variables de flujo en el formato:
ratelimit.QuotaPolicy.allowed.count
: Recuento Permitidoratelimit.QuotaPolicy.used.count
: Valor actual de contadorratelimit.QuotaPolicy.expiry.time
: Hora de UTC cuando se restablece el contador.
Existen muchas otras variables de flujo a las que puedes acceder, como se describe a continuación.
Por ejemplo, puedes usar la siguiente política AssignMessage para mostrar los valores de las variables de flujo de cuota como encabezados de respuesta:
<AssignMessage continueOnError="false" enabled="true" name="ReturnQuotaVars"> <AssignTo createNew="false" type="response"/> <Set> <Headers> <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header> <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header> <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header> </Headers> </Set> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage>
Contadores compartidos
En el siguiente ejemplo, se ilustra cómo configurar un contador compartido para un proxy de API, en el que el contador de cuota también se incrementa cuando la respuesta de destino es el estado HTTP 200
.
Debido a que ambas políticas de cuotas usan el mismo valor <SharedName>
, ambas políticas de cuota compartirán el mismo contador de cuota. Para obtener más información, consulta Configura contadores de cuota compartida.
Ejemplo de configuración de ProxyEndpoint:
<ProxyEndpoint name="default"> <PreFlow name="PreFlow"> <Request> <Step> <Name>Enforce-Only</Name> <!--First quota policy enforces quota count --> </Step> </Request> <Response> <Step> <Name>Count-Only</Name> <!-- Second quota policy counts quota if call is successful --> <Condition>response.status.code = 200</Condition> </Step> </Response> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPProxyConnection> <BasePath>/quota-shared-name</BasePath> </HTTPProxyConnection> <RouteRule name="noroute"/> </ProxyEndpoint>
Ejemplo de la primera política de cuotas:
<Quota continueOnError="false" enabled="true" name="Enforce-Only" type="rollingwindow"> <DisplayName>Enforce-Only</DisplayName> <Properties/> <Allow count="5"/> <Interval>2</Interval> <TimeUnit>minute</TimeUnit> <Distributed>true</Distributed> <Synchronous>true</Synchronous> <EnforceOnly>true</EnforceOnly> <SharedName>common-proxy</SharedName> <!-- Notice that SharedName value is the same for both Quota policies --> </Quota>
Ejemplo de la política de cuotas:
<Quota continueOnError="false" enabled="true" name="Count-Only" type="rollingwindow"> <DisplayName>Count-Only</DisplayName> <Properties/> <Allow count="5"/> <Interval>2</Interval> <TimeUnit>minute</TimeUnit> <Distributed>true</Distributed> <Synchronous>true</Synchronous> <CountOnly>true</CountOnly> <SharedName>common-proxy</SharedName> <!-- Same name as the first policy --> </Quota>
Primera solicitud
<Quota name="MyQuota"> <Interval>1</Interval> <TimeUnit>hour</TimeUnit> <Allow count="10000"/> </Quota>
Usa este código de muestra para aplicar una cuota de 10,000 llamadas por hora. La política restablece el recuento de cuotas en la parte superior de cada hora. Si el recuento alcanza la cuota de 10,000 llamadas antes de que finalice la hora, se rechazan las llamadas que superen los 10,000.
Por ejemplo, si el recuento comienza el 2021-07-08 07:00:00
, se restablece en 0 a las 2021-07-08 08:00:00
(1 hora desde la hora de inicio). Si el primer mensaje se recibe a las 2021-07-08 07:35:28
y el recuento de mensajes alcanza los 10,000 antes de 2021-07-08 08:00:00
, las llamadas posteriores a ese recuento se rechazan hasta que el recuento se restablezca en la parte superior de la hora.
El tiempo de restablecimiento de contadores se basa en la combinación de <Interval>
y <TimeUnit>
. Por ejemplo, si estableces <Interval>
en 12 por un <TimeUnit>
de hora, el contador se restablece cada doce horas.
Puedes configurar <TimeUnit>
como minutos, horas, días, semanas o meses.
Puedes hacer referencia a esta política en varias partes del proxy de API. Por ejemplo, puedes ubicarla en el PreFlow del proxy para que se ejecute en cada solicitud. O bien, puedes ubicarla en varios flujos en el proxy de API. Si usas esta política en varios lugares del proxy, mantendrá un solo contador que se actualice para todas las instancias de la política.
También puedes definir varias políticas de cuotas en el proxy de API. Cada política de cuota mantiene su propio contador, según el atributo name
de la política.
Identificador de conjunto
<Quota name="QuotaPolicy" type="calendar"> <Identifier ref="request.header.clientId"/> <StartTime>2021-02-18 10:00:00</StartTime> <Interval>5</Interval> <TimeUnit>hour</TimeUnit> <Allow count="99"/> </Quota>
De forma predeterminada, una política de cuotas define un solo contador para el proxy de API, sin importar el origen de una solicitud. Como alternativa, puedes usar el atributo <Identifier>
con una política de cuotas para mantener contadores separados según el valor del atributo <Identifier>
.
Por ejemplo, usa la etiqueta <Identifier>
a fin de definir contadores independientes para cada ID de cliente. En una solicitud a tu proxy, la app cliente pasa un encabezado que contiene clientID
, como se muestra en el ejemplo anterior.
Puedes especificar cualquier variable de flujo para el atributo <Identifier>
. Por ejemplo, puedes especificar que un parámetro de búsqueda llamado id
contenga el identificador único:
<Identifier ref="request.queryparam.id"/>
Si usas la política VerifyAPIKey a fin de validar la clave de API o las políticas de OAuthV2 con tokens de OAuth, puedes usar información de la clave de API o del token para definir contadores individuales para la misma política de cuotas. Por ejemplo, el siguiente elemento <Identifier>
usa la variable de flujo client_id
de una política VerifyAPIKey llamada verify-api-key
:
<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>
Cada valor client_id
único ahora define su propio contador en la política de cuotas.
Clase
<Quota name="QuotaPolicy"> <Interval>1</Interval> <TimeUnit>day</TimeUnit> <Allow> <Class ref="request.header.developer_segment"> <Allow class="platinum" count="10000"/> <Allow class="silver" count="1000" /> </Class> </Allow> </Quota>
Puedes establecer límites de cuotas de forma dinámica mediante un recuento de cuota basado en la clase. En este ejemplo, el límite de cuota se determina según el valor del encabezado developer_segment
que se pasa con cada solicitud. Esa variable puede tener un valor de platinum
o silver
. Si el encabezado tiene un valor no válido, la política muestra un error de incumplimiento de cuota.
Elemento <Quota>
A continuación, se muestran los atributos y los elementos secundarios de <Quota>
. Ten en cuenta que algunas combinaciones de elementos son mutuamente excluyentes o no obligatorias. Consulta las muestras para un uso específico.
Las variables verifyapikey.my-verify-key-policy.apiproduct.*
que se muestran a continuación están disponibles de forma predeterminada cuando se usa una política VerifyAPIKey llamada my-verify-key-policy
a fin de verificar la clave de API de la app en la solicitud.
Los valores de las variables provienen de la configuración de cuota del producto de la API con el que está asociada la clave, como se describe en Obtén la configuración de cuotas desde la configuración de productos de la API.
<Quota continueOnError="false" enabled="true" name="Quota-3" type="calendar"> <DisplayName>Quota 3</DisplayName> <Allow count="UPPER_REQUEST_LIMIT" countRef="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.limit"/> <Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="UPPER_LIMIT_DURING_PEAK"/> <Allow class="off_peak_time" count="UPPER_LIMIT_DURING_OFFPEAK"/> </Class> </Allow> <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval> <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit> <StartTime>2021-7-16 12:00:00</StartTime> <Distributed>false</Distributed> <Synchronous>false</ Synchronous> <AsynchronousConfiguration> <SyncIntervalInSeconds>20</ SyncIntervalInSeconds> <SyncMessageCount>5</ SyncMessageCount> </AsynchronousConfiguration> <Identifier/> <MessageWeight/> <UseQuotaConfigInAPIProduct> <DefaultConfig> <Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow> <Interval ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.interval">1</Interval> <TimeUnit ref="verifyapikey.my-verify-key-policy.apiproduct.developer.quota.timeunit">month</TimeUnit> </DefaultConfig> </UseQuotaConfigInAPIProduct> </SharedName> </CountOnly> </EnforceOnly> </Quota>
Los siguientes atributos son específicos de esta política:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
tipo |
Establece el Tipo de política de cuota, que determina cuándo y cómo el contador de cuota verifica el uso de la cuota y cómo se restablece. Si no configuras Estos son algunos de los valores válidos:
Para obtener una descripción completa de cada tipo, consulta Tipos de políticas de cuotas. |
N/A | Opcional |
En la siguiente tabla, se describen los atributos que son comunes a todos los elementos principales de las políticas:
Atributo | Descripción | Configuración predeterminada | Presence |
---|---|---|---|
name |
El nombre interno de la política. El valor del atributo De forma opcional, usa el elemento |
N/A | Obligatorio |
continueOnError |
Configúralo como Configúralo como |
false | Opcional |
enabled |
Configúralo como Configúralo como |
true | Opcional |
async |
Este atributo dejó de estar disponible. |
false | Obsoleto |
Elemento <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.
<DisplayName>Policy Display Name</DisplayName>
Configuración predeterminada |
N/A Si omites este elemento, se usa el valor del atributo |
---|---|
Presence | Opcional |
Tipo | String |
<Allow>
Especifica el límite de conteo para la cuota. Si el recuento de la política alcanza este valor de límite, las llamadas posteriores se rechazan hasta que se restablece el contador.
También puede contener un elemento <Class>
que haga que el elemento <Allow>
sea condicional según una variable de flujo.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Tipo complejo o número entero |
Elemento principal |
<Quota>
|
Elementos secundarios |
<Class> |
A continuación, se muestran tres formas de establecer el elemento <Allow>
:
<Allow count="2000"/>
<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
Si especificas count
y countRef
, entonces countRef
tiene la prioridad. Si countRef
no se resuelve en el entorno de ejecución, se usa el valor de count
.
También puedes especificar un elemento <Class>
como elemento secundario de <Allow>
para determinar el recuento permitido de la política en función de una variable de flujo. Apigee hace coincidir el valor de la variable de flujo con el atributo class
del elemento <Allow>
, como se muestra a continuación:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow>
En la siguiente tabla, se enumeran los atributos de <Allow>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
count |
Se usa para especificar un recuento de mensajes de la cuota. Por ejemplo, un valor de atributo |
2000 | Opcional |
countRef |
Se usa para especificar una variable de flujo que contiene el recuento de mensajes de una cuota.
|
ninguno | Opcional |
<Class>
Te permite hacer condicional el valor del elemento <Allow>
según el valor de una variable de flujo. Por cada etiqueta secundaria <Allow>
diferente de <Class>
, la política mantiene un contador diferente.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Tipo complejo |
Elemento principal |
<Allow>
|
Elementos secundarios |
<Allow> (secundario de <Class> ) |
Para usar el elemento <Class>
, especifica una variable de flujo mediante el atributo ref
al elemento <Class>
. Luego, Apigee usa el valor de la variable de flujo para seleccionar una de los elementos secundarios <Allow>
a fin de determinar el recuento permitido de la política. Apigee hace coincidir el valor de la variable de flujo con el atributo class
del elemento <Allow>
, como se muestra a continuación:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow class="peak_time" count="5000"/> <Allow class="off_peak_time" count="1000"/> </Class> </Allow>
En este ejemplo, el contador de la cuota actual se determina por el valor del parámetro de búsqueda time_variable
que se pasa con cada solicitud. Esa variable puede tener un valor de peak_time
o off_peak_time
. Si el parámetro de consulta contiene un valor no válido, la política muestra un error de incumplimiento de cuota.
En la siguiente tabla, se enumeran los atributos de <Class>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
ref | Se usa para especificar una variable de flujo que contiene la clase de cuota de una cuota. | ninguno | Obligatorio |
<Allow>
(secundario de <Class>
)
Especifica el límite para un contador de cuota definido por el elemento <Class>
. Por cada etiqueta secundaria <Allow>
diferente de <Class>
, la política mantiene un contador diferente.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Tipo complejo |
Elemento principal |
<Class>
|
Elementos secundarios |
Ninguno |
Por ejemplo:
<Allow> <Class ref="request.queryparam.time_variable"> <Allow count="5000"/> <Allow count="1000"/> </Class> </Allow>
En este ejemplo, la política de cuotas mantiene dos contadores de cuota llamados peak_time
y off_peak_time
. La opción de cuál se use depende del parámetro de búsqueda que se pase, como se muestra en el ejemplo de <Class>
.
En la siguiente tabla, se enumeran los atributos de <Allow>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
clase | Define el nombre del contador de cuota. | ninguno | Obligatorio |
count | Especifica el límite de cuota del contador. | ninguno | Obligatorio |
<Interval>
Especifica la cantidad de períodos en los que se calculan las cuotas.
Valor predeterminado | n/a |
¿Es obligatorio? | Obligatorio |
Tipo | Entero |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Se usa para especificar un número entero (por ejemplo, 1, 2, 5, 60, etc.) que se sincronizará con el elemento <TimeUnit>
que especifiques (minuto, hora, día, semana o mes) para determinar un período durante el cual Apigee calcula el uso de la cuota.
Por ejemplo, un intervalo de 24
con un <TimeUnit>
de hour
significa que la cuota se calculará durante 24 horas.
<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
En la siguiente tabla, se enumeran los atributos de <Interval>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
ref |
Se usa para especificar una variable de flujo que contiene el intervalo de una cuota. |
ninguno | Opcional |
<TimeUnit>
Especifica la unidad de tiempo aplicable a la cuota.
Valor predeterminado | n/a |
¿Es obligatorio? | Obligatorio |
Tipo | String |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Selecciona entre minute
, hour
, day
, week
, month
o year
.
Por ejemplo, un Interval
de 24
con un TimeUnit
de hour
significa que la cuota se calculará durante 24 horas.
<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
Predeterminado: | ninguno |
Presencia: | Obligatorio |
Tipo: | String |
En la siguiente tabla, se enumeran los atributos de <TimeUnit>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
ref | Especifica una variable de flujo que contiene la unidad de tiempo de una cuota. ref tiene prioridad sobre un valor del intervalo explícito. Si ref no se resuelve en el entorno de ejecución, se usa el valor del intervalo. |
ninguno | Opcional |
<StartTime>
Cuando type
se configura como calendar
, se especifica la fecha y la hora en que el contador de cuotas comenzará a contar, sin importar si se recibieron solicitudes de alguna app.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional (obligatorio cuando type se establece en calendar ) |
Tipo | String en formato de fecha y hora ISO 8601 |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Debes proporcionar un <StartTime>
explícito cuando type
se establece de forma explícita como calendar
, no puedes usar una referencia a una variable de flujo. Si especificas un valor <StartTime>
cuando no se estableció un valor type
, Apigee mostrará un error.
Por ejemplo:
<StartTime>2021-7-16 12:00:00</StartTime>
<Distributed>
Determina si Apigee usa uno o más nodos para procesar solicitudes.
Valor predeterminado | false |
¿Es obligatorio? | Opcional |
Tipo | Booleano |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Configúralo como true
para especificar que la política debe mantener un recuento central y sincronizarlo continuamente en todos los nodos. Los nodos pueden estar ubicados en diferentes zonas o regiones de disponibilidad.
Si usas el valor predeterminado de false
, puedes exceder tu cuota, ya que no se comparte el recuento de cada nodo:
<Distributed>false</Distributed>
Para garantizar que los contadores se sincronicen y se actualicen en cada solicitud, configura <Distributed>
y <Synchronous>
como true
:
<Distributed>true</Distributed> <Synchronous>true</Synchronous>
<Synchronous>
Determina si se debe actualizar un contador de cuotas distribuidas de forma síncrona.
Valor predeterminado | false |
¿Es obligatorio? | Opcional |
Tipo | Booleano |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Configúralo como true
para actualizar un contador de cuotas distribuidas de forma síncrona. Esto significa que las actualizaciones de los contadores se realizan al mismo tiempo que la cuota se comprueba en una solicitud a la API. Configúralo como true
si es fundamental que no permitas ninguna llamada a la API cuando se supera la cuota.
Configúralo como false
para actualizar el recuento de cuotas de forma asíncrona. Esto significa que es posible que algunas llamadas a la API que excedan la cuota se transferirán, dependiendo de cuándo se actualice de forma asíncrona el contador de cuota en el repositorio central. Sin embargo, no tendrás el impacto potencial de rendimiento asociado con las actualizaciones síncronas.
El intervalo de actualización asíncrono predeterminado es de 10 segundos. Usa el elemento <AsynchronousConfiguration>
para configurar este comportamiento asíncrono.
<Synchronous>false</Synchronous>
<AsynchronousConfiguration>
Configura el intervalo de sincronización entre los contadores de cuota distribuida cuando el elemento de configuración de la política <Synchronous>
no está presente o está presente y se establece en false
. Apigee ignora este elemento cuando <Synchronous>
se establece en true
.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Tipo complejo |
Elemento principal |
<Quota>
|
Elementos secundarios |
<SyncIntervalInSeconds> <SyncMessageCount> |
Puedes especificar el comportamiento de sincronización con los elementos secundarios <SyncIntervalInSeconds>
o <SyncMessageCount>
. Usa uno o ambos elementos. Por ejemplo:
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> </AsynchronousConfiguration>
o
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> <SyncMessageCount>5</SyncMessageCount> </AsynchronousConfiguration>
- Cuando solo está presente
<SyncIntervalInSeconds>
, la cuota se sincroniza cada N segundos, donde N es el valor especificado en el elemento, independientemente de la cantidad de mensajes que se hayan controlado. - Cuando solo está presente
<SyncMessageCount>
, la cuota sincroniza cada M mensajes, donde M es el valor especificado en el elemento, o cada 10 segundos, lo que ocurra primero. - Cuando ambos elementos están presentes, la cuota se sincroniza cada M mensajes o cada N segundos, lo que ocurra primero.
- Cuando
<AsynchronousConfiguration>
no está presente o no hay ningún elemento secundario, la cuota se sincroniza cada 10 segundos, independientemente de la cantidad de mensajes que se hayan controlado.
<SyncIntervalInSeconds>
Anula el comportamiento predeterminado en el que se realizan actualizaciones asíncronas después de un intervalo de 10 segundos.
Valor predeterminado | 10 segundos |
¿Es obligatorio? | Opcional |
Tipo | Entero |
Elemento principal |
<AsynchronousConfiguration>
|
Elementos secundarios |
Ninguno |
<AsynchronousConfiguration> <SyncIntervalInSeconds>20</SyncIntervalInSeconds> </AsynchronousConfiguration>
El intervalo de sincronización debe ser mayor que 10 segundos, como se describe en Límites.
<SyncMessageCount>
Especifica la cantidad de solicitudes que se deben procesar antes de sincronizar el contador de cuotas.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Entero |
Elemento principal |
<AsynchronousConfiguration>
|
Elementos secundarios |
Ninguno |
<AsynchronousConfiguration> <SyncMessageCount>5</SyncMessageCount> </AsynchronousConfiguration>
Con la configuración de este ejemplo, en cada nodo, el recuento de cuota se sincronizará después de cada 5 solicitudes o cada 10 segundos, lo que ocurra primero.
<Identifier>
Configura la política para crear contadores únicos basados en una variable de flujo.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | String |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
A través del elemento Identificador, puedes asignar recuentos de llamadas a distintos buckets definidos por el valor en una variable de flujo. Por ejemplo, puedes usar la variable developer.id
, que se propaga después de una política VerifyAPIKey, para aplicar un límite de cuota a todas las instancias de todas las apps que crea cada desarrollador específico. También puedes usar client_id
a fin de aplicar un límite de cuota para cada app en particular. La configuración de esto último luce de la siguiente manera:
<Identifier ref="client_id"/>
Puedes hacer referencia a una variable personalizada que puedas establecer con la política AssignMessage o la política de JavaScript, o una variable establecida de forma implícita, como las que configuran la política VerifyAPIKey o la política VerifyJWT. Para obtener más información sobre las variables, consulta Usa variables de flujo. Para obtener una lista de las variables conocidas que define Apigee, consulta la Referencia de variables de flujo.
Si no usas este elemento, la política asigna todos los recuentos de llamadas a un solo contador para la política de cuotas específica.
También se analiza este elemento en ¿Cómo funciona la política de cuotas cuando no se especifica ningún identificador?
En la siguiente tabla, se describen los atributos de <Identifier>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
ref |
Especifica una variable de flujo que identifica el recuento que se usará para la solicitud. La variable puede hacer referencia a un encabezado HTTP, un parámetro de consulta, un parámetro de formulario o un elemento del contenido del mensaje, o algún otro valor para identificar cómo asignar recuentos de llamadas. Por lo general, |
N/A | Opcional |
<MessageWeight>
Especifica el costo asignado a cada mensaje para fines de cuota. Usa este elemento para aumentar el impacto de los mensajes de solicitud que, por ejemplo, consumen más recursos de procesamiento que otros.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Entero |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Por ejemplo, deseas contar los mensajes POST
con el doble del costo que los mensajes GET
. Por lo tanto, debes establecer <MessageWeight>
en 2 para POST
y 1 para GET
. Puedes establecer <MessageWeight>
en 0 para que la solicitud no afecte el contador.
En este ejemplo, si la cuota es de 10 mensajes por minuto y el <MessageWeight>
para las solicitudes POST
es 2
, la cuota permitirá 5 solicitudes POST
en cualquier intervalo de 10 minutos. Se rechazará cualquier solicitud adicional, POST
o GET
, antes de que se restablezcan los contadores.
Se debe especificar un valor que represente <MessageWeight>
por una variable de flujo y se puede extraer de los encabezados HTTP, los parámetros de búsqueda, una carga útil de la solicitud XML o JSON, o cualquier otra variable de flujo. Por ejemplo, lo configuras en un encabezado llamado weight
:
<MessageWeight ref="message_weight"/>
<UseQuotaConfigInAPIProduct>
Define la configuración de cuota para un producto de API, como las unidades de tiempo, el intervalo y el máximo permitido.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Tipo complejo |
Elemento principal |
<Quota>
|
Elementos secundarios |
<DefaultConfig> |
Si agregas el elemento <UseQuotaConfigInAPIProduct>
a la política de cuotas, Apigee ignora los elementos secundarios <Allow>
, <Interval>
y <TimeUnit>
de la <Quota>
.
El elemento <UseQuotaConfigInAPIProduct>
es solo un contenedor para la configuración predeterminada que defines con el elemento <DefaultConfig>
, como se muestra en el siguiente ejemplo:
<UseQuotaConfigInAPIProduct stepName="POLICY_NAME"> <DefaultConfig>...</DefaultConfig> </UseQuotaConfigInAPIProduct>
Puedes usar el atributo stepName
para hacer referencia a una política VerifyAPIKey o a una operación de política ValidateToken
de la política OAuthv2 en el flujo.
En la siguiente tabla, se describen los atributos de <UseQuotaConfigInAPIProduct>
:
Atributo | Descripción | Predeterminado | Presence |
---|---|---|---|
stepName | Identifica el nombre de la política de autenticación en el flujo. El destino puede ser una política VerifyAPIKey o una política OAuthv2. | N/A | Obligatorio |
Para obtener más información, consulta lo siguiente:
<DefaultConfig>
Contiene valores predeterminados para la cuota de un producto de API. Cuando defines un <DefaultConfig>
, se requieren los tres elementos secundarios.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | Tipo complejo |
Elemento principal |
<UseQuotaConfigInAPIProduct>
|
Elementos secundarios |
<Allow> <Interval> <TimeUnit> |
Es posible definir estos valores en la operación del producto de API (ya sea con la IU o la API de API de Products y en la política de cuotas). Sin embargo, si lo haces, tendrá prioridad la configuración del producto de API y se ignorará la configuración de la política de cuotas.
La sintaxis de este elemento es la que se muestra a continuación:
<UseQuotaConfigInAPIProduct stepName="POLICY_NAME"> <DefaultConfig> <Allow>allow_count</Allow> <Interval>interval</Interval> <TimeUnit>[minute|hour|day|week|month]</TimeUnit> </DefaultConfig> </UseQuotaConfigInAPIProduct>
En el siguiente ejemplo, se especifica una cuota de 10,000 cada semana:
<DefaultConfig> <Allow>10000</Allow> <Interval>1</Interval> <TimeUnit>week</TimeUnit> </DefaultConfig>
Para obtener más información, consulta lo siguiente:
<SharedName>
Identifica esta política de cuotas como compartida. Todas las políticas de cuotas en un proxy de API con el mismo valor <SharedName>
comparten el mismo contador de cuota subyacente. Si este elemento está presente, los elementos <EnforceOnly>
o <CountOnly>
también deben estar presentes.
Para obtener más información y ejemplos, consulta Configura contadores de cuota compartida.
Valor predeterminado | n/a |
¿Es obligatorio? | Opcional |
Tipo | String |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
<CountOnly>
Coloca una política de cuotas con este elemento configurado en true
en un paso condicional en el flujo de respuesta ProxyEndpoint para aumentar el contador de cuota subyacente de manera condicional. Si este elemento está presente, los elementos <SharedName>
y <EnforceOnly>
también deben estar presentes.
Para obtener más información y ejemplos, consulta Configura contadores de cuota compartida.
Valor predeterminado | false |
¿Es obligatorio? | Opcional |
Tipo | Booleano |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
<EnforceOnly>
Coloca una política de cuotas con este elemento configurado como true
en el flujo de solicitud de un proxy de API. Esta configuración permite que los recuentos de cuota se compartan para cualquier política de cuotas en el proxy de API con el mismo valor <SharedName>
. Si este elemento está presente, los elementos <SharedName>
y <CountOnly>
también deben estar presentes.
Para obtener más información y ejemplos, consulta Configura contadores de cuota compartida.
Valor predeterminado | false |
¿Es obligatorio? | Opcional |
Tipo | Booleano |
Elemento principal |
<Quota>
|
Elementos secundarios |
Ninguno |
Variables de flujo
Las siguientes variables de flujo predefinidas se propagan automáticamente cuando se ejecuta una política de cuotas. Para obtener más información, consulta Referencia de variables de flujo.
Variables | Tipo | Permisos | Descripción |
---|---|---|---|
ratelimit.{policy_name}.allowed.count | Largo | Solo lectura | Muestra el recuento de cuotas permitido. |
ratelimit.{policy_name}.used.count | Largo | Solo lectura | Muestra la cuota actual que se usó en un intervalo de cuota. |
ratelimit.{policy_name}.available.count | Largo | Solo lectura | Muestra el recuento de cuotas disponible en el intervalo de cuota. |
ratelimit.{policy_name}.exceed.count | Largo | Solo lectura | Muestra 1 después de que se excede la cuota. |
ratelimit.{policy_name}.total.exceed.count | Largo | Solo lectura | Muestra 1 después de que se excede la cuota. |
ratelimit.{policy_name}.expiry.time | Largo | Solo lectura |
Muestra la hora UTC (en milisegundos), que determina cuándo vence la cuota y cuándo comienza el intervalo de cuota nuevo. Cuando el tipo de política de cuotas es |
ratelimit.{policy_name}.identifier | String | Solo lectura | Muestra la referencia del identificador (cliente) adjunto a la política. |
ratelimit.{policy_name}.class | String | Solo lectura | Muestra la clase asociada con el identificador del cliente. |
ratelimit.{policy_name}.class.allowed.count | Largo | Solo lectura | Muestra el recuento de cuotas permitido en la clase |
ratelimit.{policy_name}.class.used.count | Largo | Solo lectura | Muestra la cuota que se usa en una clase. |
ratelimit.{policy_name}.class.available.count | Largo | Solo lectura | Muestra el recuento de cuotas disponible en la clase |
ratelimit.{policy_name}.class.exceed.count | Largo | Solo lectura | Muestra el recuento de solicitudes que exceden el límite en la clase en el intervalo de cuota actual |
ratelimit.{policy_name}.class.total.exceed.count | Largo | Solo lectura | Muestra el recuento total de solicitudes que exceden el límite en la clase en todos los intervalos de cuota, por lo que es la suma de class.exceed.count para todos los intervalos de cuota. |
ratelimit.{policy_name}.failed | Booleano | Solo lectura |
Indica si la política falló (verdadero o falso). |
Referencia de errores
En esta sección, se describen los códigos de falla y los mensajes de error que se muestran, y las variables de falla que establece Apigee cuando esta política activa un error. Esta información es importante para saber si estás desarrollando reglas de fallas con el propósito de manejar fallas. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo solucionar fallas.
Errores de entorno de ejecución
Estos errores pueden producirse cuando se ejecuta la política.
Código de falla | Estado de HTTP | Causa | Corregir |
---|---|---|---|
policies.ratelimit.FailedToResolveQuotaIntervalReference |
500 |
Ocurre si el elemento <Interval> no está definido dentro de la política Quota . Este elemento es obligatorio y se usa para especificar el intervalo de tiempo aplicable a la cuota. El intervalo de tiempo puede ser de minutos, horas, días, semanas o meses, según se defina con el elemento <TimeUnit> . |
build |
policies.ratelimit.FailedToResolveQuotaIntervalTimeUnitReference |
500 |
Ocurre si el elemento <TimeUnit> no está definido dentro de la política Quota . Este elemento es obligatorio y se usa para especificar la unidad de tiempo aplicable a la cuota. El intervalo de tiempo puede ser en minutos, horas, días, semanas o meses. |
build |
policies.ratelimit.InvalidMessageWeight |
500 |
Este error se produce si el valor del elemento <MessageWeight> que se especificó a través de una variable de flujo no es válido (un número que no es entero). |
build |
policies.ratelimit.QuotaViolation |
500 |
Se superó el límite de la cuota. | N/A |
Errores en la implementación
Nombre del error | Causa | Corregir |
---|---|---|
InvalidQuotaInterval |
Si el intervalo de cuota especificado en el elemento <Interval> no es un número entero, fallará la implementación del proxy de la API. Por ejemplo, si el intervalo de cuota especificado es 0.1 en el elemento <Interval> , fallará la implementación del proxy de API.
|
build |
InvalidQuotaTimeUnit |
Si la unidad de tiempo especificada en el elemento <TimeUnit> no es compatible, fallará la implementación del proxy de API. Las unidades de tiempo admitidas son minute , hour , day , week y month .
|
build |
InvalidQuotaType |
Si el tipo de cuota especificado por el atributo type en el elemento <Quota> no es válido, fallará la implementación del proxy de la API. Los tipos de cuota admitidos son default , calendar , flexi y rollingwindow .
|
build |
InvalidStartTime |
Si el formato del tiempo especificado en el elemento <StartTime> no es válido, fallará la implementación del proxy de la API. El formato válido es yyyy-MM-dd HH:mm:ss , que es el formato de fecha y hora ISO 8601. Por ejemplo, si la hora especificada en el elemento <StartTime> es 7-16-2017 12:00:00 , fallará la implementación del proxy de API.
|
build |
StartTimeNotSupported |
Si se especifica el elemento <StartTime> cuyo tipo de cuota no es calendar , fallará la implementación del proxy de API. El elemento <StartTime> solo es compatible con el tipo de cuota calendar . Por ejemplo, si el atributo type se establece en flexi o rolling window en el elemento <Quota> , fallará la implementación del proxy de la API.
|
build |
InvalidTimeUnitForDistributedQuota |
Si el elemento <Distributed> se configura como true y el elemento <TimeUnit> se configura como second , fallará la implementación del proxy de la API. La unidad de tiempo second no es válida para una cuota distribuida. |
build |
InvalidSynchronizeIntervalForAsyncConfiguration |
Si el valor especificado para el elemento <SyncIntervalInSeconds> dentro del elemento <AsynchronousConfiguration> en una política de Quota es inferior a cero, fallará la implementación del proxy de la API. |
build |
InvalidAsynchronizeConfigurationForSynchronousQuota |
Si el valor del elemento <AsynchronousConfiguration> se establece en true en una política Quota , que también tiene una configuración asíncrona definida con el elemento <AsynchronousConfiguration> , la implementación del proxy de la API falla. |
build |
Variables con fallas
Estas variables se establecen cuando esta política activa un error. Para obtener más información, consulta Qué debes saber sobre los errores de la política.
Variables | Donde | Ejemplo |
---|---|---|
fault.name="fault_name" |
fault_name es el nombre de la falla, como se indica en la tabla de Errores del entorno de ejecución anterior. El nombre de la falla es la última parte del código de la falla. | fault.name Matches "QuotaViolation" |
ratelimit.policy_name.failed |
policy_name es el nombre especificado por el usuario de la política que generó la falla. | ratelimit.QT-QuotaPolicy.failed = true |
Ejemplo de respuesta de error
{ "fault":{ "detail":{ "errorcode":"policies.ratelimit.QuotaViolation" }, "faultstring":"Rate limit quota violation. Quota limit exceeded. Identifier : _default" } }
Ejemplo de regla de falla
<FaultRules> <FaultRule name="Quota Errors"> <Step> <Name>JavaScript-1</Name> <Condition>(fault.name Matches "QuotaViolation") </Condition> </Step> <Condition>ratelimit.Quota-1.failed=true</Condition> </FaultRule> </FaultRules>
Esquemas
Temas relacionados
Comparar políticas de cuota y de Spike Arrest