502 Bad Gateway - Socket ניתוק

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

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 502 Bad Gateway עם הקוד ECONNRESET כתגובה לקריאות ל-API ב-Edge Microgateway.

הודעת השגיאה

הלקוח יראה את קוד התגובה הבא:

HTTP/1.1 502 Bad Gateway

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

{"message":"socket hang up","code":"ECONNRESET"}

גורמים אפשריים

סיבה התיאור ההוראות לפתרון בעיות הרלוונטיות עבור
זמן קצוב לתפוגה של הודעת keep-alive הוגדר באופן שגוי הזמן הקצוב לתפוגה שמוגדר באופן שגוי בין Edge Microgateway לבין שרת היעד. משתמשי Edge הציבוריים והפרטיים
שרת היעד סוגר את החיבור מוקדם מדי שרת היעד סוגר את החיבור מוקדם מדי בזמן שה-Edge Microgateway שולח את המטען הייעודי (payload) של הבקשה. משתמשי Edge הציבוריים והפרטיים

שלבים נפוצים באבחון

  1. בודקים את יומני Edge Microgateway:
    /var/tmp/edgemicro-`hostname`-*.log
    
  2. אפשר לחפש כדי לבדוק אם יש שגיאות 502 בקוד ECONNRESET במהלך פרק זמן ספציפי (אם הבעיה אירעה בעבר) או אם יש בקשות שעדיין נכשלות עם 502.
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
    [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
    [microgateway-core][][GET][502][socket hang up][ECONNRESET][]
    
  3. אם רמת הרישום ביומן מוגדרת כ-warn או כ-info, תופיע גם הודעת [warn] שכוללת את שם המארח של שרת היעד והיציאה, ברכיב השני. בדוגמה הזו הוא X.X.X.X:8080, וניתן להשתמש בו מאוחר יותר כדי לצלם tcpdump.
    2021-06-23T03:52:24.109Z
    [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
    [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
    [targetRequest error][GET][][socket hang up][ECONNRESET][395]
    
  4. קוד השגיאה [socket hang up][ECONNRESET] מציין ששרת היעד סגר את החיבור עם Edge Microgateway. אפשר לחפש את האירוע ביומנים כדי לבדוק באיזו תדירות זה מתרחש.

הסיבה: זמן קצוב לתפוגה של הודעת keep-alive הוגדר באופן שגוי

אבחון

  1. פועלים לפי השלבים בקטע שלבי האבחון הנפוצים ומוודאים שהשגיאה [socket hang up][ECONNRESET] מופיעה.
  2. אם כן, כדאי להמשיך לבדוק בעזרת tcpdump כמו שמוסבר בהמשך:

שימוש ב-tcpdump

  1. מצלמים tcpdump בין Edge Microgateway לבין השרת של הקצה העורפי במערכת ההפעלה המארחת של Edge Microgateway באמצעות הפקודה הבאה:
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
    
  2. ניתוח tcpdump שתועד:

    פלט tcpdump לדוגמה: ( הצגת תמונה גדולה יותר)

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

    1. בחבילה 250288, הלקוח שולח בקשה של POST.
    2. בחבילה 250371, השרת מגיב באמצעות 200 OK.
    3. בחבילה 250559, הלקוח שולח ACK.
    4. בחבילה 250560, השרת שולח את ההודעה Continuation.
    5. בחבילה 250561, הלקוח שולח ACK.
    6. בחבילה 262436, השרת שולח FIN, ACK ללקוח שמתחיל את החיבור. חשוב לשים לב שהתהליך נמשך כחמש שניות אחרי החבילה הקודמת (250561).
    7. בחבילה 262441, הלקוח שולח בקשת POST נוספת. עם זאת, הפעולה הזו נכשלת כי השרת כבר הפעיל את סגירת החיבור. התגובה שלו כוללת RST בחבילה 262441.

    בדוגמה הזו נעשה שימוש חוזר באותו חיבור לפחות פעם אחת, אבל בבקשה האחרונה, השרת מתחיל סגירה של החיבור אחרי חמש שניות של זמן ללא פעילות, כלומר בזמן שהלקוח שלח בקשה חדשה. פירוש הדבר הוא שככל הנראה, הזמן הקצוב לתפוגה של שרת הקצה העורפי הוא קצר יותר או שווה לערך שהוגדר בלקוח. כדי לוודא זאת, קראו את המאמר השוואה בין פרק הזמן הקצוב לתפוגה של שמירת פעילות (Keep-alive) ב-Edge Microgateway ובשרת הקצה העורפי.

השוואה בין זמני קצוב לתפוגה של אירוע מסוג keep-alive

  1. ל-Edge Microgateway אין מאפיין ספציפי של זמן קצוב לתפוגה של הודעת keep-alive. הוא נקבע לפי מערכת ההפעלה שבה הוא פועל. דוגמאות נפוצות לקונטיינרים של Windows, Linux ו-Docker.
  2. ייתכן שהאפשרות הזו תהיה מותאמת אישית במערכת ההפעלה. כדי לברר זאת, פנו לאדמין. כברירת מחדל, במערכות ההפעלה Linux יש זמן קצוב לתפוגה של הודעת keep-alive כברירת מחדל של שעתיים.
  3. לאחר מכן, בדוק את מאפיין הזמן הקצוב לתפוגה שהוגדר בשרת הקצה העורפי שלך. נניח שהשרת העורפי מוגדר עם ערך של 10 שניות.
  4. אם קבעת שהערך של הזמן הקצוב לתפוגה של אירוע מסוג keep-alive במערכת ההפעלה גבוה מהערך של מאפיין הזמן הקצוב לתפוגה של האירוע keep-alive בשרת הקצה, כמו בדוגמה שלמעלה, זו הסיבה לשגיאות 502.

רזולוציה

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

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

שיטה מומלצת

כדי למנוע מצבים כאלה של תנאי מרוץ ושגיאות 502, מומלץ מאוד לוודא שלרכיבי downstream יש תמיד סף זמן קצוב לתפוגה נמוך יותר מזה שהוגדר בשרתים של upstream. כל צעד ב-downstream צריך להיות נמוך מכל צעד במעלה הזרם. ב-Edge Microgateway מומלץ להשתמש בהנחיות הבאות:

  1. הזמן הקצוב לתפוגה של תהליך השמירה בזמן אמת באפליקציית הלקוח או במאזן העומסים צריך להיות קטן מהזמן הקצוב לתפוגה של הודעת keep-alive של Edge Microgateway.

    כדי להגדיר את הזמן הקצוב לתפוגה של שמירת פעילות ב-Edge Microgateway, יש להוסיף את הערך keep_alive_timeout לקובץ ~/.edgemicro/org-env-config.yaml.

    edgemicro:
      keep_alive_timeout: 65000
    
  2. הזמן הקצוב לתפוגה של פונקציית ה-Keep במערכת ההפעלה של Edge Microgateway צריך להיות קטן יותר מהזמן הקצוב לתפוגה של הודעת ה-Keep של שרת היעד.
  3. אם יש ביצוע צעדים אחרים לפני או מאחורי Edge Microgateway, צריך להחיל את אותו הכלל. תמיד צריך להשאיר את האחריות של הלקוח ב-downstream לסגור את החיבור עם ה-upstream.

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

אבחון

  1. פועלים לפי השלבים המפורטים בקטע שלבי האבחון הנפוצים ומוודאים שהשגיאה [socket hang up][ECONNRESET] מופיעה.
  2. אם כן, כדאי להמשיך לבדוק בעזרת tcpdump כפי שמוסבר בהמשך.

    הודעת השגיאה [targetRequest error][GET][][socket hang up][ECONNRESET] בדוגמה שלמעלה מציינת שהשגיאה אירעה בזמן ש-Edge Microgateway שלח את הבקשה לשרת הקצה העורפי (יעד). כלומר, Edge Microgateway שלח את בקשת ה-API לשרת הקצה העורפי והמתין לתגובה. אבל השרת העורפי סיים את החיבור בפתאומיות לפני ש-Edge Microgateway קיבל תגובה.

  3. צריך לבדוק את היומנים של השרת העורפי ולבדוק אם יש שגיאות או מידע שעלולים לגרום לשרת הקצה העורפי לסיים את החיבור בפתאומיות. אם יופיעו שגיאות או פרטים, עוברים אל פתרון ומתקנים את הבעיה כראוי בשרת הקצה העורפי.
  4. אם לא מוצאים שגיאות או מידע בשרת הקצה העורפי, אוספים את הפלט tcpdump בשרת Edge Microgateway:
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
    
  5. ניתוח tcpdump שתועד:

    פלט tcpdump לדוגמה: ( הצגת תמונה גדולה יותר)

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

    1. בחבילה 4, Edge Microgateway שלח בקשת GET לשרת היעד.
    2. בחבילה 5, שרת היעד הגיב עם ACK כדי לאשר את הבקשה.
    3. עם זאת, בחבילה 6, במקום להגיב עם מטען ייעודי (payload) של תגובה, שרת היעד שולח FIN, ACK שמתחיל את סגירת החיבור.
    4. בחבילות 7 ואילך, החיבור נסגר באופן הדדי. מאחר שהחיבור נסגר לפני שליחת התגובה, Edge Microgateway יחזיר את שגיאת ה-HTTP 502 ללקוח.
    5. חשוב לשים לב שחותמת הזמן של החבילה 8, 2021-06-23T03:52:24.110Z תואמת לחותמת הזמן שבה השגיאה נרשמה ביומני Edge Microgateway. לעיתים קרובות ניתן להשתמש בחותמות הזמן בקובצי היומן וב-tcpdump כדי לקשר בין השגיאות לחבילות עצמן.

    רזולוציה

    יש לתקן את הבעיה בשרת הקצה העורפי כראוי.

    אם הבעיה נמשכת ואתם צריכים עזרה בפתרון בעיות 502 Bad Gateway Error, או אם חושדים שזו בעיה ב-Edge Microgateway, תוכלו לעבור אל נדרש איסוף מידע לאבחון.

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

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

    • קובצי יומן: תיקיית ברירת המחדל היא /var/tmp, אבל יכול להיות שנשנה אותה בקובץ config.yaml (logging > dir parameter) הראשי. מומלץ לשנות את log > level ל-info לפני שמעבירים את קובצי היומן לתמיכה של Apigee.
    • קובץ התצורה: התצורה הראשית של Edge Microgateway נמצאת בקובץ YAML שבתיקיית Edge Microgateway שמוגדרת כברירת מחדל, $HOME/.edgemicro. יש קובץ תצורה המוגדר כברירת מחדל בשם default.yaml, ולאחר מכן קובץ תצורה אחד לכל סביבה ORG-ENV-config.yaml. יש להעלות את הקובץ הזה במלואו עבור הארגון והסביבה המושפעים.