Kontingentrichtlinie

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Was

Mit der Kontingentrichtlinie können Sie die Anzahl der Anfragenachrichten konfigurieren, die ein API-Proxy in einem bestimmten Zeitraum zulässt, z. B. in einer Minute, einer Stunde, einem Tag, einer Woche oder einem Monat. Sie können festlegen, dass das Kontingent für alle Anwendungen, die auf den API-Proxy zugreifen, gleich ist, oder Sie können die Kontingente auf folgenden Grundlagen festlegen:

• Das Produkt, das den API-Proxy enthält
• Die Anwendung, die die Anfrage an die API sendet
• Der Entwickler der Anwendung
• Viele weitere Kriterien

Verwenden Sie das Kontingent nicht, um allgemeine Trafficspitzen zu verhindern. Dazu verwenden Sie die SpikeArrest-Richtlinie. Siehe Spike Arrest .

Videos

In diesen Videos wird die Kontingentverwaltung per Kontingentrichtlinie vorgestellt:

Beispiele

Diese Codebeispiele für Richtlinien zeigen, wie Sie das Start- und Enddatum für Kontingente festlegen:

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

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

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<AssignMessage async="false" 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>

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/> 
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

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

Informationen zur Kontingentrichtlinie

Ein Kontingent gibt die Anzahl der Anfragenachrichten an, die ein API-Proxy über einen bestimmten Zeitraum verarbeiten kann, z. B. Minute, Stunde, Tag, Woche oder Monat. Die Richtlinie verwaltet Zähler, in denen die Anzahl der Anfragen erfasst wird, die vom API-Proxy empfangen werden. Mit dieser Funktion können API-Anbieter Limits für die Anzahl von API-Aufrufen festlegen, die von Apps über einen bestimmten Zeitraum ausgeführt werden. Mit Kontingentrichtlinien können Sie beispielsweise Anwendungen auf eine Anfrage pro Minute oder 10.000 Anfragen pro Monat beschränken.

Wenn als Kontingent beispielsweise 10.000 Nachrichten pro Monat definiert sind, beginnt die Ratenbegrenzung nach der 10.000. Nachricht. Dabei spielt es keine Rolle, ob am ersten oder am letzten Tag dieses Zeitraums 10.000 Nachrichten gezählt wurden. Es sind keine weiteren Anfragen zugelassen, bis der Kontingentzähler am Ende des angegebenen Zeitintervalls automatisch zurückgesetzt wird oder bis das Kontingent mithilfe der Richtlinie zum Zurücksetzen von Kontingenten explizit zurückgesetzt wird.

Eine Variante des Kontingents namens SpikeArrest verhindert Trafficspitzen (oder Bursts), die durch einen plötzlichen Nutzungsanstieg, einen fehlerhaften Client oder bösartige Angriffe verursacht werden können. Weitere Informationen zu SpikeArrest finden Sie unter Spike Arrest-Richtlinie.

Kontingente gelten für einzelne API-Proxys und werden nicht unter API-Proxys aufgeteilt. Beispiel: Wenn Sie drei API-Proxys in einem API-Produkt haben, wird ein Kontingent nicht für alle drei genutzt, auch wenn alle drei die gleiche Kontingentrichtlinie-Konfiguration verwenden.

Typen von Kontingentrichtlinien

Die Kontingentrichtlinie unterstützt verschiedene Typen von Richtlinien: Standard, calendar, flexi und rollingwindow. Für jeden Typ ist definiert, wann der Kontingentzähler gestartet und zurückgesetzt wird, wie in der folgenden Tabelle dargestellt:

Für type="calendar" müssen Sie den Wert von <StartTime> angeben.

In der Tabelle ist der Wert für den Typ rollingwindow nicht aufgeführt. Die rollierenden Fensterkontingente werden durch Festlegen der Größe eines Kontingentfensters, z. B. eine Stunde oder ein Zeitfenster, festgelegt. Wenn eine neue Anfrage eingeht, bestimmt die Richtlinie, ob das Kontingent in der Vergangenheit überschritten wurde.

Sie definieren zum Beispiel ein zweistündiges Zeitfenster, in dem 1.000 Anfragen zugelassen werden. Um 16:45 Uhr geht eine neue Anfrage ein. Die Richtlinie berechnet den Kontingentzähler für das letzte Fenster von zwei Stunden, d. h. die Anzahl der Anfragen seit 14:45 Uhr. Wenn das Kontingentlimit in diesem zweistündigen Zeitraum nicht überschritten wurde, wird die Anfrage zugelassen.

Eine Minute später, um 16:46 Uhr, geht eine weitere Anfrage ein. Jetzt berechnet die Richtlinie den Kontingentzähler seit 14:46 Uhr, um zu ermitteln, ob das Limit überschritten wurde.

Beim Typ rollingwindow wird der Zähler nie zurückgesetzt, sondern bei jeder Anfrage neu berechnet.

Informationen zu Kontingentzählern

Standardmäßig gilt für eine Kontingentrichtlinie ein einzelner Zähler, unabhängig davon, wie oft Sie in einem API-Proxy darauf verweisen. Der Name des Kontingentzählers basiert auf dem Attribut name der Richtlinie.

Sie erstellen beispielsweise eine Kontingentrichtlinie namens MyQuotaPolicy mit einem Limit von fünf Anfragen und platzieren diese in mehreren Abläufen (A, B und C) im API-Proxy. Auch wenn der Zähler in mehreren Abläufen verwendet wird, bleibt er ein einzelner Zähler, der von allen Instanzen der Richtlinie aktualisiert wird:

• Ablauf A wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 1.
• Ablauf B wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 2.
• Ablauf A wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 3.
• Ablauf C wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 4.
• Ablauf A wird ausgeführt -> MyQuotaPolicy wird ausgeführt und der Zähler = 5.

Die nächste Anfrage an einen der drei Abläufe wird abgelehnt, da der Kontingentzähler sein Limit erreicht hat.

Die Verwendung derselben Kontingentrichtlinie an mehreren Stellen in einem API-Proxy-Ablauf, wodurch das Kontingent ungewollt schneller als erwartet erschöpft, ist ein Anti-Muster, das in The Book of Apigee Edge Antipatterns

Alternativ können Sie mehrere Kontingentrichtlinien in Ihrem API-Proxy definieren und in jedem Ablauf eine andere Richtlinie verwenden. Jede Kontingentrichtlinie nutzt dann einen eigenen Zähler, gemäß dem Attribut name der Richtlinie.

Alternativ können Sie das Element <Class> oder <Identifier> in der Kontingentrichtlinie verwenden, um mehrere eindeutige Zähler in einer einzelnen Richtlinie zu definieren. Wenn Sie diese Elemente verwenden, kann eine einzelne Richtlinie verschiedene Zähler verwalten – auf Grundlage der Anwendung, die die Anfrage stellt, des App-Entwicklers, der die Anfrage stellt, einer Client-ID, einer Client-Kennzeichnung und so weiter. Weitere Informationen zur Verwendung der Elemente <Class> und <Identifier> finden Sie in den obigen Beispielen.

Zeitnotation

Alle Kontingentzeiten sind auf die koordinierte Weltzeit (UTC) eingestellt.

Die Notation der Kontingentzeit entspricht der internationalen Standardnotation, die im internationalen Standard ISO 8601 definiert ist.

Datumsangaben sind als Jahr, Monat und Tag im folgenden Format definiert: YYYY-MM-DD. Beispielsweise steht 2015-02-04 für den 4. Februar 2015.

Die Tageszeit wird im folgenden Format als Stunden, Minuten und Sekunden angegeben: hours:minutes:seconds. Beispielsweise steht 23:59:59 für die Uhrzeit um eine Sekunde vor Mitternacht.

Beachten Sie, dass es zwei Notationen gibt, nämlich 00:00:00 und 24:00:00, um zwischen den beiden Uhrzeiten um Mitternacht zu unterscheiden, die einem Datum zugeordnet werden können. Daher ist 2015-02-04 24:00:00 dasselbe Datum und dieselbe Uhrzeit wie 2015-02-05 00:00:00. Letzteres ist normalerweise die bevorzugte Notation.

Kontingenteinstellungen aus der API-Produktkonfiguration abrufen

Sie können Kontingentlimits in API-Produktkonfigurationen festlegen. Diese Limits erzwingen nicht automatisch ein Kontingent. Stattdessen können Sie in einer Kontingentrichtlinie auf die Einstellungen für das Produktkontingent verweisen. Beim Festlegen eines Kontingents für das Produkt haben Sie folgende Vorteile:

• Bei Kontingentrichtlinien kann eine einheitliche Einstellung für alle API-Proxys im API-Produkt verwendet werden.
• Sie können Laufzeitänderungen an der Kontingenteinstellung eines API-Produkts vornehmen. Außerdem haben Kontingentrichtlinien, die auf den Wert verweisen, automatisch aktualisierte Kontingentwerte.

Weitere Informationen zur Verwendung der Kontingenteinstellungen aus einem API-Produkt finden Sie im obigen Beispiel "Dynamisches Kontingent".

Informationen zum Konfigurieren von API-Produkten mit Kontingentlimits finden Sie unter API-Produkte erstellen.

Elementverweis

Die folgenden Elemente und Attribute können Sie für diese Richtlinie konfigurieren: Beachten Sie, dass einige Elementkombinationen sich gegenseitig ausschließen oder nicht erforderlich sind. Unter den jeweiligen Beispielen werden konkrete Anwendungsfälle gezeigt. Die unten aufgeführten verifyapikey.VerifyAPIKey.apiproduct.*-Variablen sind standardmäßig verfügbar, wenn eine API-Schlüsselrichtlinie "VerifyAPIKey" verwendet wird, um den API-Schlüssel der Anwendung in der Anfrage zu prüfen. Die Variablenwerte stammen aus den Kontingenteinstellungen des API-Produkts, dem der Schlüssel zugeordnet ist, wie unter Kontingenteinstellungen der API-Produktkonfiguration abrufen beschrieben.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <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.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval> 
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime> 
   <Distributed>false</Distributed> 
   <Synchronous>false</Synchronous> 
   <AsynchronousConfiguration> 
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds> 
      <SyncMessageCount>5</SyncMessageCount> 
   </AsynchronousConfiguration> 
   <Identifier/> 
   <MessageWeight/> 
</Quota>

<Quota>-Attribute

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

Die folgenden Attribute sind spezifisch für diese Richtlinie.

In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:

<DisplayName>-Element

Wird zusätzlich zum Attribut name verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<DisplayName>Policy Display Name</DisplayName>

<Allow>-Element

Gibt das numerische Limit für das Kontingent an. Wenn der Zähler für die Richtlinie dieses Limit erreicht, werden nachfolgende Aufrufe abgelehnt, bis der Zähler zurückgesetzt wird.

Hier sehen Sie drei Möglichkeiten zum Festlegen des Elements <Allow>:

<Allow count="2000"/> 

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

Wenn Sie sowohl count als auch countRef angeben, erhält countRef die Priorität. Wenn countRef zur Laufzeit nicht aufgelöst wird, wird der Wert von count verwendet.

Attribute

<Allow>/<Class>-Element

Mit dem Element <Class> können Sie den Wert des Elements <Allow> basierend auf dem Wert einer Flussvariablen an Bedingungen knüpfen. Für jedes unterschiedliche untergeordnete <Allow>-Tag von <Class> verwaltet die Richtlinie einen anderen Zähler.

Wenn Sie das <Class>-Element verwenden möchten, geben Sie eine Ablaufvariable mithilfe des Attributs ref für das Tag <Class> an. Edge verwendet dann den Wert des können Sie eines der <Allow> untergeordneten Tags auswählen, um die zulässige Anzahl der Richtlinie. Edge entspricht dem Wert der Flussvariablen mit class des <Allow>-Tags wie unten gezeigt:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

In diesem Beispiel wird der aktuelle Kontingentzähler durch den Wert des an Ihrer Anfrage übergebenen Abfrageparameters time_variable bestimmt. Diese Variable kann den Wert peak_time oder off_peak_time haben. Wenn der Abfrageparameter einen ungültigen Wert enthält, gibt die Richtlinie einen Fehler wegen Kontingentverletzung zurück.

Attribute

<Allow>/<Class>/<Allow>-Element

Das Element <Allow> gibt das Limit für einen Kontingentzähler an, der durch das Element <Class> definiert ist. Für jedes unterschiedliche untergeordnete <Allow>-Tag von <Class> verwaltet die Richtlinie einen anderen Zähler.

Beispiel:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

In diesem Beispiel pflegt die Kontingentrichtlinie zwei Kontingentzähler mit dem Namen von peak_time und off_peak_time.

Attribute

<Interval>-Element

Wird zur Angabe einer Ganzzahl verwendet (z. B. 1, 2, 5, 60 usw.), die mit der von Ihnen angegebenen TimeUnit gekoppelt wird (Minute, Stunde, Tag, Woche oder Monat), um einen Zeitraum zu bestimmen, in dem Edge die Kontingentnutzung berechnet.

Ein Interval von 24 mit einer TimeUnit von hour bedeutet, dass das Kontingent über einen Zeitraum von 24 Stunden berechnet wird.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

Attribute

<TimeUnit>-Element

Dient zum Angeben der Zeiteinheit für das Kontingent.

Ein Interval von 24 mit einer TimeUnit von hour bedeutet, dass das Kontingent über einen Zeitraum von 24 Stunden berechnet wird.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

Attribute

<StartTime>-Element

Wenn type auf calendar, gesetzt ist, werden hiermit Datum und Uhrzeit für den Start des Kontingentzählers angegeben, unabhängig davon, ob Anfragen von Anwendungen empfangen wurden.

Sie müssen ein explizites StartTime angeben, wenn type explizit auf calendar, festgelegt ist. Sie können keinen Verweis auf eine Flussvariable verwenden. Wenn Sie einen StartTime-Wert angeben und kein type-Wert festgelegt ist, erhalten Sie eine Fehlermeldung.

Beispiel:

<StartTime>2017-7-16 12:00:00</StartTime>

<Distributed>-Element

Eine Installation von Edge kann einen oder mehrere Message Processors zur Verarbeitung von Anfragen verwenden. Setzen Sie dieses Element auf true, um anzugeben, dass die Richtlinie einen zentralen Zähler verwalten soll und dieser kontinuierlich auf allen Message Processors synchronisiert wird. Die Message Processors können sich in verschiedenen Verfügbarkeitszonen und/oder Regionen befinden.

Wenn Sie den Standardwert false verwenden, kann Ihr Kontingent überschritten werden, da die Zahl für jeden Message Processor nicht gemeinsam genutzt wird:

<Distributed>true</Distributed>

Um dafür zu sorgen, dass die Zähler bei jeder Anfrage synchronisiert und aktualisiert werden, legen Sie <Distributed> und <Synchronous> auf „true“ fest:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

<Synchronous>-Element

Legen Sie true fest, um einen verteilten Kontingentzähler synchron zu aktualisieren. Dieses Das bedeutet, dass die Aktualisierung des Zählers zur selben Zeit erfolgt, zu der das Kontingent bei einer Anfrage geprüft wird an die API senden. Setzen Sie den Wert auf true, wenn Sie keine API-Aufrufe über das Kontingent zulassen möchten.

Setzen Sie den Wert auf false, um den Kontingentzähler asynchron zu aktualisieren. Dies bedeutet, dass einige API-Aufrufe trotz Überschreitung des Kontingents möglicherweise ausgeführt werden. Dies hängt davon ab, wann der Kontingentzähler im zentralen Repository asynchron aktualisiert wird. Es bestehen jedoch keine Auswirkungen auf die Leistung wie bei einer synchronen Aktualisierung.

Bei asynchroner Aktualisierung beträgt das Standardaktualisierungsintervall 10 Sekunden. Verwenden Sie das Element AsynchronousConfiguration, um dieses asynchrone Verhalten zu konfigurieren.

<Synchronous>false</Synchronous>

<AsynchronousConfiguration>-Element

Konfiguriert das Synchronisierungsintervall zwischen verteilten Kontingentzählern, wenn das Richtlinienkonfigurationselement <Synchronous> nicht vorhanden ist oder vorhanden und auf false festgelegt ist.

Sie können nach einem Zeitraum oder einer Nachrichtenzahl synchronisieren und dabei eines der untergeordneten Elemente SyncIntervalInSeconds oder SyncMessageCount verwenden. Diese schließen sich gegenseitig aus. Beispiel:

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

oder

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

<AsynchronousConfiguration>/<SyncIntervalInSeconds>-Element

Verwenden Sie dieses Element, um das Standardverhalten zu überschreiben, bei dem asynchrone Aktualisierungen nach einem Intervall von 10 Sekunden ausgeführt werden.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

Das Synchronisierungsintervall muss mindestens 10 Sekunden lang sein, wie im Thema Limits beschrieben.

<AsynchronousConfiguration>/<SyncMessageCount>-Element

Gibt die Anzahl der Anfragen bei allen Message Processors von Apigee zwischen Kontingentaktualisierungen an.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

In diesem Beispiel wird angegeben, dass die Kontingentanzahl nach jeweils 5 Anfragen bei allen Message Processors von Apigee Edge aktualisiert wird.

<Identifier>-Element

Verwenden Sie das Element <Identifier>, um die Richtlinie so zu konfigurieren, dass gemäß einer Ablaufvariable eindeutige Zähler erstellt werden.

Wenn Sie dieses Element nicht verwenden, verwendet die Richtlinie einen einzelnen Zähler, der auf das Kontingent angewendet wird.

Dieses Element wird auch im folgenden Apigee-Communitybeitrag besprochen: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<Identifier ref="verifyapikey.verify-api-key.client_id"/>

Attribute

<MessageWeight>-Element

Verwenden Sie diese Option, um die pro Nachricht zugewiesene Gewichtung anzugeben. Verwenden Sie die Nachrichtengewichtung, um die Wirkung von Anfragenachrichten zu erhöhen, beispielsweise von solchen, die mehr Rechenleistung verbrauchen als andere.

Beispiel: Sie möchten, dass POST-Nachrichten doppelt so hoch sind wie "schwer". oder teuer sein, wie GET Nachrichten. Daher setzen Sie MessageWeight für POST-Anfragen auf 2 und GET. Sie können sogar MessageWeight auf 0 setzen, damit die Anfrage nicht auf den Zähler auswirken. Wenn das Kontingent in diesem Beispiel bei 10 Nachrichten pro Minute liegt und MessageWeight für POST-Anfragen 2 beträgt, dann wird das Kontingent gestattet 5 POST-Anforderungen in einem beliebigen Intervall von 10 Minuten. Jede zusätzliche Anfrage, POST oder GET, bevor die Zählerzurücksetzungen abgelehnt werden.

Ein Wert, der MessageWeight darstellt, muss durch eine Flussvariable angegeben werden und kann aus HTTP-Headern, Abfrageparametern, einer XML- oder JSON-Anfragenutzlast oder einer anderen Flussvariablen extrahiert werden. Legen Sie sie beispielsweise in einem Header mit dem Namen weight fest:

<MessageWeight ref="message_weight"/>

Ablaufvariablen

Die folgenden vordefinierten Flussvariablen beim Ausführen einer Kontingentrichtlinie automatisch ausgefüllt. Weitere Informationen zu Ablaufvariablen finden Sie in der Variablenreferenz.

Fehlerreferenz

Dieser Abschnitt beschreibt die Fehlercodes und Fehlermeldungen, die zurückgegeben werden, und die Fehlervariablen, die von Edge festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Bereitstellungsfehler

Fehlervariablen

Diese Variablen werden festgelegt, wenn die Richtlinie einen Fehler auslöst. Weitere Informationen finden sich unter Was Sie über Richtlinienfehler wissen müssen.

Beispiel für eine Fehlerantwort

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Beispiel für eine Fehlerregel

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

Schemas

Weitere Informationen

ResetQuota-Richtlinie

SpikeArrest Richtlinie

Richtlinien für Kontingente, Spike Arrest und die gleichzeitige Ratenbegrenzung vergleichen