Правила SpikeArrest

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

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

Элемент <SpikeArrest>

Определяет правило 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>

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

Примеры

Ниже приведены примеры использования правила "Защита от скачков".

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

Используйте этот атрибут в дополнение к атрибуту name, чтобы присвоить правилу в редакторе прокси-сервера интерфейса управления другое, более понятное название.

Элемент <DisplayName> используется во всех правилах.

Элемент <DisplayName> имеет следующий синтаксис:

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

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

У элемента <DisplayName> нет атрибутов или дочерних элементов.

<Identifier>

Позволяет выбрать способ группировки запросов, чтобы правило 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: Quota Identifier Across Different Policies.

<MessageWeight>

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

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

Например, если значение параметра Spike Arrest <Rate> равно 10pm, а приложение отправляет запросы с весом 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>

Распределяет количество срабатываний функции Spike Arrest между процессорами сообщений при использовании групп с автомасштабированием.

<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> необязателен. Если элемент отсутствует в правиле Spike Arrest, по умолчанию используется значение false.

В таблице ниже описаны атрибуты элемента <UseEffectiveCount>.

Действие переменной <UseEffectiveCount> зависит от ее значения:

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

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

Например, если вы введете значение 30pm (30 запросов в минуту), При тестировании вы можете подумать, что можно отправить 30 запросов за одну секунду, если они приходят в течение минуты. Однако правила применяются не так. Если подумать, 30 запросов за одну секунду в некоторых случаях можно считать мини-пиком.

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

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

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

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

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

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

Переменные процесса

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

Дополнительную информацию можно найти в справочнике по переменным потока.

Справочник по ошибкам

В этом разделе описаны коды ошибок и сообщения об ошибках, которые возвращаются, а также переменные ошибок, которые задаются Edge, когда это правило вызывает ошибку. Эта информация важна, если вы разрабатываете правила обработки ошибок. Подробнее о том, что нужно знать об ошибках в правилах и как устранять неполадки…

Ошибки времени выполнения

Эти ошибки могут возникать при выполнении правил.

Ошибки развертывания

Эти ошибки могут возникать при развертывании прокси-сервера, содержащего это правило.

Переменные ошибок

Эти переменные задаются при возникновении ошибки выполнения. Подробнее о нарушениях правил…

Пример ответа об ошибке

Ниже приведен пример ответа с ошибкой:

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

Пример правила обработки ошибок

Ниже приведен пример правила обработки ошибок для ошибки 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>

Текущий код статуса 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.

Статьи по теме

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