מדיניות מכסה

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

מה

משתמשים במדיניות Quota כדי להגדיר את מספר הודעות הבקשה ששרת proxy ל-API מאפשר לעבור פרק זמן, כמו דקה, שעה, יום, שבוע או חודש. אפשר להגדיר שהמכסה תהיה זהה לכל האפליקציות שיש להן גישה לשרת ה-proxy ל-API. לחלופין, אפשר להגדיר את המכסה לפי:

• המוצר שמכיל את ה-Proxy ל-API
• האפליקציה שמבקשת את ה-API
• מפתח האפליקציה
• קריטריונים רבים נוספים

אל תשתמשו במכסה כדי להגן מפני עליות חדות בנפח התנועה הכולל. לשם כך, צריך להשתמש ב-Spke Arrest. המדיניות בנושא ראו מעצר ספייק .

סרטונים

בסרטונים הבאים מוצגת אפשרות לניהול המכסות באמצעות מדיניות המכסות:

דוגמאות

הדוגמאות הבאות של קוד מדיניות ממחישות איך להתחיל ולסיים תקופות של מכסות על ידי:

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

מידע על המדיניות בנושא מכסות

מכסה היא הקצאה של הודעות בקשה ששרת proxy ל-API יכול לטפל בהן לאורך תקופה, כמו דקה, שעה, יום, שבוע או חודש. במדיניות יש ספירות שסופרות את מספר בקשות שהתקבלו דרך שרת ה-proxy של ה-API. היכולת הזו מאפשרת לספקי API לאכוף מגבלות על מספר הקריאות ל-API שבוצעו על ידי אפליקציות בפרק זמן מסוים. באמצעות מדיניות מכסות תוכלו, לדוגמה, אפשר להגביל אפליקציות לבקשה אחת בדקה או ל-10,000 בקשות בחודש.

לדוגמה, אם מכסה מוגדרת ל-10,000 הודעות בחודש, הגבלת הקצב של יצירת הבקשות תתחיל אחרי בהודעה ה-10,000. לא משנה אם 10,000 הודעות נספרו כבר ביום האחרון של התקופה הזו או ביום האחרון של התקופה הזו. לא תתאפשר אזור של בקשות נוספות עד למונה המכסות מתאפס אוטומטית בסוף מרווח הזמן שצוין, או עד שהמכסה איפוס באמצעות איפוס המכסה .

שינוי במכסה בשם SpikeArrest מונעת עליות חדות (או תקריות) של תנועת הגולשים שיכולות נגרמה כתוצאה מעלייה פתאומית בשימוש, מבאגים בלקוחות או מהתקפות זדוניות. לקבלת מידע נוסף מידע על SpikeArrest זמין במדיניות של Spike Arrest.

המכסות חלות על שרתי proxy ל-API ספציפיים ולא מחולקות בין שרתי proxy ל-API. לדוגמה, אם במוצר API יש שלושה שרתי proxy ל-API, מכסה אחת לא משותפת לכל השלושה גם אם כל השלוש משתמשות באותה הגדרה של מדיניות המכסה.

סוגי המדיניות בנושא מכסות

במדיניות המכסה יש תמיכה בכמה סוגים שונים של כללי מדיניות: ברירת המחדל, calendar, flexi ו-rollingwindow. כל סוג מגדיר מתי מונה המכסה כשהערך מתחיל ומתי הוא מתאפס, כפי שמוצג בטבלה הבאה:

עבור type="calendar", עליך לציין את הערך של <StartTime>.

בטבלה לא מופיע הערך של הסוג rollingwindow. חלון מתגלגל מכסות פועלות על ידי הגדרת הגודל של 'חלון' של מכסה, למשל חלון של שעה או יום אחד. כאשר מתקבלת בקשה חדשה, המדיניות קובעת אם חרגת מהמכסה בעבר 'window' הזמן.

לדוגמה, תוכלו להגדיר חלון של שעתיים שבו אפשר לכלול 1,000 בקשות. בקשה חדשה נכנסת בשעה 16:45.המדיניות מחשבת את מספר המכסות בחלון של השעתיים האחרונות, כלומר, מספר הבקשות מאז 14:45. אם לא תחרגו ממגבלת המכסה החלון של שעתיים, ואז הבקשה מורשית.

דקה לאחר מכן, בשעה 16:46, נכנסת בקשה נוספת. עכשיו המדיניות מחשבת את וספירת מכסות מאז 14:46 כדי לקבוע אם הייתה חריגה מהמגבלה.

בסוג rollingwindow, המונה אף פעם לא מתאפס, אבל מחושב מחדש בכל בקשה.

הסבר על מוני המכסות

כברירת מחדל, במדיניות מכסה נשמר מונה אחד, ללא קשר לכמות הפעמים להפנות אליו בשרת proxy ל-API. השם של מונה המכסות מבוסס על המאפיין name של המדיניות.

לדוגמה, יוצרים מדיניות מכסה בשם MyQuotaPolicy ומוגבלת ל-5. ומציבים אותו בתהליכים מרובים (Flow A, B ו-C) בשרת ה-proxy ל-API. למרות שזה משמש במספר תהליכים, יש מונה אחד שמתעדכן בכל המופעים של מדיניות:

• פעולת זרימה א' בוצעה -> MyQuotaPolicy בוצעה והמונה שלו = 1
• תהליך ב' בוצע -> MyQuotaPolicy בוצעה והמונה שלו = 2
• פעולת זרימה א' בוצעה -> MyQuotaPolicy בוצעה והמונה שלו = 3
• תהליך ג' בוצע -> MyQuotaPolicy בוצעה והמונה שלו = 4
• פעולת זרימה א' בוצעה -> MyQuotaPolicy בוצעה והמונה שלו = 5

הבקשה הבאה לכל אחד משלושת התהליכים נדחתה כי הגעתם למונה למגבלה.

שימוש באותה מדיניות מכסה ביותר ממקום אחד בתהליך של שרת proxy ל-API, מה שיכול גורמת בטעות למכסה להיגמר מהר מהצפוי, היא דפוס אנטי-דפוס שמתואר The Book of Apigee Edge Antipatterns.

לחלופין, אפשר להגדיר כמה כללי מדיניות מכסות בשרת ה-proxy ל-API ולהשתמש המדיניות בכל תהליך. לכל מדיניות Quota יש מונה משלה, בהתאם המאפיין name של המדיניות.

לחלופין, השתמשו רכיבים של <Class> או <Identifier> בתוך את מדיניות המכסות להגדרה של ספירות מרובות וייחודיות במדיניות אחת. באמצעות רכיבים שונים, מדיניות אחת יכולה לכלול ספירות שונות בהתאם לאפליקציה שממנה נשלחה הבקשה, מפתח האפליקציה ששלח את הבקשה, מזהה לקוח או מזהה לקוח אחר ועוד. לצפייה לקבלת מידע נוסף על השימוש רכיבי <Class> או <Identifier>.

סימון זמן

כל זמני המכסה מוגדרים לערך זמן אוניברסלי מתואם אזור זמן (UTC).

סימון זמן המכסות תואם לסימון התאריכים לפי תקן בינלאומי, המוגדר בתקן הבינלאומי תקן ISO 8601.

התאריכים מוגדרים כשנה, חודש ויום בפורמט הבא: YYYY-MM-DD. לדוגמה, 2015-02-04 מייצג את 4 בפברואר 2015.

השעה ביום מוגדרת כשעות, דקות ושניות, בפורמט הבא: hours:minutes:seconds לדוגמה, 23:59:59 מייצג את הזמן שנייה לפני חצות.

הערה: שני הסימונים 00:00:00 ו-24:00:00 זמינים עבור להבדיל בין שתי חצות שאפשר לשייך לתאריך אחד. לכן, הערך 2015-02-04 24:00:00 זהה לתאריך ולשעה 2015-02-05 00:00:00. האפשרות השנייה היא בדרך כלל את הסימון המועדף.

קבלת הגדרות מכסה מתצורת המוצר של API

אפשר להגדיר מגבלות מכסה בהגדרות של מוצרי API. המגבלות האלה לא חלות באופן אוטומטי לאכוף מכסה. במקום זאת, אתם יכולים לעיין בהגדרות מכסת המוצרים במדיניות המכסות. הנה כמה דוגמאות היתרונות של הגדרת מכסה במוצר כדי להפנות למדיניות המכסות:

• כללי מדיניות המכסות יכולים להשתמש בהגדרה אחידה בכל שרתי ה-proxy ל-API במוצר ה-API.
• אפשר לבצע שינויים בהגדרת המכסה של מוצר API ובמדיניות המכסות בסביבת זמן הריצה שמפנים לערך הזה, ערכי מכסה מעודכנים באופן אוטומטי.

מידע נוסף על שימוש בהגדרות מכסה של מוצר API זמין בקטע 'מכסה דינמית' לדוגמה שלמעלה..

מידע נוסף על הגדרה של מוצרי API עם מגבלות מכסה זמין במאמר יצירת מוצרי API.

הפניה לרכיב

בהמשך מפורטים רכיבים ומאפיינים שאפשר להגדיר במדיניות הזו. שימו לב שחלק מהרכיבים שילובים הם בלעדיים או לא נדרשים. דוגמאות לשימוש ספציפי. verifyapikey.VerifyAPIKey.apiproduct.* המשתנים שלמטה זמינים כברירת מחדל כאשר מדיניות לאימות מפתח API שנקראת 'VerifyAPIKey' משמש לבדיקת מפתח ה-API של האפליקציה בבקשה. ערכי המשתנים מגיעים מהגדרות המכסה במוצר ה-API שהמפתח משויך אליו עם, כפי שמתואר במאמר קבלת הגדרות מכסה ממוצר ה-API הגדרה אישית.

<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> מאפיינים

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

המאפיינים הבאים הם ספציפיים למדיניות הזו.

בטבלה הבאה מתוארים מאפיינים שמשותפים לכל רכיבי ההורה של המדיניות:

<DisplayName> רכיב

צריך להשתמש בנוסף למאפיין name כדי להוסיף תווית למדיניות עורך proxy של ממשק משתמש לניהול עם שם אחר בשפה טבעית.

<DisplayName>Policy Display Name</DisplayName>

<Allow> רכיב

זו מגבלת הספירה במכסה. אם המונה של המדיניות יגיע למגבלה הזו ערך, הקריאות הבאות נדחות עד שהמונה מתאפס.

למטה מוצגות שלוש דרכים להגדרת הרכיב <Allow>:

<Allow count="2000"/> 

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

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

אם מציינים גם count וגם countRef, אז countRef מקבל את העדיפות. אם countRef לא מפוענח בזמן הריצה, הערך של נעשה שימוש ב-count.

מאפיינים

<Allow>/<Class> רכיב

הרכיב <Class> מאפשר התניה של הערך של הרכיב <Allow> על סמך הערך של משתנה הזרימה. עבור כל תג צאצא שונה מסוג <Allow> של <Class>, במדיניות מוצג מונה שונה.

כדי להשתמש ברכיב <Class>, צריך לציין משתנה זרימה באמצעות ref לתג <Class>. לאחר מכן, Edge משתמש בערך של כדי לבחור אחד מתגי הצאצא של <Allow> כדי לקבוע אילו בספירת המדיניות. Edge תואם את הערך של משתנה הזרימה לערך class של התג <Allow>, כמו שמוצג כאן:

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

בדוגמה הזו, מונה המכסות הנוכחי נקבע לפי הערך של פרמטר של שאילתה אחד (time_variable) מועבר עם כל בקשה. למשתנה הזה יכול להיות ערך של peak_time או off_peak_time. אם פרמטר השאילתה מכיל , המדיניות מחזירה שגיאה של הפרת המכסה.

מאפיינים

<Allow>/<Class>/<Allow> רכיב

הרכיב <Allow> מציין את המגבלה למונה מכסה מוגדר על ידי הרכיב <Class>. בכל פעם תג צאצא <Allow> שונה של <Class>, כוללת מונה שונה.

לדוגמה:

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

בדוגמה הזו, במדיניות Quota יש שני מוני מכסה שנקראים של peak_time ו-off_peak_time.

מאפיינים

<Interval> רכיב

משמש לציון מספר שלם (לדוגמה, 1, 2, 5, 60 וכן הלאה) שיותאם עם TimeUnit שמציינים (דקה, שעה, יום, שבוע או חודש) כדי לקבוע שעה שבמהלכה דפדפן Edge מחשב את השימוש במכסה.

לדוגמה, Interval של 24 עם המשמעות של TimeUnit של hour שהמכסה תהיה מחושב לאורך 24 שעות.

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

מאפיינים

<TimeUnit> רכיב

משמש לציון יחידת הזמן הרלוונטית למכסה.

לדוגמה, Interval של 24 עם המשמעות של TimeUnit של hour שהמכסה תהיה מחושב לאורך 24 שעות.

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

מאפיינים

<StartTime> רכיב

אם המדיניות type מוגדרת לערך calendar,, התאריך הזה מציין את התאריך ואת השעה שבה תתחיל הספירה של מונה המכסות, בין אם נשלחו בקשות כלשהן שהתקבלו מאפליקציות.

צריך לציין StartTime מפורש כשמוגדר type באופן מפורש אל calendar, לא ניתן להשתמש בהפניה למשתנה זרימה, אם מציינים ערך של StartTime אם לא הוגדר ערך של type, אז מתקבל ערך של StartTime שגיאה.

לדוגמה:

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

<הופצה> רכיב

בהתקנה של Edge אפשר להשתמש במעבד הודעות אחד או יותר כדי לעבד בקשות. הגדרה ל-true כדי לציין שהמדיניות צריכה לשמור מונה ולסנכרן אותו באופן רציף בין כל מעבדי ההודעות. מעבדי ההודעות יכולים להיות בכמה אזורי זמינות ו/או אזורים.

אם משתמשים בערך ברירת המחדל של false, יכול להיות שתחרגו מהמכסה כי הספירה עבור כל מעבד הודעות לא משותפת:

<Distributed>true</Distributed>

כדי להבטיח שהמוניים יסונכרנו ומעודכנים בכל בקשה, מגדירים <Distributed> ו-<Synchronous> לערך True:

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

&lt;Synchronous&gt; רכיב

צריך להגדיר את הערך true כדי לעדכן מונה מכסה מבוזר באופן סינכרוני. הזה פירושו שהעדכון למונה מתבצע באותו זמן שבו נבדקת המכסה בבקשה ל-API. אם חשוב לא לאפשר אף API, צריך להגדיר את הערך ל-true קריאות מעבר למכסה.

צריך להגדיר את הערך false כדי לעדכן את מונה המכסה באופן אסינכרוני. כלומר ייתכן שחלק מהקריאות ל-API שיחרגו מהמכסה יבוצעו, בהתאם למועד מונה המכסות במאגר המרכזי מתעדכן באופן אסינכרוני. עם זאת, לא תתקלו את ההשפעות הפוטנציאליות על הביצועים כתוצאה מעדכונים סינכרוניים.

מרווח העדכון האסינכרוני שמוגדר כברירת מחדל הוא 10 שניות. משתמשים ב AsynchronousConfiguration כדי להגדיר את ההתנהגות האסינכרונית הזו.

<Synchronous>false</Synchronous>

&lt;AsynchronousConfiguration&gt; רכיב

המדיניות הזו מגדירה את מרווח הסנכרון בין מוני מכסה מבוזרים כאשר המדיניות רכיב התצורה <Synchronous> לא קיים או לא קיים, ומוגדר אל false.

אפשר לסנכרן אחרי פרק זמן מסוים או אחרי ספירת הודעות, באמצעות רכיבי צאצא מסוג SyncIntervalInSeconds או SyncMessageCount. אין חפיפה ביניהן. לדוגמה,

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

או

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

&lt;AsynchronousConfiguration&gt;/&lt;SyncIntervalInSeconds&gt; רכיב

להשתמש באפשרות הזו כדי לשנות את התנהגות ברירת המחדל שבה מבוצעים עדכונים אסינכרוניים אחרי מרווח של 10 שניות.

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

מרווח הזמן לסנכרון חייב להיות >= 10 שניות כפי שמתואר מגבלות.

&lt;AsynchronousConfiguration&gt;/&lt;SyncMessageCount&gt; רכיב

מציינת את מספר הבקשות בין מכסה בכל מעבדי ההודעות ב-Apigee

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

הדוגמה הזו מציינת שספירת המכסות מתעדכנת כל 5 בקשות בכל Apigee מעבד הודעות Edge.

&lt;Identifier&gt; רכיב

עליך להשתמש ברכיב <Identifier> כדי להגדיר את המדיניות ליצירת תכונות ייחודיות מונה שמבוססים על משתנה זרימה.

אם לא משתמשים ברכיב הזה, המדיניות משתמשת במונה אחד שמוחל על במכסה.

הרכיב הזה מתואר גם בפוסט הבא בקהילת Apigee: 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"/>

מאפיינים

&lt;MessageWeight&gt; רכיב

משמש לציון המשקל שיוקצה לכל הודעה. שימוש במשקל ההודעה כדי להגדיל את ההשפעה של בקשות להודעות שצורכות, למשל, יותר משאבי חישוב מאחרים.

לדוגמה, אתם רוצים לספור הודעות POST כ'כבדות' פי שניים. או יקר, כמו GET הודעות. לכן, מגדירים את הערך MessageWeight ל-2 עבור POST ול-1 עבור הורדה. אפשר אפילו להגדיר את MessageWeight ל-0 כדי שהבקשה לא משפיעים על המונה. בדוגמה הזאת, אם המכסה היא 10 הודעות בדקה, הערך MessageWeight של בקשות POST הוא 2, ואז המכסה מאפשרת 5 בקשות POST בכל פרק זמן של 10 דקות. כל בקשה נוספת, POST או GET, לפני שפעולות האיפוס הנגדיות נדחו.

יש לציין ערך שמייצג את MessageWeight באמצעות זרימה משתנה, ואפשר לחלץ אותו מכותרות HTTP, מפרמטרים של שאילתה, מבקשת XML או בקשת JSON מטען ייעודי (payload) או כל משתנה אחר של זרימה. לדוגמה, מגדירים אותו בכותרת בשם weight:

<MessageWeight ref="message_weight"/>

משתני זרימה

משתני ה-flow המוגדרים מראש הבאים מאוכלסים באופן אוטומטי כשמדיניות מכסה מבצע. מידע נוסף על משתני זרימה זמין במאמר הפניית משתנים.

התייחסות לשגיאות

בקטע הזה מתוארים קודי השגיאה והודעות השגיאה שהוחזרו, ומשתני התקלה שמוגדרים על ידי Edge כשהמדיניות הזו גורמת לשגיאה. חשוב לדעת את המידע הזה אם אתם מפתחים כללי כשל כדי לטפל בתקלות. מידע נוסף זמין במאמר מה צריך לדעת? מידע על שגיאות שקשורות למדיניות וטיפול פגמים.

שגיאות זמן ריצה

השגיאות האלה עשויות להתרחש כשהמדיניות מופעלת.

שגיאות פריסה

משתני כשל

המשתנים האלה מוגדרים כשהמדיניות הזו גורמת לשגיאה. מידע נוסף זמין במאמר מה צריך לדעת? על שגיאות שקשורות למדיניות.

דוגמה לתגובת שגיאה

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

דוגמה לכלל שגוי

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

סכימות

נושאים קשורים

המדיניות ResetQuota

SpikeArrest מדיניות

השוואה כללי המדיניות בנושא מכסות, מעצרים והגבלת קצב של יצירת בקשות בו-זמנית