מדיניות מכסה

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

מה

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

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

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

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

המכסות חלות על שרתי proxy נפרדים של ה-API ואינן מחולקות בין שרתי proxy של API. לדוגמה, אם יש לכם שלושה שרתי proxy של API במוצר API, מכסה אחת לא תחולק לכל שלושת שרתי ה-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 בקשות ומציבים אותה בכמה תהליכי עבודה (Flow A , B ו-C) בשרת ה-API של ה-API. למרות שמשתמשים בה בכמה תהליכי עבודה, היא כוללת מונה אחד שמתעדכן בכל המופעים של המדיניות:

• שלב א' מתבצע -> MyQuotaPolicy מתבצע והמונה שלו = 1
• שלב B מתבצע -> MyQuotaPolicy מתבצע והמונה שלו = 2
• שלב א' מבוצע -> MyQuotaPolicy מתבצע והמונה שלו = 3
• שלב ג' מתבצע -> MyQuotaPolicy מתבצע והמונה שלו = 4
• שלב א' מתבצע -> MyQuotaPolicy מתבצע והמונה שלו = 5

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

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

לחלופין, אפשר להגדיר כמה כללי מדיניות מכסה בשרת ה-API של ממשק ה-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 עם מגבלות מכסה?

הפניה לרכיב

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

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

מאפיינים

רכיב <מרווח>

משמש לציון מספר שלם (לדוגמה 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>2017-7-16 12:00:00</StartTime>

רכיב <מופץ>

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

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

<Distributed>true</Distributed>

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

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

רכיב <סינכרוני>

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

צריך להגדיר את הערך 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>

ההגדרה קובעת את מספר הבקשות בכל מעבדי ההודעות של 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"/>

מאפיינים

הרכיב <Message weight>

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

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

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

<MessageWeight ref="message_weight"/>

משתני זרימה

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

הפניה לשגיאות

בקטע הזה מתוארים קודי התקלות והודעות השגיאה שמוחזרים, ומשתני השגיאה שמוגדרים על ידי 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>

סכימות

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

מדיניות איפוס מכסה

המדיניות בנושא SpikeArrest

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