Политика SpikeArrest

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

Политика защиты от всплесков трафика (Spike Arrest) защищает от резких скачков трафика с помощью элемента <Rate> . Этот элемент ограничивает количество запросов, обрабатываемых API-прокси и отправляемых на бэкэнд, предотвращая задержки в работе и простои.

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

Этот элемент имеет следующие атрибуты, общие для всех политик:

Примеры

Следующие примеры демонстрируют некоторые способы применения политики «Задержание за нарушение правил дорожного движения»:

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

ссылка на дочерний элемент

В этом разделе описываются дочерние элементы <SpikeArrest> .

<DisplayName>

Use in addition to the name attribute to label the policy in the management UI proxy editor with a different, more natural-sounding name.

The <DisplayName> element is common to all policies.

The <DisplayName> element uses the following syntax:

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

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

The <DisplayName> element has no attributes or child elements.

<Identifier>

Позволяет выбрать способ группировки запросов, чтобы политика Spike Arrest применялась в зависимости от клиента. Например, вы можете сгруппировать запросы по идентификатору разработчика, в этом случае запросы каждого разработчика будут учитываться в его собственном коэффициенте Spike Arrest, а не все запросы к прокси.

Используйте в сочетании с элементом <MessageWeight> для более точного контроля над ограничением количества запросов.

Если оставить элемент <Identifier> пустым, для всех запросов к этому 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>

В следующей таблице описаны атрибуты <Identifier> >:

Этот элемент также обсуждается в следующем сообщении сообщества Apigee: Идентификатор квоты в рамках различных политик .

<MessageWeight>

Задает вес, определенный для каждого сообщения. Вес сообщения изменяет влияние отдельного запроса на расчет коэффициента предотвращения всплесков активности. Вес сообщения может быть любой переменной потока, такой как заголовок HTTP, параметр запроса, параметр формы или содержимое тела сообщения. Вы также можете использовать пользовательские переменные с помощью политики JavaScript или политики AssignMessage .

Используйте совместно с <Identifier> для дальнейшего ограничения количества запросов от конкретных клиентов или приложений.

Например, если пороговое значение Spike Arrest <Rate> равно 10pm , и приложение отправляет запросы с весом 2 , то от этого клиента разрешено отправлять только пять сообщений в минуту, поскольку каждый запрос засчитывается как 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>

В следующей таблице описаны атрибуты <MessageWeight> :

<Rate>

Этот элемент задает частоту ограничения пиковых нагрузок (или всплесков) трафика, устанавливая количество разрешенных запросов в минуту или в секунду. Вы также можете использовать этот элемент совместно с <Identifier> и <MessageWeight> для плавного регулирования трафика во время выполнения, принимая значения от клиента.

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

В следующей таблице описаны атрибуты <Rate> :

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

<UseEffectiveCount>

Распределяет количество остановок всплесков активности между обработчиками сообщений (MP) при использовании групп автоматического масштабирования.

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

Элемент <UseEffectiveCount> является необязательным. Если этот элемент отсутствует в вашей политике предотвращения резкого увеличения количества нарушений, значение по умолчанию будет false

В следующей таблице описаны атрибуты элемента <UseEffectiveCount> :

Эффект параметра <UseEffectiveCount> зависит от его значения:

• true : Предел частоты скачков активности MP равен <Rate> , деленному на текущее количество MP в одном и том же модуле. Совокупный лимит равен значению <Rate> . При динамическом добавлении (или удалении) MP их индивидуальные пределы частоты скачков активности будут увеличиваться (или уменьшаться), но совокупный лимит останется неизменным.
• false : Предел частоты скачков для каждого MP — это просто значение его <Rate> . Совокупный лимит — это сумма скоростей всех MP. При добавлении (или удалении) MP их индивидуальные пределы частоты скачков остаются неизменными, но совокупный лимит увеличивается (или уменьшается).

Политика SpikeArrest использует алгоритм « токенового ведра », который сглаживает всплески трафика, разделяя указанный вами лимит скорости на более мелкие интервалы. Недостатком этого подхода является то, что множество легитимных запросов, поступающих в течение короткого промежутка времени, могут быть отклонены.

Например, предположим, вы задали частоту 30 запросов в минуту (30 запросов в минуту). В ходе тестирования вы можете подумать, что сможете отправить 30 запросов за 1 секунду, если они поступят в течение минуты. Но политика не обеспечивает соблюдение этого параметра. Если подумать, 30 запросов за 1 секунду в некоторых средах могут считаться небольшим всплеском.

• Поминутные тарифы сглаживаются, и все запросы разрешаются с интервалом в несколько секунд .
  

  Например, время 30 вечера сглаживается следующим образом:
  60 секунд (1 минута) / 30 вечера = 2-секундные интервалы, или 1 запрос разрешен каждые 2 секунды. Второй запрос в течение 2 секунд будет отклонен. Также 31-й запрос в течение минуты будет отклонен.

• Посекундные запросы сглаживаются и преобразуются в полные запросы, разрешенные с интервалами в миллисекунды .

  Например, значение 10 пс сглаживается следующим образом:
  1000 миллисекунд (1 секунда) / 10 пс = 100-миллисекундные интервалы, или 1 запрос разрешен каждые 100 миллисекунд. Второй запрос в течение 100 мс завершится неудачей. Также 11-й запрос в течение секунды завершится неудачей.

В следующей таблице показано влияние параметра <UseEffectiveCount> на эффективный лимит скорости каждого MP:

В этом примере обратите внимание, что когда количество MP уменьшается с 4 до 2, и <UseEffectiveCount> равно false , эффективная ставка на MP остается неизменной (10). Но когда <UseEffectiveCount> равно true , эффективная ставка на MP увеличивается с 10 до 20 при уменьшении количества MP с 4 до 2.

Переменные потока

При выполнении политики Spike Arrest заполняется следующая переменная потока:

Для получения более подробной информации см. справочник по переменным потока .

Ссылка на ошибку

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>

Текущий код состояния HTTP, указывающий на превышение лимита запросов, установленного политикой квотирования или предотвращения всплесков активности, — 429 (Слишком много запросов). Чтобы изменить код состояния HTTP на 500 (Внутренняя ошибка сервера), установите свойство features.isHTTPStatusTooManyRequestEnabled в значение false , используя API обновления свойств организации .

Например:

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

Схемы

Каждый тип политики определяется XML-схемой ( .xsd ). Для справки, схемы политик доступны на GitHub.

Связанные темы

• Политика квот : Политика квот, ограничивающая трафик на отдельных клиентах.
• Ограничение скорости для обзора ограничений скорости
• Сравнение политики квотирования и политики предотвращения резкого увеличения количества сообщений о нарушениях.
• Рабочие примеры API-прокси