504 זמן קצוב לתפוגה של שער מהשרת העורפי

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

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס של HTTP‏ 504 עם ההודעה "Gateway Timeout" בתגובה לקריאות API.

תגובת השגיאה הזו מציינת שהלקוח לא קיבל תגובה בזמן מ-Apigee Edge או משרת הקצה העורפי במהלך הביצוע של קריאה ל-API.

הודעת השגיאה

אפליקציית הלקוח מקבלת את קוד התגובה הבא: 

HTTP/1.1 504 Gateway Timeout

יכול להיות שקוד השגיאה הזה יופיע עם הודעת שגיאה שדומה להודעה הבאה: 

<html>
<head><title>504 Gateway Timeout</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Timeout</h1></center>
</body>
</html>

מה גורם לפסק זמן בשער?

הנתיב האופייני לבקשת API שמתבצעת דרך Apigee Edge הוא Client -> Router -> מעבד בקשות -> Backend Server, כפי שמוצג באיור הבא:

נתיב בקשת ה-API

אפליקציית הלקוח, הנתבים ומעבדי ההודעות מוגדרים עם ערכי זמן קצוב מתאימים. מערכת Apigee Edge מצפה לקבל תגובה לכל בקשת API בפרק זמן מסוים, בהתאם לערכי הזמן הקצוב לתפוגה. אם התגובה לא מתקבלת במסגרת הזמן שצוינה, מוחזרת תגובה מסוג 504 Gateway Timeout.

סיבות אפשריות

ב-Apigee Edge, הגורם הנפוץ לתגובה מסוג 504 Gateway Timeout (הזמן שהוקצב לשער חלף) משרת ה-Backend הוא:

הסיבה תיאור הוראות לפתרון בעיות ב
השרת בקצה העורפי מגיב עם שגיאת 504 Gateway Timeout הזמן הקצוב לתפוגה של השרת העורפי חלף והוא מחזיר תגובה מסוג 504 Gateway Timeout (הזמן שהוקצב לשער חלף) למעבד ההודעות. משתמשים ב-Edge Private Cloud וב-Edge Public Cloud

שרת הקצה העורפי מגיב עם שגיאת 504 Gateway Timeout

השרת העורפי עשוי להגיב עם קוד תגובת HTTP‏ 504 Gateway Timeout (פסק זמן של שער).

אבחון

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

תהליך מספר 1: שימוש ב-Trace (משתמשי ענן פרטי וציבורי)

  1. מפעילים את Trace בממשק המשתמש של Apigee עבור ה-API המושפע.
  2. שליחת בקשה לשרת העורפי.
  3. אם בקשת ה-API שנכשלה מציגה תגובה 504 מהשרת העורפי ב-Trace, אז הגורם ל-504 Gateway Timeout הוא השרת העורפי.
  4. כדי לקבוע את זמן התגובה, לוחצים על השלב Response received from target server (התגובה התקבלה משרת היעד) בכלי Trace. בדוגמה שמוצגת, הזמן שחלף הוא 60004 אלפיות השנייה:

    פרטי שלב מממשק המשתמש

    בקטע 'פרטי השלב' מופיע מידע נוסף:

    • הוא מדגיש את התגובה 504 Gateway Timeout שהתקבלה משרת הקצה העורפי.
    • בקטע Response Content מוצג הגוף המלא של התגובה משרת הקצה העורפי. כמו שצוין קודם, הפורמט והתוכן של מטען הייעודי (payload) של התגובה עשויים להיות שונים בהתאם להטמעה של שרת הקצה העורפי.
    • בקטע כותרת תגובה > שרת אפשר לראות מאיפה התגובה הגיעה.
  5. כדי לראות את הנתונים של Analytics ולאשר את האבחון, לוחצים על השלב Analytics Data Recorded (הנתונים של Analytics נרשמו) ב-Trace, כמו שמוצג באיור שלמטה:

    פרטי ניתוח ממעקב

    בקטע כותרות תגובה של פרטי השלב מוצגים הערכים של X-Apigee-fault-code ושל X-Apigee-fault-source, כמו שמוצג באיור הבא:

    פרטים על שלב הניתוח בממשק המשתמש

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

    כותרות תגובה ערך
    X-Apigee-fault-source יעד
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  6. בודקים אם יש שרשור של שרתי proxy. כדי לבדוק אם שרת הקצה העורפי מפעיל עוד שרת proxy ב-Apigee, פועלים לפי השלבים הבאים:
    1. חוזרים לשלב Request sent to target server ולוחצים על הלחצן Show Curl כדי לראות את הכינוי של מארח שרת הקצה העורפי.
    2. אם הכינוי של המארח בשרת הקצה העורפי מצביע על כינוי של מארח וירטואלי, אז יש שרשור של שרתי Proxy. חוזרים על השלבים שלמעלה לגבי כל שרת proxy בשרשור כדי לאבחן את הסיבה לתשובת השגיאה 504 Gateway Timeout. אפשר לאבחן מצבים של פסק זמן בשער (504) שמתרחשים בשרתי proxy בשרשרת בשלבים אחרים של מחזור הבקשה/התגובה באמצעות המדריך הזה.
    3. אם הדומיין החלופי של מארח שרת הקצה העורפי מצביע על שרת הקצה העורפי, ממשיכים אל פתרון.

תהליך מספר 2: הפעלת ה-API של שרת הקצה העורפי ישירות (משתמשים בענן ציבורי ובענן פרטי)

מתקשרים ישירות לשרת העורפי כדי לאשר את אותו התנהגות של תגובת 504 Gateway Timeout שנתקלה בה כשבקשה מוגשת דרך Apigee Edge.

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

תהליך מספר 3: בדיקת יומני הגישה של NGINX (משתמשים בענן פרטי בלבד)

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

  1. כדי לראות את יומני הגישה של NGINX, משתמשים בפקודה הבאה: 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  2. בודקים אם יש תגובות שגיאה מסוג 504 ב-proxy ל-API שהושפע. אם הבעיה התרחשה בעבר, אפשר לבדוק תקופה ספציפית, או לקבוע אם הבקשות עדיין נכשלות עם תגובת שגיאה 504.
  3. אם יש תגובות שגיאה מסוג 504, צריך לבדוק אם תגובת השגיאה מגיעה מהשרת העורפי.

    4. באיור הבא מוצגת דוגמה לרשומה ביומן של NGINX שבה מוצגת תגובת שגיאה 504 שנגרמה על ידי שרת היעד:

    דוגמה ליומני nginx

    אם השדות X-Apigee-fault-source ו-X-Apigee-fault-code מכילים את הערכים שמוצגים בטבלה שלמטה, התגובה 504 מגיעה משרת הקצה העורפי:

    כותרות תגובה ערך
    X-Apigee-fault-source יעד
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  4. בודקים את ה-API proxy המושפע כדי לראות אם יש בו שרשור של proxy, כלומר ששרת הקצה העורפי או נקודת היעד מפעילים proxy אחר ב-Apigee. אם שרת ה-proxy של ה-API משתמש בשרשור של שרתי proxy , צריך לחזור על השלבים שלמעלה לכל שרת proxy בשרשור כדי לאבחן את הסיבה לתשובת השגיאה 504 Gateway Timeout. אפשר לאבחן שגיאות מסוג 504 Gateway timeouts שמתרחשות בשרתי proxy בשרשרת בשלבים אחרים באמצעות המדריך הזה.
  5. אם אין שרשור של שרתי proxy, ותגובת השגיאה 504 מגיעה משרת הקצה העורפי, עוברים אל פתרון.

תהליך מספר 4: שימוש ב-API Monitoring (למשתמשי ענן ציבורי בלבד)

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

דוגמה לתרחיש שמדגים איך לפתור בעיות מסוג 5xx ב-API באמצעות API Monitoring. לדוגמה, אפשר להגדיר התראה כדי להודיע לאדמינים כשמספר קודי הסטטוס 504 חורג מסף מסוים.

רזולוציה

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

איסוף פרטי אבחון

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

אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:

  • שם הארגון
  • שם הסביבה
  • שם ה-proxy ל-API
  • הפקודה curl המלאה שבה השתמשת כדי לשחזר את תגובת השגיאה 504
  • קובץ מעקב עם בקשות API שמקבלות תגובת שגיאה מסוג 504 Gateway Timeout

אם אתם משתמשים ב-Private Cloud, עליכם לספק את הפרטים הבאים:

  • הודעת השגיאה המלאה שזוהתה בבקשות שנכשלו
  • שם הסביבה
  • חבילת proxy ל-API
  • קובץ מעקב עם בקשות API שמקבלות תגובת שגיאה מסוג 504 הזמן שהוקצב לשער חלף
  • יומני גישה של NGINX 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  • יומנים של מעבד הודעות 
    /opt/apigee/var/log/edge-message-processor/logs/system.log