מדיניות מכסה

אתם צופים במסמכי התיעוד של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

מה

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

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

אל תשתמשו במכסות כדי להגן מפני עליות חדות במספר הבקשות הכולל. לשם כך, משתמשים במדיניות Spike 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 יכול לטפל בהן במהלך תקופת זמן, כמו דקה, שעה, יום, שבוע או חודש. המדיניות כוללת ספירה של מספר הבקשות שהתקבלו על ידי שרת ה-API. היכולת הזו מאפשרת לספקים של ממשקי API לאכוף מגבלות על מספר הקריאות ל-API שמבוצעות על ידי אפליקציות במרווח זמן מסוים. באמצעות מדיניות המכסות אפשר, למשל, להגביל אפליקציות לבקשה אחת בדקה או ל-10,000 בקשות בחודש.

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

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

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

סוגי כללי מדיניות המכסות

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

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

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

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

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

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

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

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

לדוגמה, יוצרים מדיניות מכסות בשם MyQuotaPolicy עם מגבלה של 5 בקשות וממקמים אותה במספר תהליכים (תהליך א', ב' וג') בשרת ה-proxy של ה-API. למרות שהיא משמשת בכמה תהליכים, היא שומרת על מונה יחיד שמתעדכן על ידי כל המופעים של המדיניות:

• תהליך א' מופעל –> MyQuotaPolicy מופעל ומונה ההתקדמות שלו = 1
• תהליך B מופעל –> MyQuotaPolicy מופעל ומונה ההתקדמות שלו = 2
• תהליך א' מופעל –> MyQuotaPolicy מופעל ומונה שלו = 3
• תהליך C מופעל –> MyQuotaPolicy מופעל ומונה ההתקדמות שלו = 4
• תהליך א' מופעל –> MyQuotaPolicy מופעל ומונה ההתקדמות שלו = 5

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

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

לחלופין, אפשר להגדיר כמה מדיניות מכסות בשרת ה-proxy של ה-API ולהשתמש בכל מדיניות בנפרד לכל תהליך. לכל מדיניות מכסה יש מונה משלה, שמבוסס על המאפיין 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.* שמפורטים בהמשך זמינים כברירת מחדל כשמשתמשים במדיניות Verify API Key‏ (אימות מפתח 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">

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

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

&lt;DisplayName&gt; רכיב

צריך להשתמש בנוסף למאפיין 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>

בדוגמה הזו, מדיניות המכסות שומרת על שני ספירי מכסות בשם 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>2017-7-16 12:00:00</StartTime>

האלמנט <Distributed>

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

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

<Distributed>true</Distributed>

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

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

אלמנט <Synchronous>

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

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

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

<Synchronous>false</Synchronous>

האלמנט <AsynchronousConfiguration>

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

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

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

או

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

האלמנט <AsynchronousConfiguration>/<SyncIntervalInSeconds>

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

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

מרווח הסנכרון צריך להיות 10 שניות לפחות, כפי שמתואר בנושא מגבלות.

<AsynchronousConfiguration>/<SyncMessageCount> element

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

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

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

אלמנט <Identifier>

משתמשים ברכיב <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"/>

מאפיינים

האלמנט <MessageWeight>

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

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

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

<MessageWeight ref="message_weight"/>

משתני תהליך

משתני Flow המוגדרים מראש הבאים מאוכלסים באופן אוטומטי כשמדיניות המכסות מופעלת. מידע נוסף על משתני 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

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