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

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

סרטונים

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

וידאו התיאור
שגיאה 503 של שירות לא זמין משרת קצה עורפי מידע על הנושאים הבאים:
  • מבוא לשגיאה 503 של שירות לא זמין ב-Apigee Edge
  • פתרון בעיות ופתרון בעיות של שירות 503 בזמן אמת לא זמין משרת קצה עורפי

תיאור הבעיה

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

הודעות שגיאה

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

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.

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

גורמים

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

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

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

הסיבה: עומס יתר על השרת/השרת בתחזוקה

ב-Apigee Edge, ניתן להחזיר את 'שגיאה 503 Service Unavailable' משרת קצה עורפי בכל אחת מהנסיבות הבאות:

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

אבחון

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

  • כלי המעקב
  • יומני הגישה של NGINX
  • שיחה ישירה לשרת הקצה העורפי

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

כלי המעקב

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

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

  5. לוחצים על השלב תגובה שהתקבלה משרת היעד ועוברים על הקטעים 'כותרות תגובה' ו'תוכן תגובה' כדי לראות אם יש בהם מידע שימושי:
    • כותרות התגובה עשויות להכיל את כותרת השרת, שמציינת מהיכן נשלחה תגובת השגיאה.
    • תוכן התגובה עשוי להכיל מידע נוסף על הסיבה לכך ששרת היעד שלח את קוד התגובה 503.
  6. מוודאים ששגיאה 503 מגיעה משרת היעד. לשם כך, בודקים את הערכים של X-Apigee-fault-source ושל X-Apigee-fault-code בשלב AX (רישום נתונים של Analytics) במסגרת המעקב, לפי השלבים הבאים:
    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. חוזרים לשלב בקשה שנשלחה לשרת היעד, לוחצים על הלחצן Show Curl וקובעים את כתובת האימייל החלופית של שרת היעד.
    2. אם הכינוי של שרת היעד מפנה אל כינוי מארח וירטואלי, מדובר בשרשרת של שרת proxy. במקרה כזה, צריך לחזור על כל השלבים שלמעלה לגבי שרת ה-proxy המשורשר, עד שמוצאים מה למעשה גורם לשגיאה 503 – Service Unavailable. במקרים האלה, השירות 503 לא זמין יכול להתרחש בשרתי proxy אחרים של הרשת בשלבים אחרים, וגם ניתן לאבחן אותם בעזרת המדריך הזה.
    3. אם הכינוי של שרת היעד מפנה לשרת הקצה העורפי, עוברים אל פתרון.

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

אפשר גם לעיין ביומני lccess של 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 מגיעה משרת הקצה העורפי:
    כותרות תגובה ערך
    X-Apigee-fault-source יעד
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode

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

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

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

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

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

רזולוציה

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

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

אבחון בעיות באמצעות API Monitoring

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

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

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

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

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

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

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

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