מדיניות של SpikeArst

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

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

רכיב <SpikeArrest>

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

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <DisplayName>display_name</DisplayName>
  <Properties/>
  <Identifier ref="flow_variable"/>
  <MessageWeight ref="flow_variable"/>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
  <DisplayName>Spike Arrest-1</DisplayName>
  <Properties/>
  <Identifier ref="request.header.some-header-name"/>
  <MessageWeight ref="request.header.weight"/>
  <Rate>30ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

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

דוגמאות

בדוגמאות הבאות מפורטות כמה מהדרכים שבהן אפשר להשתמש במדיניות 'מניעת עלייה חדה בתנועה':

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

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

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

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

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

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

<DisplayName>

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

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

רכיב <DisplayName> כולל את התחביר הבא:

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

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

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

<Identifier>

מאפשרת לבחור איך לקבץ את הבקשות כדי שאפשר יהיה להחיל את המדיניות של Spike Arrest על סמך הלקוח. לדוגמה, אפשר לקבץ בקשות לפי מזהה מפתח. במקרה כזה, כל בקשה של מפתח תצורף לשיעור החסימה של התקפי פסגה שלו, ולא כל הבקשות לשרת proxy.

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

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

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>
        

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

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

הרכיב הזה מתואר גם בפוסט הבא בקהילה של Apigee: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<MessageWeight>

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

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

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

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

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

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

<Rate>

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

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

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

<Rate ref="request.header.custom_rate">1pm</Rate>

<UseEffectiveCount>

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

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

הרכיב <UseEffectiveCount> הוא אופציונלי. ערך ברירת המחדל הוא false כשהרכיב לא נכלל במדיניות שלכם לטיפול בתנודות חדות בביקוש.

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

ההשפעה של <UseEffectiveCount> תלויה בערך שלו:

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

בטבלה הבאה מוצגת ההשפעה של <UseEffectiveCount> על המגבלה בפועל של קצב שליחת הבקשות לכל MP:

בדוגמה הזו, שימו לב שכאשר מספר המשתתפים קטן מ-4 ל-2, ו-<UseEffectiveCount> הוא false, הקצב האפקטיבי לכל משתתף נשאר ללא שינוי (10). לעומת זאת, כש-<UseEffectiveCount> הוא true, השיעור האפקטיבי לכל חבר פרלמנט עולה מ-10 ל-20 כשמספר חברי הפרלמנט יורד מ-4 ל-2.

משתני תהליך

כשמדיניות של Spike Arrest פועלת, משתנה התהליך הבא מאוכלס:

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

הפניה לשגיאה

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

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

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

שגיאות פריסה

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

משתני כשל

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

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

למטה מוצגת דוגמה לתגובת שגיאה:

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

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

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

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

קוד הסטטוס הנוכחי של HTTP לחריגה ממגבלת קצב שהוגדר על ידי מדיניות מכסה או מדיניות לעיכוב התקפות חירום הוא 429 (יותר מדי בקשות). כדי לשנות את קוד הסטטוס של ה-HTTP ל-500 (שגיאה פנימית בשרת), מגדירים את המאפיין features.isHTTPStatusTooManyRequestEnabled לערך false באמצעות ה-API Update organization properties.

לדוגמה:

curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

סכימות

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

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

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