מדיניות SpikeArrest

מדיניות רגילה

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

ההבדל בין SpikeArrest לבין מכסת שימוש

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

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

סרטונים

בסרטונים האלה מוסבר על תרחישי שימוש במדיניות הזו:

למה צריך את זה

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

רכיב <SpikeArrest>

הגדרת המדיניות SpikeArrest.

ערך ברירת המחדל מידע נוסף מופיע בכרטיסייה מדיניות ברירת המחדל שבהמשך
חובה? אופציונלי
סוג אובייקט מורכב
רכיב אב לא רלוונטי
רכיבי צאצא <Identifier>
<MessageWeight>
<Rate> (חובה)
<UseEffectiveCount>

תחביר

רכיב <SpikeArrest> משתמש בתחביר הבא:

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
 > na<me="po>licy_name&qu<ot;

  Displ>ayN<amedisplay_>nam<e/DisplayName
  Properties/
  I>den<tifier ref="flow_variable&quo>t;/<
  MessageWeight ref=&qu>ot;flow_var<iable>&qu<ot;/
  Rate ref=&>quot;flow_va<riable"rate[p>m<|ps]/Rate
  >UseEffectiveCount[false|true]/UseEffectiveCount
/SpikeArrest

מדיניות ברירת המחדל

בדוגמה הבאה מוצגות הגדרות ברירת המחדל כשמוסיפים מדיניות SpikeArrest לזרימה בממשק המשתמש:

<SpikeArrest async="false" continueOnError="false" enabled="tr>ue&<quot; name=>"Spike-Ar<rest-1">
  <DisplayName>Spi<ke Arrest-1/DisplayName
  Properties/
  Identifie>r r<ef="request.header.some-header-name&q>uot<;/
 > Mes<sageW>eig<ht ref="requ>est.h<eader.weight">/<
  Rate30ps/>Rate
  UseEffectiveCountfalse/UseEffectiveCount
/SpikeArrest

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

מאפיין ברירת מחדל חובה? תיאור
name לא רלוונטי חובה

השם הפנימי של המדיניות. הערך של מאפיין name יכול להכיל אותיות, מספרים, רווחים, מקפים, קווים תחתונים ונקודות. הערך הזה לא יכול להיות ארוך מ-255 תווים.

אפשר להשתמש ברכיב <DisplayName> כדי לתת למדיניות תווית בשם אחר בשפה טבעית בכלי לעריכת פרוקסי בממשק המשתמש לניהול.
continueOnError FALSE אופציונלי מגדירים את הערך false כדי להחזיר שגיאה אם המדיניות נכשלת. זו התנהגות צפויה ברוב המקרים. הגדרה ל-true מאפשרת להמשיך את הביצוע של התהליך גם אחרי שמדיניות נכשלת. מאמרים קשורים:
enabled TRUE אופציונלי מגדירים את הערך true כדי לאכוף את המדיניות, או את הערך false כדי להשבית את המדיניות. המדיניות לא נאכפת גם אם היא עדיין משויכת לזרימה.
async   FALSE הוצא משימוש המאפיין הזה הוצא משימוש.

דוגמאות

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

דוגמה 1

בדוגמה הבאה, הקצב מוגדר לחמש בקשות בשנייה:

<SpikeArrest name="SA-Static>-5p<s&qu>ot;<
  Ra>te5<ps/Rate
  UseEffe>ctive<Countfalse/UseEffe>c<tiveCount
/S>pikeArrest

מדיניות לדוגמה שמאפשרת עד 5 בקשות בשנייה. ההגבלה היא מקסימום של בקשה אחת לכל 200 מילישניות (1, 000/5) באמצעות החלקת נתונים.

דוגמה 2

בדוגמה הבאה, הקצב מוגדר ל-12 לדקה:

<SpikeArrest name="SA-Static->12p<m&qu>ot;
<  Rat>e12<pm/Rate
  UseEffe>ctiv<eCounttrue/UseEffe>c<tiveCount
/S>pikeArrest

מדיניות לדוגמה שמאפשרת עד 12 בקשות בדקה בקצב של בקשה אחת כל 5 שניות (60/12). אם יש יותר מבקשה אחת במרווח של 5 שניות, הבקשות האלה מותרות (ללא החלקה) בתנאי שמספר הבקשות נמוך ממגבלת הקצב שהוגדרה של 12 בדקה.

דוגמה 3

בדוגמה הבאה, הבקשות מוגבלות ל-12 בדקה (בקשה אחת מותרת כל חמש שניות, או 60/12):

<SpikeArrest name="SA-With-Dynamic-Weig>ht-<1&qu>ot;
<  Rat>e12<pm/Rate
  Identifier ref=&qu>ot;<client_id" /
  MessageWeight ref="r>equ<est_specific_weig>ht&q<uot; /
  UseEffect>i<veCounttrue/>UseEffectiveCount
/SpikeArrest

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

דוגמה 4

בדוגמה הבאה, המדיניות SpikeArrest מורה לחפש ערך של זמן ריצה שהוגדר באמצעות הבקשה שמועברת כמשתנה request.header.runtime_rate flow:

<SpikeArrest name="SA-From-Inbound-Head>er-<1"
  Rate ref="request.header.>run<time_rate" />
  U<seEffectiveCounttr>u<e/UseEffecti>veCount
/SpikeArrest

הערך של משתנה הנתונים חייב להיות בפורמט intpm או intps.

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

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

הפניה לרכיב צאצא

בקטע הזה מתוארים רכיבי הבן של <SpikeArrest>.

<DisplayName>

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

הרכיב <DisplayName> משותף לכל סוגי המדיניות.

ערך ברירת המחדל לא רלוונטי
חובה? זה שינוי אופציונלי. אם לא מציינים את <DisplayName>, המערכת משתמשת בערך של מאפיין name של המדיניות.
סוג String
רכיב אב <PolicyElement>
רכיבי צאצא ללא

רכיב <DisplayName> משתמש בתחביר הבא:

תחביר

<PolicyElement>
  <DisplayName>POLICY_DISPLAY_NAME</DisplayName>
  ...
</PolicyElement>

דוגמה

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

לרכיב <DisplayName> אין מאפיינים או רכיבי צאצא.

<Identifier>

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

אפשר להשתמש בו בשילוב עם הרכיב <MessageWeight> כדי לקבל שליטה מדויקת יותר על הגבלת קצב הבקשות.

אם משאירים את הרכיב <Identifier> ריק, תיאכף מגבלת קצב אחת על כל הבקשות ל-proxy ל-API הזה.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג String
רכיב אב <SpikeArrest>
רכיבי צאצא ללא

תחביר

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
 > na<me="policy_name"

  I>d<entifier ref>="flow_variable"/
/SpikeArrest

דוגמה 1

בדוגמה הבאה, מדיניות SpikeArrest מוחלת לפי מזהה מפתח:

<SpikeArrest name="Spike-Arre>st-<1"
  Identifier ref=">;de<velo>per.<id&quo>t;/<
  Rate42pm/Rate/>
  U<seEffectiveCounttr>u<e/UseEffecti>veCount
/SpikeArrest

בטבלה הבאה מתוארים המאפיינים של <Identifier>:

מאפיין תיאור ברירת מחדל נוכחות
ref מזהה את המשתנה שלפיו מדיניות SpikeArrest מקבצת בקשות נכנסות. אפשר להשתמש בכל משתנה של זרימת נתונים כדי לציין לקוח ייחודי, כמו המשתנים שזמינים עם מדיניות VerifyAPIKey. אפשר גם להגדיר משתנים מותאמים אישית באמצעות מדיניות JavaScript או מדיניות AssignMessage. לא רלוונטי חובה

האלמנט הזה מוסבר גם בפוסט הזה בקהילת Apigee.

<MessageWeight>

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

אפשר להשתמש בו בשילוב עם <Identifier> כדי לווסת עוד יותר את הבקשות לפי לקוחות או אפליקציות ספציפיים.

לדוגמה, אם הערך של SpikeArrest <Rate> הוא 10pm, ואפליקציה שולחת בקשות במשקל 2, אז מותרות רק חמש הודעות בדקה מהלקוח הזה, כי כל בקשה נספרת כ-2.

ערך ברירת המחדל לא רלוונטי
חובה? אופציונלי
סוג מספר שלם
רכיב אב <SpikeArrest>
רכיבי צאצא ללא

תחביר

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
 > na<me="policy_name"

  Mess>a<geWeight ref>="flow_variable"/
/SpikeArrest

דוגמה 1

בדוגמה הבאה, הבקשות מוגבלות ל-12 בדקה (בקשה אחת מותרת כל חמש שניות, או 60/12):

<SpikeArrest name="SA-With-Dynamic-Weig>ht-<1&qu>ot;
<  Rat>e12<pm/Rate
  Identifier ref=&qu>ot;<client_id" /
  MessageWeight ref="r>equ<est_specific_weig>ht&q<uot; /
  UseEffect>i<veCounttrue/>UseEffectiveCount
/SpikeArrest

בדוגמה הזו, <MessageWeight> מקבל ערך מותאם אישית (הכותרת weight בבקשה) שמשנה את משקלי ההודעות עבור לקוחות ספציפיים. כך מתקבלת שליטה נוספת על הגבלת קצב הבקשות לישויות שמזוהות באמצעות הרכיב <Identifier>.

בטבלה הבאה מתוארים המאפיינים של <MessageWeight>:

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

<Rate>

מגדיר את הקצב שבו יוגבלו עליות חדות בתעבורת נתונים (או פרצי תעבורה) על ידי הגדרת מספר הבקשות שמותרות במרווחי זמן של דקה או שנייה. אפשר גם להשתמש ברכיב הזה בשילוב עם <Identifier> ועם <MessageWeight> כדי לווסת את תעבורת הנתונים בצורה חלקה בזמן הריצה על ידי קבלת ערכים מהלקוח. משתמשים ברכיב <UseEffectiveCount> כדי להגדיר את אלגוריתם הגבלת קצב של יצירת בקשות שבו נעשה שימוש במדיניות.

ב-SpikeArrest section of the Limits page מופיעות מגבלות הקצב המקסימליות שאפשר לציין.

ערך ברירת המחדל לא רלוונטי
חובה? חובה
סוג מספר שלם
רכיב אב <SpikeArrest>
רכיבי צאצא ללא

תחביר

אפשר לציין מחירים באחת מהדרכים הבאות:

  • שיעור סטטי שאתם מציינים כגוף של רכיב <Rate>
  • ערך משתנה, שאפשר להעביר אותו על ידי הלקוח. צריך לציין את שם משתנה התהליך באמצעות המאפיין ref
<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
 > na<me="policy_name&quo>t;

  Rate <ref=&>q<uot;flow_var>iable"rate[pm|ps]/Rate
/SpikeArrest

ערכי שיעור תקפים (מוגדרים כערך משתנה או בגוף הרכיב) צריכים להיות בפורמט הבא:

  • ‫intps (מספר הבקשות לשנייה, מוחלק למרווחי זמן של אלפיות שנייה)
  • ‫intpm (מספר הבקשות בדקה, מוחלק למרווחי שניות)

הערך של int חייב להיות מספר שלם חיובי שגדול מאפס.

דוגמה 1

בדוגמה הבאה, הקצב מוגדר לחמש בקשות לשנייה:

<SpikeArrest name="SA-Static>-5p<s&qu>ot;<
  Ra>te5<ps/Rate
  UseEffe>ctive<Countfalse/UseEffe>c<tiveCount
/S>pikeArrest

המדיניות מאפשרת שליחה של בקשה אחת בכל 200 אלפיות השנייה (1,000 חלקי 5).

דוגמה 2

בדוגמה הבאה, הקצב מוגדר ל-12 בקשות בדקה:

<SpikeArrest name="SA-Static->12p<m&qu>ot;
<  Rat>e12<pm/Rate
  UseEffe>ctiv<eCounttrue/UseEffe>c<tiveCount
/S>pikeArrest

המדיניות לדוגמה הזו מחליקה את הקצב כך שמתאפשרת בקשה אחת בכל חמש שניות (‎60/12).

בטבלה הבאה מתוארים המאפיינים של <Rate>:

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

אפשר גם להשתמש במשתנים מותאמים אישית באמצעות מדיניות JavaScript או מדיניות AssignMessage.

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

לדוגמה:

<Rate ref="request.header.custom_>rat<e&quo>t;1pm/Rate

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

אתם יכולים להשתמש ב-<Identifier> כדי לקבץ בקשות ולאכוף תעריפים מותאמים אישית עבור סוגים שונים של לקוחות.

אם מציינים ערך למאפיין ref אבל לא מגדירים את הקצב בגוף של רכיב <Rate>, והלקוח לא מעביר ערך, המדיניות SpikeArrest תציג שגיאה.

 אופציונלי לא רלוונטי
בטבלה הבאה מפורטים המאפיינים של Rate שקובעים את ההתנהגות של הגבלת התנועה:
מאפיין תיאור
messagesPerPeriod מציין את מספר ההודעות שמותר לשלוח בפרק זמן מוגדר. לדוגמה, אם המדיניות מוגדרת ל-10ps (10 לשנייה), הערך של messagesPerPeriod יהיה 10.
periodInMicroseconds הערך הזה מגדיר את תקופת הזמן במיקרו-שניות, שבמהלכה מחושב הערך של messagesPerPeriod. בהגדרה של '10ps', הערך הזה יהיה 1,000,000, ששווה לשנייה אחת.
maxBurstMessageCount מייצג את המספר המקסימלי של בקשות שאפשר לאשר באופן מיידי או בפרק זמן קצר בתחילת מרווח חדש.

<UseEffectiveCount>

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

TRUE

אם המדיניות מוגדרת ל-true, המדיניות SpikeArrest מופצת באזור. המשמעות היא שספירת הבקשות מסונכרנת בין מעבדי ההודעות (MPs) באזור. בנוסף, נעשה שימוש באלגוריתם להגבלת קצב של יצירת בקשות של 'חלון נע'. האלגוריתם הזה מספק התנהגות עקבית של הגבלת קצב הבקשות, ולא 'מיישר' את מספר הבקשות הנכנסות שאפשר לשלוח לשרת העורפי. אם נשלחות הרבה בקשות במרווח זמן קצר, הן יאושרו כל עוד הן לא חורגות ממגבלת הקצב שהוגדרה, כפי שמוגדר ברכיב <Rate>. לדוגמה:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

‫false (ברירת מחדל)

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

לדוגמה, נניח שהזנתם קצב של 30pm (30 בקשות לדקה). במהלך בדיקה, יכול להיות שתחשבו שאפשר לשלוח 30 בקשות בשנייה אחת, כל עוד הן נשלחו בתוך דקה. אבל זה לא האופן שבו המדיניות אוכפת את ההגדרה. אם חושבים על זה, 30 בקשות בתוך תקופה של שנייה אחת יכולות להיחשב כעלייה קטנה במספר הבקשות בסביבות מסוימות.

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

    לדוגמה, אם מגדירים 30pm, המערכת תבצע החלקה באופן הבא:
    60 שניות (דקה אחת) חלקי 30pm = בקשות במרווחים של 2 שניות, או בקשה אחת מותרת כל 2 שניות. בקשה שנייה בתוך 2 שניות תיכשל. בנוסף, בקשה 31 בתוך דקה תיכשל.

  • השיעורים לשנייה מוחלקים לבקשות מלאות שמותרות במרווחים של אלפיות השנייה.

    לדוגמה, אם המגבלה היא 10ps, המערכת תבצע החלקה באופן הבא:
    ‫1,000 מילישניות (שנייה אחת) חלקי 10ps = מרווחים של 100 מילישניות, או בקשה אחת מותרת כל 100 מילישניות. בקשה שנייה בתוך 100 אלפיות השנייה תיכשל. בנוסף, בקשה 11 בתוך שנייה תיכשל.

ערך ברירת המחדל לא נכון
חובה? אופציונלי
סוג בוליאני
רכיב אב <SpikeArrest>
רכיבי צאצא ללא

משתנים בתהליך

כשמדיניות SpikeArrest מופעלת, Apigee מאכלס קבוצה של משתני זרימה. אפשר להשתמש במשתני הזרימה האלה בזרימות מותנות, או למטרות מעקב וניתוח.

משתנה סוג הרשאה תיאור
ratelimit.policy_name.available.count ארוכה קריאה בלבד הפונקציה מחזירה את מספר ההגנות מפני עליות פתאומיות בזמן שזמינות במרווח הזמן.
ratelimit.policy_name.exceed.count ארוכה קריאה בלבד הפונקציה מחזירה 1 אם חרגתם מהמגבלה של SpikeArrest בחלון הזמן הנוכחי.
ratelimit.policy_name.failed בוליאני קריאה בלבד המשתנה הזה הוא true אם המדיניות נכשלה בביצוע פנימי. אין להשתמש במשתנה הזה כדי לבדוק אם חרגתם ממגבלת הקצב. יכול להיות שהערך שלו יהיה true בעומס גבוה, בגלל העיצוב של המדיניות שמאפשר גישה גם אם היא נכשלת.

מידע נוסף זמין במאמר חומר עזר בנושא משתני זרימה.

הפניה לשגיאה

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

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

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

קוד תקלה סטטוס HTTP מטרה תיקון
policies.ratelimit.FailedToResolveSpikeArrestRate 500 השגיאה הזו מתרחשת אם אי אפשר לפתור את ההפניה למשתנה שמכיל את הגדרת התעריף בתוך הרכיב <Rate> לערך במדיניות SpikeArrest. הרכיב הזה הוא חובה ומשמש להגדרת קצב ההגבלה של העלייה הפתאומית בצורה של intpm או intps.
policies.ratelimit.InvalidMessageWeight 500 השגיאה הזו מתרחשת אם הערך שצוין לרכיב <MessageWeight> באמצעות משתנה של זרימת נתונים לא תקין (ערך לא שלם).
policies.ratelimit.SpikeArrestViolation 429 הייתה חריגה ממגבלת הקצב.

שגיאות בהטמעה

השגיאות האלה יכולות להתרחש כשפורסים שרת proxy שמכיל את המדיניות הזו.

שם השגיאה מטרה תיקון
InvalidAllowedRate אם הערך של קצב עצירת העלייה הפתאומי שצוין ברכיב <Rate> של המדיניות SpikeArrest אינו מספר שלם, או אם לערך של הקצב אין את הסיומת ps או pm, הפריסה של שרת ה-proxy של ה-API תיכשל.

משתני תקלות

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

משתנים כאשר: דוגמה
fault.name="fault_name" ‫fault_name הוא שם התקלה, כפי שמופיע בטבלה שגיאות בזמן ריצה שלמעלה. שם התקלה הוא החלק האחרון של קוד התקלה. fault.name Matches "SpikeArrestViolation"
ratelimit.policy_name.failed ‫policy_name הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה. ratelimit.SA-SpikeArrestPolicy.failed = true

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

דוגמה לתגובה עם שגיאה:

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

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

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

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>Assign-Message-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>(ratelimit.Spike-Arrest-1.exceed.count > 0) or (ratelimit.Spike-Arrest-1.available.count < 1)</Condition>
    </FaultRule>
</FaultRules>

קוד הסטטוס הנוכחי של HTTP לחריגה ממגבלת קצב שהוגדרה על ידי מדיניות מכסה או SpikeArrest הוא 429 (יותר מדי בקשות).

סכימות

כל סוג מדיניות מוגדר על ידי סכימת XML ‏ (.xsd). סכימות מדיניות זמינות ב-GitHub.

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