איזון עומסים בין שרתים עורפיים

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

Apigee Edge משפרת את הזמינות של ה-API באמצעות תמיכה מובנית באיזון עומסים ויתירות כשל במכונות מרובות של שרת קצה עורפי.

ההגדרות של TargetServer מפרידות כתובות URL קונקרטיות של נקודות קצה מהגדרות TargetEndpoint. ב-TargetEndpoint HTTPConnection יש הפניה לכל שרת TargetServer. במקום להגדיר כתובת URL קונקרטית בתצורה, אפשר להגדיר שרת אחד או יותר בשם TargetServers, כפי שמתואר בקטע TargetEndpoint.

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

סרטונים

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

וידאו	תיאור
איזון עומסים באמצעות שרתי יעד	ממשקי API של איזון עומסים בשרתי יעד.
ניתוב API המבוסס על סביבה באמצעות שרתי יעד	ניתוב API לשרת יעד אחר על סמך הסביבה.
ניתוב API ואיזון עומסים באמצעות שרתי יעד (Classic Edge)	ניתוב API לשרת יעד אחר בהתאם לסביבה ולמאזן העומסים של ה-API בין שרתי היעד בממשק המשתמש הקלאסי של Edge.

דוגמה של תצורת שרת יעד

הקוד הבא מגדיר שרת יעד:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

רכיבי התצורה של TargetServer

הטבלה הבאה מתארת את הרכיבים המשמשים ליצירה ולהגדרה של TargetServer:

שם	תיאור	ברירת המחדל	חובה?
name	השם של הגדרת ה-TargetServer, שחייב להיות ייחודי בסביבה. שם TargetServer יכול להכיל תווים אלפאנומריים בלבד.	לא רלוונטי	כן
Host	כתובת ה-URL של המארח של השירות לקצה העורפי (ללא הפרוטוקול).	לא רלוונטי	כן
Port	היציאה שבה מאזין השירות לקצה העורפי	לא רלוונטי	כן
IsEnabled	ערך בוליאני שמציין אם תצורת שרת היעד מופעלת או מושבתת. כך אפשר להוציא את TargetServers מהסבב בלי לשנות את ההגדרה של שרת ה-API. אחד השימושים הנפוצים הוא לכתוב אפליקציה או סקריפט שמאפשרים או משביתים אוטומטית שרתי TargetServers באופן אוטומטי על סמך דרישות הקיבולת הצפויה, לוחות זמנים של תחזוקה וכו'.	true	כן

ניהול שרתי היעד באמצעות ממשק המשתמש

ניהול שרתי היעד, כפי שמתואר בהמשך.

ניהול שרתי היעד באמצעות ה-API

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

כדי ליצור שרת יעד, משתמשים בקריאה הבאה ל-API:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

תשובה לדוגמה:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

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

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

תשובה לדוגמה:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

יש להשתמש בקריאה הבאה ל-API כדי לאחזר רשימה של TargetServers בסביבה:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

דוגמה לתשובה:

[ "target2", "target1" ]

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

יש מגבלה של 500 TargetServers לכל סביבה, כפי שמצוין בנושא Limits.

הגדרת TargetEndpoint למאזן עומסים ב-TargetServers שמות

עכשיו שיש לך שני שרתי TargetServers זמינים, אפשר לשנות את ההגדרה של חיבור ה-HTTP של TargetEndpoint כדי להפנות לשני שרתי TargetServer האלה לפי שם:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

התצורה שלמעלה היא ההגדרה הבסיסית ביותר של איזון עומסים. מאזן העומסים תומך בשלושה אלגוריתמים של איזון עומסים: Round Robin, Weighted ו-Least Connection. 'Round Robin' הוא אלגוריתם ברירת המחדל. מאחר שלא צוין אלגוריתם בהגדרה שלמעלה, בקשות יוצאות משרת ה-API של ה-API לשרתי הקצה העורפי יעברו לסירוגין, אחת מהן, בין יעד 1 ליעד 2.

הרכיב <Path> יוצר את הנתיב הבסיסי של ה-URI של TargetEndpoint עבור כל שרתי היעד. הוא נמצא בשימוש רק כאשר נעשה שימוש ב-<LoadBalancer>. אחרת, המערכת תתעלם ממנה. בדוגמה שלמעלה, בקשה שתגיע אל "target1" תהיה http://target1/test וכך גם לגבי שרתי יעד אחרים.

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

אפשר להתאים את הזמינות באמצעות אפשרויות של איזון עומסים ויתירות כשל ברמת מאזן העומסים וברמה של TargetServer. בקטע הזה מתוארות האפשרויות האלה.

אלגוריתם

מגדיר את האלגוריתם המשמש את <LoadBalancer>. האלגוריתמים הזמינים הם RoundRobin, Weighted ו-LeastConnections, וכל אחד מהם מתועד בהמשך.

כולם נגד כולם

אלגוריתם ברירת המחדל, Robin robin, מעביר בקשה לכל TargetServer לפי הסדר שבו השרתים רשומים בחיבור ה-HTTP של נקודת הקצה (endpoint). לדוגמה:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

נשקל

האלגוריתם המשוקלל של איזון העומסים מאפשר להגדיר עומסי תנועה יחסיים עבור TargetServers. ה-Load Balancer המשוקלל מחלק בקשות לשרתי TargetServers שלך באופן ישיר ביחס למשקל של כל TargetServer. לכן, האלגוריתם המשוקלל מחייב להגדיר מאפיין weight לכל שרת יעד. לדוגמה:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

בדוגמה הזו, שתי בקשות ינותבו אל target2 לגבי כל בקשה אחת שתנותב אל target1.

הכי פחות חיבור

Load Balancers מוגדרים לשימוש באלגוריתם של החיבור הנמוך ביותר, לניתוב בקשות יוצאות אל TargetServer עם מספר חיבורי ה-HTTP הפתוחים הנמוך ביותר. לדוגמה:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

מקסימום כשלים

המספר המקסימלי של בקשות שנכשלו משרת ה-API של ה-API אל TargetServer, שיובילו להפניה מחדש של הבקשה ל-TargetServer אחר.

המשמעות של כשל בתגובה היא ש-Apigee לא מקבל תגובה משרת יעד. במקרה כזה, מונה הכשל יגדל באחד.

עם זאת, כש-Apigee מקבל תגובה מיעד, גם אם התשובה היא שגיאת HTTP (כמו 500), נספרת כתגובה משרת היעד, ומונה הכשל מתאפס. כדי לוודא שתגובות HTTP לא טובות (כמו 500) גם מגבירות את מונה הכשל ובכך מוציאות שרת לא תקין מסבב איזון עומסים בהקדם האפשרי, אפשר להוסיף להגדרה של מאזן העומסים את הרכיב <ServerUnhealthyResponse> עם רכיבי צאצא <ResponseCode>. Edge גם תספור תשובות עם הקודים האלה ככשלים.

בדוגמה הבאה, המערכת תסיר את target1 מהסבב אחרי חמש בקשות שנכשלו, כולל כ-5XX תגובות משרת היעד.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

ברירת המחדל של MaxFailures היא 0. כלומר, Edge תמיד מנסה להתחבר ליעד עבור כל בקשה, ואף פעם לא מסירה את שרת היעד מהסבב.

מומלץ להשתמש ב-MaxFailures > 0 עם HealthMonitor. אם מגדירים את MaxFailures > 0, שרת היעד מוסר מהסבב כאשר היעד נכשל במספר הפעמים שציינתם. אחרי התקנה של HealthMonitor, Apigee מחזיר את TargetServer באופן אוטומטי אחרי שהיעד מופעל ופועל שוב, בהתאם לתצורה של HealthMonitor. אפשר לקרוא מידע נוסף במעקב אחר בריאות.

לחלופין, אם מגדירים את MaxFailures > 0 ולא מגדירים HealthMonitor, Apigee לא תכלל מחדש את TargetServer בסבב לאחר ש-Apigee מזהה כשל. במקרה כזה, צריך לפרוס מחדש את שרת ה-API של ה-API לפני ש-Apigee יחזיר את TargetServer בחזרה לסבב. למידע נוסף, ראו פריסת שרת proxy ל-API.

ניסיון נוסף

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

ערך ברירת המחדל של <RetryEnabled> הוא true. כדי להשבית את הניסיון החוזר, יש להגדיר את הערך false. לדוגמה:

<RetryEnabled>false</RetryEnabled>

IsFallback

אפשר להגדיר שרת יעד אחד (ואחד בלבד) כשרת 'fallback'. ה-TargetServer החלופי לא נכלל בתרחישי איזון העומסים עד שכל שאר שרתי TargetServer יזוהו כלא זמינים על ידי מאזן העומסים. כשמאזן העומסים קובע שכל שרתי TargetServers לא זמינים, כל התעבורה מנותבת לשרת החלופי. לדוגמה:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

ההגדרה שלמעלה מובילה לאיזון עומסים בסבב רובין בין יעדים 1 ו-2 עד שיעדים 1 ו-2 לא זמינים. כשיעדים 1 ו-2 לא זמינים, כל התנועה מנותבת אל יעד 3.

נתיב

הנתיב מגדיר מקטע URI שיצורף לכל הבקשות שהונפקו על ידי TargetServer לשרת הקצה העורפי.

הרכיב הזה יכול לקבל נתיב מחרוזת מילולי או תבנית הודעה. תבנית הודעה מאפשרת להחליף מחרוזת משתנה בזמן הריצה. לדוגמה, בהגדרה הבאה של נקודת הקצה של היעד, הערך של {mypath} משמש לנתיב:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

הגדרה של שרת יעד ל-TLS/SSL

אם בחרת להשתמש ב-TargetServer כדי להגדיר את השירות לקצה העורפי, והשירות לקצה העורפי דורש חיבור כדי להשתמש בפרוטוקול HTTPS, עליך להפעיל TLS/SSL בהגדרת TargetServer. הפעולה הזו נדרשת כי התג <Host> לא מאפשר לציין את פרוטוקול החיבור. בהמשך מוצגת הגדרת TargetServer עבור TLS/SSL חד-כיווני, כאשר Edge שולח בקשות HTTPS לשירות הקצה העורפי:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

אם השירות לקצה העורפי דורש TLS/SSL דו-כיווני או הדדי, עליכם להגדיר את TargetServer באמצעות אותן הגדרות TLS/SSL כמו אלה של TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

למידע על מאפייני <SSLInfo>, כמו <Ciphers> ו-<ClientAuthEnabled>, תוכלו לקרוא את המאמר על הגדרת המאפיינים האלה למארח וירטואלי במאמר הגדרת גישה באמצעות TLS ל-API בענן הפרטי.

להוראות מלאות להגדרת TLS/SSL יוצא, ראו הגדרת TLS מ-Edge לקצה העורפי (Cloud וענן פרטי).

סכימה של שרת היעד

אפשר לעיין בסכימה של TargetServer ושל ישויות אחרות ב- GitHub.

מעקב אחר בריאות

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

מעקב אחר בריאות עובד עם <MaxFailures>. אם מעקב אחר תקינות לא מופעל, המדיניות <MaxFailures> מציינת את מספר הבקשות שנכשלו משרת ה-proxy של ה-API אל שרת ה-TargetServer. כתוצאה מכך הבקשה מופנית אוטומטית לשרת TargetServer אחר. לאחר מכן, שרת ה-TargetServer הכשל יוצא מהסבב עד לפריסה מחדש של שרת ה-proxy.

כשהתכונה 'מעקב אחר תקינות' מופעלת, שרת TargetServer שהעיבוד שלו נכשל מוחזר אוטומטית לסבב ואין צורך בפריסות מחדש של שרת ה-proxy.

ה-HealthMonitor פועל כלקוח פשוט שמפעיל שירות לקצה העורפי באמצעות TCP או HTTP:

• לקוח TCP פשוט מבטיח שניתן יהיה לפתוח שקע (socket).
• אתם מגדירים את לקוח ה-HTTP כך שישלח בקשת HTTP חוקית לשירות הקצה העורפי. אפשר להגדיר פעולות HTTP GET, PUT, POST או DELETE. התגובה של הקריאה לניטור ה-HTTP חייבת להתאים להגדרות שנקבעו בבלוק <SuccessResponse>.

הצלחות וכישלונות

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

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

• הצלחה: שרת היעד נחשב תקין כשמתבצעת בדיקת תקינות מוצלחת. לרוב הסיבה לכך היא אחת או יותר מהסיבות הבאות:
  • שרת היעד מקבל חיבור חדש ליציאה שצוינה, מגיב לבקשה ביציאה הזו ולאחר מכן סוגר את היציאה במסגרת הזמן שצוינה. התשובה משרת היעד מכילה 'Connection: close'
  • שרת היעד מגיב לבקשת בדיקת תקינות עם קוד סטטוס HTTP 200 (OK) או קוד אחר שקבעתם כמקובל.
  • שרת היעד מגיב לבקשה לבדיקת תקינות עם גוף הודעה שתואם לגוף ההודעה הצפוי.

  כש-Edge מזהה שהשרת תקין, היא ממשיכה לשלוח אליו בקשות או ממשיכה לשלוח אליו בקשות.

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

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

הפעלת HealthMonitor

כדי ליצור HealthMonitor, צריך להוסיף את הרכיב <HealthMonitor> לתצורת HTTPConnection של TargetEndpoint עבור שרת proxy. לא ניתן לעשות זאת בממשק המשתמש. במקום זאת צריך ליצור הגדרה אישית לשרת proxy ולהעלות אותה ל-Edge כקובץ ZIP. הגדרת שרת proxy היא תיאור מובנה של כל ההיבטים של שרת proxy של API. הגדרות שרת Proxy מורכבות מקובצי XML במבנה ספריות מוגדר מראש. מידע נוסף זמין במאמר חומר עזר בנושא הגדרת שרת proxy ל-API.

HealthMonitor פשוט מגדיר IntervalInSec בשילוב עם TCPMonitor או HTTPMonitor. הרכיב <MaxFailures> מציין את המספר המקסימלי של בקשות שנכשלו משרת ה-API של ה-API לשרת TargetServer, וכתוצאה מכך הבקשה מפנה אוטומטית לשרת TargetServer אחר. ערך ברירת המחדל של <MaxFailures> הוא 0, כלומר Edge לא מבצעת פעולה מתקנת. כשמגדירים מעקב תקינות, חשוב להקפיד להגדיר את הערך <MaxFailures> בתג <HTTPTargetConnection> של התג <TargetEndpoint> לערך שאינו אפס.

TCPMonitor

בהגדרה שמופיעה בהמשך מוגדר HealthMonitor שבודקת כל TargetServer על ידי פתיחת חיבור ביציאה 80 כל חמש שניות. (היציאה היא אופציונלית. אם לא מציינים שום אפשרות, יציאת TCPMonitor היא יציאת TargetServer.)

• אם החיבור נכשל או שנדרש יותר מ-10 שניות כדי להתחבר, ספירת הכשלים גדלה ב-1 עבור אותו TargetServer.
• אם החיבור מצליח, ספירת הכשלים עבור TargetServer מתאפסת ל-0.

אפשר להוסיף רכיב HealthMonitor כרכיב צאצא של רכיב HTTPTargetEndpoint של targetEndpoint, באופן הבא:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor עם רכיבי תצורה של TCPMonitor

הטבלה הבאה מכילה תיאור של רכיבי התצורה של TCPMonitor:

שם	תיאור	ברירת המחדל	חובה?
IsEnabled	ערך בוליאני שמפעיל או משבית את HealthMonitor.	false	לא
IntervalInSec	מרווח הזמן בשניות בין כל בקשת TCP של תשאול.	0	כן
ConnectTimeoutInSec	זמן החיבור ליציאת ה-TCP כדי להבטיח הצלחה. אם החיבור במרווחי הזמן שצוין נכשל, המערכת מוסיפה את מספר הכשלים של מאזן העומסים ל-TargetServer.	0	כן
Port	אפשרות. היציאה שבה יווצר חיבור ה-TCP. אם לא מציינים שום אפשרות, יציאת TCPMonitor היא יציאת TargetServer.	0	לא

HTTPMonitor

דגימת HealthMonitor שמשתמשת ב-HTTPMonitor תשלח בקשת GET לשירות הקצה העורפי פעם ב-5 שניות. בדוגמה הבאה מוסיפה כותרת HTTP Basic Authorization להודעת הבקשה. ההגדרה של 'תגובה' קובעת הגדרות שיושוו לעומת התגובה בפועל מהשירות לקצה העורפי. בדוגמה הבאה, התגובה הצפויה היא קוד תגובת HTTP 200, וכותרת HTTP מותאמת אישית ImOK שהערך שלה הוא YourOK. אם התשובה לא תואמת, הבקשה תטופל ככשל בהגדרות של מאזן העומסים.

HTTPMonitor תומך בשירותים לקצה עורפי שהוגדרו לשימוש בפרוטוקולי HTTP ו-HTTPS חד-כיווניים. עם זאת, הוא לא תומך בפלטפורמות הבאות:

• HTTPS דו-כיווני (נקרא גם TLS דו-כיווני או SSL)
• אישורים בחתימה עצמית

שימו לב שכל ההגדרות של 'בקשה' ו'תגובה' בניטור HTTP יהיו ספציפיות לשירות הקצה העורפי שיש להפעיל.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor עם רכיבי תצורה של HTTPMonitor

הטבלה הבאה מתארת את רכיבי התצורה של HTTPMonitor:

שם	תיאור	ברירת המחדל	חובה?
IsEnabled	ערך בוליאני שמפעיל או משבית את HealthMonitor.	false	לא
IntervalInSec	מרווח הזמן בשניות, בין כל בקשת תשאול.	0	כן
Request	אפשרויות הגדרה עבור הודעת הבקשה היוצאת שנשלחה על ידי HealthMonitor ל-TargetServers בסבב. הנתיב לא תומך במשתנים.	לא רלוונטי	כן
ConnectTimeoutInSec	זמן, בשניות, שבו לחיצת היד של חיבור TCP לשירות ה-HTTP חייבת להסתיים כדי להיחשב כהצלחה. אם החיבור במרווח הזמן שצוין לא מתחבר, נספר ככשל, וכתוצאה מכך עולה מספר הכשלים של Load Balancer עבור TargetServer.	0	לא
SocketReadTimeoutInSec	זמן, בשניות, שבו יש לקרוא את הנתונים משירות ה-HTTP כדי להיחשב להצלחה. אי קריאה במרווח הזמן שצוין נספרת ככשל, וכתוצאה מכך עולה מספר הכשלים של Load Balancer עבור TargetServer.	0	לא
Port	היציאה שבה ייקבע חיבור ה-HTTP לשירות הקצה העורפי.	לא רלוונטי	לא
Verb	פועל ה-HTTP המשמש לכל דגימה של בקשת HTTP לשירות הקצה העורפי .	לא רלוונטי	לא
Path	הנתיב שמצורף לכתובת ה-URL שהוגדרה ב-TargetServer. צריך להשתמש ברכיב הנתיב כדי להגדיר 'נקודת קצה (endpoint)' בשירות ה-HTTP.	לא רלוונטי	לא
IncludeHealthCheckIdHeader	מאפשרת לעקוב אחרי הבקשות לבדיקת תקינות במערכות upstream. השדה IncludeHealthCheckIdHeader מקבל ערך בוליאני, וברירת המחדל שלו היא false. אם מגדירים אותו לערך true, יש Header בשם X-Apigee-Healthcheck-Id שמוחדרת לבקשת הבדיקה. הערך של הכותרת מוקצה באופן דינמי בפורמט ORG/ENV/SERVER_UUID/N, שבו ORG הוא שם הארגון, ENV הוא שם הסביבה, SERVER_UUID הוא מזהה ייחודי המזהה את ה-MP ו-N הוא מספר אלפיות השנייה שחלפו מאז 1 בינואר 1970. דוגמה לכותרת של בקשה שהתקבלה: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	לא
Payload	גוף ה-HTTP שנוצר לכל בקשת HTTP של תשאול. לתשומת ליבך, הרכיב הזה אינו נדרש עבור בקשות GET.	לא רלוונטי	לא
SuccessResponse	אפשרויות התאמה להודעת תגובת HTTP הנכנסת, שנוצרה על ידי שירות הקצה העורפי שנדגם. תשובות שלא תואמות מגדילות את מספר הכישלונות ב-1.	לא רלוונטי	לא
ResponseCode	קוד תגובת ה-HTTP שצפוי להתקבל מ-TargetServer שנדגם. קוד השונה מהקוד שצוין יוביל לכשל, והספירה מתווספת לשירות הקצה העורפי שנבדק. ניתן להגדיר מספר רכיבים של ResponseCode.	לא רלוונטי	לא
Headers	רשימה של כותרת HTTP אחת או יותר וערכים שצפויים להתקבל מהשירות לקצה העורפי שנדגם. כל כותרות או ערכי HTTP בתגובה, השונים מאלה שצוינו, יובילו לכשל, והספירה של TargetServer שנדגם מתווספת ב-1. ניתן להגדיר מספר רכיבי כותרת.	לא רלוונטי	לא