503 שירות לא זמין - שרת קצה עורפי

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

סרטונים

כדאי לצפות בסרטון הבא כדי לקבל מידע נוסף על פתרון שגיאות 503 Service Unavailable.

וידאו תיאור
503 Service Unavailable Error from Backend Server מידע על הנושאים הבאים:
  • מבוא לשגיאה '503 השירות לא זמין' ב-Apigee Edge
  • פתרון בעיות שקשורות לשגיאה '503 השירות לא זמין' בזמן אמת משרת קצה עורפי

תיאור הבעיה

אחרי קריאה ל-proxy ל-API, אפליקציית הלקוח מקבלת קוד סטטוס של תגובת HTTP‏ 503 עם ההודעה Service Unavailable.

הודעות שגיאה

יכול להיות שתופיע אחת מהודעות השגיאה הבאות:

HTTP/1.1 503 Service Unavailable
 
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

יכול להיות שתוצג גם הודעת שגיאה כמו זו בתגובת ה-HTTP:

The server is temporarily unable to service your request due to
maintenance downtime or capacity problems. Please try again later.

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

גורמים

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

סיבות אפשריות לתגובה 503 Service Unavailable:

הסיבה תיאור מי יכול לבצע את השלבים לפתרון בעיות
עומס יתר בשרת עומס יתר על שרת הקצה העורפי או שהוא מעבר לקיבולת שלו, והוא לא יכול לטפל בבקשות חדשות של לקוחות נכנסים. משתמשים ב-Edge Public Cloud וב-Edge Private Cloud
השרת נמצא בתחזוקה יכול להיות ששרת הקצה העורפי נמצא בתחזוקה באופן זמני. משתמשים ב-Edge Public Cloud וב-Edge Private Cloud

הסיבה: עומס יתר בשרת או שהשרת נמצא בתחזוקה

ב-Apigee Edge, שגיאת 503 Service Unavailable יכולה לחזור משרת backend באחד מהמקרים הבאים:

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

אבחון

כדי לאבחן את השגיאה, אפשר להשתמש באחת משלוש השיטות הבאות:

  • כלי המעקב
  • יומני גישה של NGINX
  • קריאה ישירה לשרת בק-אנד

אפשר ללחוץ על הכרטיסיות הבאות כדי לקבל מידע על כל שיטה.

כלי המעקב

  1. מפעילים את סשן המעקב ושולחים את הקריאה ל-API כדי לשחזר את הבעיה – 503 Service Unavailable (השירות לא זמין).
  2. בוחרים אחת מהבקשות שנכשלו ובודקים את המעקב.
  3. מנווטים בין השלבים השונים של ה-trace ומאתרים את המקום שבו התרחשה הכשל.
  4. אם שגיאת 503 מוחזרת כתגובה משרת היעד, הסיבה לשגיאה היא שרת היעד.

    לפניכם צילום מסך של דוגמה למעקב שמציג תגובה עם השגיאה 503 Service Unavailable שהתקבלה משרת היעד:

  5. לוחצים על השלב Response received from target server ועוברים על הסעיפים Response Headers ו-Response Content כדי לראות אם יש בהם מידע שימושי:
    • כותרות התגובה עשויות להכיל את כותרת השרת, שמציינת מאיפה נשלחה תגובת השגיאה.
    • תוכן התגובה עשוי לכלול מידע נוסף על הסיבה לכך ששרת היעד שלח את קוד התגובה 503.
  6. כדי לוודא שהשגיאה 503 מגיעה משרת היעד, בודקים את הערכים של X-Apigee-fault-source ו-X-Apigee-fault-code בשלב AX (Analytics Data Recorded) ב-trace, באמצעות השלבים הבאים:
    1. לוחצים על השלב AX (נתוני Analytics שתועדו) כמו שמוצג בצילום המסך שלמטה:
    2. גוללים מטה בקטע 'פרטי השלב' אל הקטע 'כותרות תגובה' וקובעים את הערכים של X-Apigee-fault-code ו-X-Apigee-fault-source כמו שמוצג בהמשך:
    3. אם הערכים של X-Apigee-fault-source ו-X-Apigee-fault-code תואמים לערכים שמוצגים בטבלה שלמטה, אפשר לאשר שהשגיאה 503 מגיעה משרת היעד:
      כותרות תגובה ערך
      X-Apigee-fault-source יעד
      X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  7. בודקים אם משתמשים בשרשור של שרתי proxy, כלומר אם שרת היעד או נקודת הקצה של היעד מפעילים שרת proxy אחר ב-Apigee. כדי לדעת מהו:
    1. חוזרים לשלב בקשה שנשלחה לשרת היעד, לוחצים על הלחצן הצגת Curl וקובעים את הכינוי של מארח שרת היעד.
    2. אם כינוי המארח של שרת היעד מצביע על כינוי של מארח וירטואלי, מדובר בשרשור של שרתי proxy. במקרה כזה, צריך לחזור על כל השלבים שלמעלה עבור שרשרת ה-proxy עד שמגלים מה גורם לשגיאה 503 Service Unavailable. במקרים כאלה, יכול להיות ששגיאה 503 Service Unavailable תתרחש גם בשרתי proxy אחרים בשרשרת בשלבים אחרים. אפשר לאבחן את הבעיה באמצעות המדריך הזה.
    3. אם הכינוי של מארח שרת היעד מצביע על השרת העורפי, צריך לעבור אל פתרון.

יומני גישה של NGINX

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

  1. בודקים את יומני הגישה של NGINX. 
    /opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
  2. מחפשים שגיאות 503 עבור proxy ל-API הספציפי במהלך משך זמן מסוים (אם הבעיה התרחשה בעבר) או עבור בקשות שעדיין נכשלות עם שגיאה 503.
  3. אם יש שגיאות 503, צריך לבדוק אם השגיאה מגיעה משרת הקצה העורפי. אם הערכים של X-Apigee-fault-source ו-X-Apigee-fault-code תואמים לערכים שמוצגים בטבלה שלמטה, השגיאה 503 מגיעה משרת ה-Backend:
    כותרות תגובה ערך
    X-Apigee-fault-source יעד
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode

    הנה רשומה לדוגמה שבה מוצגת השגיאה 503 שנגרמה על ידי שרת היעד:

  4. בודקים את ה-API Proxy הספציפי ומוודאים שמשתמשים בשרשור של שרתי proxy, כלומר: אם שרת היעד או נקודת היעד לא מפעילים Proxy אחר ב-Apigee. אם אתם משתמשים בשרשור של שרתי proxy, אתם צריכים לחזור על כל השלבים שלמעלה בשביל שרשרת ה-proxy עד שתקבעו מה גורם לשגיאה 503 Service Unavailable. במקרים כאלה, יכול להיות שגיאת 503 Service Unavailable תתרחש גם בשרתי proxy אחרים בשרשרת בשלבים אחרים, ואפשר לאבחן אותה באמצעות המדריך הזה.
  5. אם אתם בטוחים שאתם לא משתמשים בשרשור של שרתי proxy, ושגיאה 503 מגיעה משרת הקצה העורפי שלכם, אתם יכולים לעבור אל פתרון הבעיה.

קריאה לשרת עורפי

אפשר לבצע קריאה ישירה לשרת העורפי ולוודא שמתקבלת אותה תגובה 503 Service Unavailable (השירות לא זמין) שהתקבלה כשבוצעה הבקשה דרך Apigee Edge.

  1. מוודאים שיש לכם את כל הכותרות הנדרשות, פרמטרים של שאילתות וכל אישורי גישה שצריך להעביר לשרת הקצה העורפי כחלק מהבקשה.
  2. אם שירות לקצה העורפי נגיש לציבור, אפשר להשתמש בפקודה curl, ב-Postman או בכל לקוח REST אחר ולהפעיל את ה-API של שרת הבק-אנד באופן ישיר.
  3. אם אפשר לגשת לשרת הקצה העורפי רק ממעבדי ההודעות, אפשר להשתמש בפקודה curl, ב-Postman או בכל לקוח REST אחר ולהפעיל את ה-API של שרת הקצה העורפי ישירות ממעבד ההודעות.
  4. מוודאים ששירות ה-Backend אכן מחזיר את השגיאה 503 Service Unavailable.

רזולוציה

אם תגלו שהשגיאה 503 מגיעה משרת הקצה העורפי, תוכלו לבצע את הפעולות הבאות כדי לפתור את הבעיה:

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

אבחון בעיות באמצעות 'מעקב אחר API'

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

דוגמה לתרחיש שמראה איך לפתור בעיות שקשורות לקודי שגיאה 5xx בממשקי API באמצעות API Monitoring. לדוגמה, יכול להיות שתרצו להגדיר התראה שתשלח לכם הודעה כשהמספר של התקלות messaging.adaptors.http.flow.ErrorResponseCode יעבור סף מסוים.

צריך לאסוף פרטי אבחון

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

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

  • שם הארגון
  • שם הסביבה
  • שם ה-proxy ל-API
  • פקודת curl מלאה לשחזור השגיאה 503
  • קובץ מעקב שמכיל את הבקשות עם השגיאה 503 Service Unavailable (השירות לא זמין)
  • אם שגיאות 503 לא מתרחשות כרגע, צריך לציין את טווח הזמן עם פרטי אזור הזמן שבו שגיאות 503 התרחשו בעבר.

אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:

  • הודעת השגיאה המלאה שזוהתה בבקשות שנכשלו.
  • שם הארגון, שם הסביבה ושם ה-API Proxy שבהם מתרחשות שגיאות 503.
  • חבילת proxy ל-API.
  • קובץ מעקב שמכיל את הבקשות עם השגיאה 503 Service Unavailable (השירות לא זמין).
  • יומני גישה של NGINX. 
    /opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log
  • יומנים של מעבד ההודעות. 
    /opt/apigee/var/log/edge-message-processor/logs/system.log
  • תקופת הזמן עם פרטי אזור הזמן שבה אירעו שגיאות 503.