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"}

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

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

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. אפשר לחפש ביומנים כדי לדעת באיזו תדירות זה קורה.

הסיבה: הזמן הקצוב לתפוגה של 'משך חיים ללא הגבלת זמן' הוגדר בצורה שגויה

אבחון

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 אל הלקוח שמתחיל את סגירת החיבור. לתשומת ליבכם: מדובר בערך 5 שניות אחרי החבילה הקודמת (250561).
   7. בחבילה 262441, הלקוח שולח עוד POST בקשה. עם זאת, הדבר נכשל מכיוון שהשרת כבר יזם סגירה של חיבור כזה. הוא מגיב עם RST בחבילה 262441.

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

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

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

רזולוציה

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

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

שיטה מומלצת

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

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

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

   edgemicro:
     keep_alive_timeout: 65000

2. הזמן הקצוב לתפוגה של מערכת ההפעלה Edge Microgateway צריך להיות קטן מהיעד הזמן הקצוב לתפוגה של שרת Keep-alive.
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, נשלחת בקשת GET מ-Edge Microgateway ליעד השרת.
   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. יש להעלות את הקובץ הזה באופן מלא בארגון ובסביבה שהושפעו